latchgate~ ?

a solution I came out with...

cheers
aa

Does this do what you need?

Thanks guys, they both work great. [+=~] was the piece I was missing. I don't see it in the max help file. Another one of those objects I wish I'd known about a long time ago that just pops out of nowhere.

Thanks again.

Just one remark:
in Tim's patch, the feedback loop introduces a latency of one signal vector. So, in fact what you obtain is that the 0-1 transition is sample accurate, but the 1-0 transition is not - it goes from 1 to 2, stays at 2 for one vector and then goes back to 0:

cheers
aa

That's true about my patch. Andrea's is definitely the better all-around solution. Just make sure that you reset the accumulator every so often, or it's possible for it to stop working completely ;) That would be pretty unlikely, but if you're using the abstraction with a fast flow of 0-1 transitions, it's possible that you could run in to rounding error issues after the patch has been running for a while. It depends on the context you're using it in though, so just make sure you reset [+=~ ] when it's not in use.

this is also true.

In fact, it would take many hours, even if the incoming samples are constantly switching between 0 and 1, to run into rounding error issues with integers. But yes, eventually the problem arises if +=~ is never reset.

I think Psyko's problem is a quite interesting one. I can't figure out a perfectly satisfying solution in Max (but this doesn't mean there isn't one, of course!) but the problem becomes trivial in C or Java... maybe it's time to write a small [flipflop~] external!

aa

It wouldn't necessarily take hours. At 44.1k it would only take 12 minutes of sample-rate flipping between 0 and 1 for rounding error to stop it working. That would be a worst-case scenario though and it isn't likely to happen so fast in an actual patch.

I think the only way to do it with standard objects would be to put the feedback-loop method into a poly~ with a signal vector size of 1. That would be fairly cpu-intensive, so an external would definitely be better! I've had the zipped-up SDK sitting on my desktop for a long time taunting me about my non-existant ability to write externals!

I just tried the poly~ approach and it didn't work, the feedback still makes the down-transition lag.

However, I just remembered Andrew Benson's [steps~ ] external, which does exactly what Psyko wants already. give it an argument of 2 and it does the job; I can't believe I didn't think of it before, I've been using his audio rate objects for ages for things like this *facepalm* :)

Eric Lyon's [el.mask~ 1 2] > [el.clickhold~ ] > [-~ 1 ] will also do the trick sample-accurately.

Yeah, I played around with both patches for a little while this morning. Seems like you get a choice between an infinite counter or a feedback loop, no matter how you slice it.

Sticking a [%~ 2] at the end of Tim's version fixes the vector size latency on reset as far as output goes, but would still cause problems if you tried to retrigger it faster than the vs.

Neither drawback is really an issue for me right now, as I don't plan on triggering it fast enough to make it skip or often enough for it to lose count. But I'd still like a complete solution.

Looks like it might be time to write my 1st external. I'm surprised this hasn't come up more often. It's one of those things that seems simple until you actually try to do it.

Here's what I finally settled on (for now):