Maybe something like this could work. I haven’t flashed it, but I hope this gives you an idea as to what you need to do!
The [r Ctrl5 @hv_param] will output a signal between 0.0 to 1.0. If you connect a gate CV into CV input 5, that object should either output 0.0 or 1.0.
Honestly, you can probably connect [r Ctrl5 @hv_param] to [s cvout1 @hv_param] directly and see what happens! It should blink according to the gate CV.
Actually I suspect that using a snapshot~ on that control message is not going to do anything.
This object requires a signal input (notice the color of the inlet), it might work if you add a sig~ object in the path.
However this whole setup feels a bit like a “hack”. There must be a better way to interpret the Ctrl8 as a gate …
By the way: adding a number box in a signal chain in Heavy does nothing but add another [f ] box. So unless you want to store a value and bang it later it is not functional.
What if you remove the whole snapshot~ part? Only leave the [ > 0.5] and what comes after.
I think the main issue of recognizing proper “gates” is “rising edge” detection and the total gate duration.
For the normal “gatein” device configuration this is already handled by libDaisy by using the gatein_trig option for instance.
Glad to hear that it’s working!
And that was my bad about [snapshot~], I wrongly thought that [r Ctrl5 …] was outputting a signal, I’m sorry about that. It does output values constantly, so that’s worth keeping in mind.