I'm trying to come up with an audio rate flipflop that doesn't use the [expr~ ] object. I'm using Plugdata in compile mode, so expr~ isn't available. I've done lots of searching, here and elsewhere, I haven't been able to find anything that I can implement.

Any ideas? What I'm hoping to do is use a brief ~1ms trigger signal to switch between two signals, so I need each trigger to change the state of a toggle/flipflop to drive the signal switching. I can't make the trigger longer, because it's coming from a signal cross detection.

@rewindForward

I'm trying to extract level crossings between 2 signals, [...] and use that to switch signals.

the patch i posted above does this. However, it doesn't generate a trigger (one sample impulses?) from each crossing...

I do think it's very similar to what [max~ ] is doing, unless I'm misunderstanding?

mh i don't know. It depends on what you do with [max~], which is not clear to me.

For my purposes, I'll need a stream of triggers to gate a trigger (vs gate) stream that I'm going to gate with another process so that trigger signals only pass when the other process opens to gate the level crossing triggers. The problem is, then I need a flipflop/toggle...

This works, for reference:
...

looks like you found a solution(?) I'm wondering if you even need to generate/process a stream of audio rate triggers to achieve your goals. I know supercollider uses audio rate triggers, but in pd it is a bit tricky to work with this concept.

@solipp said:

looks like you found a solution(?) I'm wondering if you even need to generate/process a stream of audio rate triggers to achieve your goals. I know supercollider uses audio rate triggers, but in pd it is a bit tricky to work with this concept.

That's a good question, and the one I guess I'm asking by trying this out. I blocked out the general idea in Supercollider to figure out how to approach it, and I'm trying to port those ideas to PD/Plugdata so that I can compile it for hardware. I've always wanted to go deeper with PD, so this seemed like a great opportunity to learn.

@solipp said:

mh i don't know. It depends on what you do with [max~], which is not clear to me.

The goal with the signal crossing -> trigger -> toggle -> wave switching portion is to switch waveforms when there's a signal crossing, and both signals are either of the rise or fall of their waveform. Compared to min max, it produces a signal with much less of a "buzz", and I like what it does for combining sine waves.

Thanks for your help.

a bit late to this and nice approaches were already mentioned. but since i just built a flipflop~ abstraction a few days ago, i felt like joining this discussion anyway.

here's a patch that uses this to switch signals when they're crossing while sharing the same direction:

flipflop~ is this:

this obviously relies on the zexy library. time to lobby for https://github.com/pure-data/pure-data/pull/2054 ... but these compiled objects can be replaced with vanilla stuff if needed.

patches:
switchoncross~.pd
flipflop~.pd

PS: this obviously happily switches the signals on every crossing. if you want to "arm" the switch through a trigger, it'll need to handle this additional "armed" state which then get's reset by the next crossing impulse ...

this should hopefully work correctly for switching only after impulses:

EDIT: without block~ 1, there's a risk of directly switching back in the same block while the switch is still armed. so this is not very elegant. if anyone knows how to tackle this without 1 sample blocksize, let me know!

@rewindForward said:

I'm using Plugdata in compile mode, so expr~ isn't available.

If you are on the latest toolchain release it is (mostly) available!

In the next release of plugdata (or the current nightly build) the warnings for expr/expr~ will be gone as well, but the toolchain will already work. So just ignore the warnings for now

@ben.wes You could use [cpole~] instead of [rpole~] like this: audio-rate-toggle.pd

@manuels said:

@ben.wes You could use [cpole~] instead of [rpole~] like this: audio-rate-toggle.pd

thanks! - this seems very interesting! i never used [cpole~] so far and will play around a bit with it these days. but i admit that i don't get yet how i would use these states here to "disarm" the flipflop mechanism immediately after a switch?

@ben.wes Oh, I think I completely missed your point ...

If I now do understand correctly, a simple solution might be to disarm the switch after every crossing instead every switch, because then you don't need feedback ... switchoncross-disarm.pd

@manuels said:

@ben.wes Oh, I think I completely missed your point ...

no worries. that was an interesting hint nonetheless!

disarm the switch after every crossing instead every switch

now i feel completely stupid, haha. of course that's the proper solution! there's no reason at all for not just resetting on every crossing!

i assume that i was too much influenced by a zero-crossing switcher abstraction i built in the past that required feedback in a similar case. thank you!

EDIT: and obviously, there's no need for the [sgn~] (sign) object. [>~ 0] is enough and i really hope that https://github.com/pure-data/pure-data/pull/2054 will make it into vanilla soon!