Oopsy Daisy Gen~ problem
I am working on a project using Oopsy Daisy Field, it requires programming in Gen~ which I'm not fimilliar with.
I want to made something like MSP [selector~] with 4 signal input , when I push a button on Daisy, it let one signal pass , but the buttons on Daisy hardware like [click~], it's a impulse. and things in Gen~ are always sending "numbers" out. I tried some sort of ways, doesn't work.
Hope some one give me some clue!
it should be like this( but I need those work in Gen~ ):
Thanks~
Hi.
I am hardly an expert in gen myself, quite the opposite, and there is probably a way more efficient way to solve your problem, but this kind of works.
Here's another version. Got rid of a couple of objects by reseting the counter and then sending a one sample delayed increase counter signal (with history object)
I'd be tempted to use a [latch] -- here's a really simple example:
The output is routed to the selector.
The caveat is if more than one button is pressed at the same time, then the latch will output the sum of their values. By default, if the input value to the selector is greater than the selector length (e.g. if the latch outputs 2 + 3 = 5, but the selector has length 4, then the selector will use the 4th output. So that's probably a decent compromise. And, since it's unlikely that you can release two buttons at the exact same time, in practice this should rarely happen.
----
However maybe you want to use this intentionally, to track different button combos?
Then you might want to use binary encoding to differentiate all possible button presses, and you would need some extra logic to handle the case that button releases can happen at different moments. That is, enable the [latch] at the first button-down event, and disable the [latch] at the first button release, until all buttons are released.
Here's what that might look like. The goal is to open the [latch] when any button is pressed, but then close it as soon as any button is released, and stay closed until all buttons are released. That means another memory element is needed -- in the patch below I'm using a [+=] accumulator as my memory element, because it usefully gives us two different trigger inputs.
The triggers we need depend on button release events -- I'm using [change] to [< 0] to get the negative edge when a button is released.
One of these for each button, routed into a [> 0] to merge, will give a trigger when *any* button is released. The four buttons merged first by [> 0] and then into the release detector will tell us when *all* buttons are released.
These two different events (the any and all cases) are the two inputs to the [+=]. It will output zero when all buttons are released (the accumulator is "reset"), and output some non-zero value after any button release, until the next reset.
Logic-inverting that will give us exactly what we need for the latch:
The binary encoding here can get up to 15 different "modes" for the selector.
That’s a way more elegant solution than mine :)