How is it possible for a core cell to not work properly with audio and event inputs.

Studiowaves
Studiowaves Member Posts: 196 Tri

As shown above the Inv input on the bottom works perfectly as an audio input but erratic at best as an event input. There is a panel on/off button attached to it. It toggles between 0 or 1 and yes it's set to toggle mode.

All other inputs work as expected. Being a simple button its almost like it doesn't always create an event or the value of the event isn't latched. Not sure how the compiler handles events but I assume the input itself would hold or latch the new value when it receives an event. This is either a bug or I'm need to do something to capture that value. Any ideas on a solid solution other than wasting cpu and leaving it set to audio?

«1

Answers

  • Paule
    Paule BerlinMember Posts: 263 Saw

    Hi Al, default is to latch all gui elements IMHO.

    As the button is on the gui latch it please.

  • Studiowaves
    Studiowaves Member Posts: 196 Tri

    Like this Paule ?


  • Paule
    Paule BerlinMember Posts: 263 Saw

    Al, why both Ins. Normally one is needed - not both.

  • Studiowaves
    Studiowaves Member Posts: 196 Tri

    Seems more robust as the event triggers the latch in case the audio clock misses it. At least it seems possible.

  • Studiowaves
    Studiowaves Member Posts: 196 Tri

    Koan, your comment didn't take for some reason. Guess it's the new forums break in period.

  • KoaN
    KoaN MontrealMember Posts: 30 Tri

    You might want to look into those crossfade modules,there are latches in there on the + and * , It's made for audio signal not event...i can't know for sure in your structure but i have often replaced them for suing with event,use the non-latched + and *.

  • KoaN
    KoaN MontrealMember Posts: 30 Tri
  • Studiowaves
    Studiowaves Member Posts: 196 Tri

    I was reading about using latches, they said to use them rather than not to save cpu. I see their point. It's working today with the latch and hopefully that takes care of it. I saw some modulation math in the cross fade modules. The signals that cross fade don't generate events but the x input does. Maybe the latch will fix it as it probably passes an event when the button is pressed. It seems like its an initialization problem and the latches are most likely initialized at start up. I re saved the patches because I added this switch later and my guess is that is whats doing it. The patch didn't save the switch status and that might be the crux of the matter.

  • bolabo
    bolabo Member Posts: 63 Tri
    edited January 17

    Can you post the ensemble with the problem? It looks fine from the screenshot, I'm not sure if using latches would help.

  • Matt_NI
    Matt_NI BerlinAdministrator Posts: 760 admin

    Sorry about that! We had a bunch of posts going into our spam for some strange reason. We're fixing this now and hopefully it shouldn't happen again 🙌

  • KoaN
    KoaN MontrealMember Posts: 30 Tri

    Good! It also happened when editing my post,same happened to Andrew and ColB it seems.

  • colB
    colB Member Posts: 236 Saw

    Your first cross fade is a x-fade(tap) that only responds to events at the x input, so with the inv as an event input, there will only an output when the button is toggled.

    Instead use x-fade(mod) this will respond to events at the 0 or 1 inputs, but not at the x input.

    Not sure if the other one is correct or not - it really depends on the wider context for this code which you haven't provided.

    The various cross fade types do explain which inputs generate output events in their info texts, so that's a good place to start.

  • Studiowaves
    Studiowaves Member Posts: 196 Tri

    This is a very good answer Colin, I looked inside the crossfade and the 0 and 1 inputs are connected to modulation type macros so they do not create events, the x input appears to react to an event as shown.

    I added a latch as shown

    The crossfade module info:>> Only events at the x input (the "tap" events) generate the output events.

    So from the looks of things it should work and it has been. The latch should send and event whenever the button is pressed or after a patch change during initialization. Perhaps there are 2 reasons the Inv input was reading 0 when the buttons light was on (which is a 1). The button may have failed to send out a 1 because I may have added the button after making the patch. I'm almost sure of it because even after I added the latch it did the same thing on another patch yet worked like it should on a couple of others. That's most likely what caused the issue. Keep in mind that I was toggling the button when it did not work yet the output remained a zero. When I changed the input to audio it worked every time. It's possible the patch itself wasn't directing the button to the Inv input when used as an event, maybe that's how events work, meaning the compiler handles events as directed by the patch yet as an audio input the sr clock passes it along whether it's been saved in a patch or not. So far so good after re saving all of the patches. What do you think about the 2 connections on the latch, it seems almost foolproof because the event from the switch latches the value. If the bottom connector is left open, the next audio clock latches the number. Who is to say the event from the button is still active when the next audio clock triggers the latch.

  • colB
    colB Member Posts: 236 Saw

    The latch you have added to the Inv input does nothing. If it's all working now, it is for some other reason.

  • Studiowaves
    Studiowaves Member Posts: 196 Tri

    Pretty much what I was thinking, I strongly think that when adding something new that is event based that you must save the patch and it's possible you need to reload the patch afterwards or it may fool you. I keep all of the versions by date so I can try again and repeat what I did and see if it does the same thing. Then do it again but save the patch and try it. If it still doesn't work I'll recall the saved patch and if that fixes it then we will know of a solution for this problem. I agree, the event should pass right thru the input and instantly trigger the cross fade and there is no need for a latch. On the other hand the number latched will do nothing if the initial event doesn't make it into the x fade. I was thinking the compiler would grab the latched number and send it to the crossfade as an event but maybe not. Maybe the next audio clock sends the number to the xfade and triggers changes. I don't know how it works, it seems you can loose either way but they do use latches connected to the SRC a lot and I suspect there's a reason for it. By latching the number with its associated event seems a guaranteed latch but in reality it probably just passes right thru and generates an event to swap the crossfade. After that it's useless even if it does hold the number because there is no clock to keep it moving down the line. Another excellent point Colin, that's why your the boss. lol Thanks,

Back To Top