Flip-flop
I think we need a simple logic flip-flop, set and reset by rising edges. I've needed one twice already. The Counter "works", but its output is not a simple level and this causes problems. The flip-flop is something that has to be implemented as a module, since building one from gates requires feedback.
Comments
What about this: In order to reduce the amount of new modules, have one "router" with a reset input, one CV input, 4 outputs and an adjustable step count: 2=flip flop, 3 and 4 cycle through 3 or 4 outputs.
It would have the advantage that the output can not only be a fixed value but any signal you feed it, if you choose to. Without connecting the input, it would just toggle its outputs between 0 and 1.
I guess so, but an FF is a pretty basic logic feature; 2 inputs, one output, no complication. I definitely agree with minimizing added modules, but also like to keep them simple.
how is a flip flop different from a switch, for either on or off? Gate in to Pulse Divider set to 2 switches between on and off signal. You can have multiple inputs.
Sorry I can't see anything in the screenshot, what's that module with 4 outputs?
An adder
Oh wow, thanks, I've never used that one by now 😅
@bcrichards A flip-flop has separate inputs for set and reset. It doesn't just toggle on the next input. This allows you to remember an event, until you forget it due to another event. In my sustain hack, it sets on the rising Gate, resets on Not (Or (Gate, Sustain)). That is, it resets only when both Gate (key) and Sustain command are zero.
There are many types of flip flops, toggle and the set/reset being two variations. You also can have a "clock" input that acts as a toggle along with a dedicated set and reset, which is the minimum I'd recommend for a dedicated module.
But in the meantime, you can build one from existing modules.
@drewfx1 How would you build a set/reset flip-flop from existing modules? Remember, you cannot use feedback. I've used a Counter, but that's weird, because the output is not a cv. It seems to be some magical increasing value that passes straight through gates, limiters, etc. without change. It works, if all you need is a zero/non-zero value, which suited me at the time.
Assuming you want dedicated Set and Reset gates with the following behavior:
Both gates low = preserve current output
Set only goes high = force output high
Reset only goes high = force output low
Both high = Set takes precedence
If Set gets precedence, you just need an OR and a Sample and Hold. The Set and Reset gates feed the OR and the output of OR goes to Sample and Hold clock (gate) input. Set feeds the Sample and Hold signal input. So whenever Set goes high S&H samples Set; when Reset goes high and Set is low then the low gets sampled.
If you want Reset to get precedence when both are high, then the signal input come from Reset gate fed through a Gate Inverter, but in this case you will need additional modules to force a retrigger to get Sample and Hold to resample.
EDIT: Actually, now that I think about it, you will need to force a retrigger in the first case if Reset is held high when Set goes high.
@drewfx1 This is a nice idea. I hadn't thought of using S&H to store the state. But it doesn't work for me because the Set and Reset contradict, so ORing them doesn't work. For the sustain problem,
Set = Gate
Reset = not ( Sustain or Gate )
Both triggered on rising edges. When these are ORed, the result is always true, unless Sustain is pressed before any notes. The Counter actually works for this, because it has a separate, edge-triggered Reset input. I was able to make S&H work by using logic differentiators on Set and Reset before the OR. But that adds even more unnecessary trickery. On balance, the kludgey Counter is easier to use, until the real FF comes along.
In that type of case (one gate already sustained high), you just need to convert the gates feeding the OR to triggers. Short AD envs (with sustain set off!) will work, as will various other methods.