## Triggering sah~ only when going reverse

Oct 09 2011 | 1:29 pm
I'm trying to use sah~ to sample a value when I hit 0.001 of a Phasor~ but I only want this to happen when I'm going from 1 to 0 and not 0 to 1.
I tried using delta~ and
I also tried edge~ but I don't want to make it to 0.999 going backwards. I want it to stay above 0.
The intended purpose is to keep a phasor~ (in this case groove~) within a certain range (so when it hits 0.001 it jumps up to 0.3 or whatever else).

• Oct 09 2011 | 1:56 pm
Hi Rodrigo
there may be a more efficient method (perhaps using [!-~ 1.] to invert your ramp, I dunno), but with a simple change to your patch it seems to work as you require - after [delta~] replace [~ 0.01]: [delta~] gives positive OR negative values, depending on ramp direction.
Brendan
• Oct 09 2011 | 5:42 pm
I tried something similar before (using edge~) but I ran into a couple of problems. First, if I'm understanding it right, using delta/edge tells me when I've gone from >0 to
I also want to try doing it in the signal domain completely rather than using signal to edge/bang, and back to signal.
Lastly, I'm using this in conjunction with minmax~, so going from 0.001 to 0.999 fills minmax~ with the maximum value, breaking it until I reset.
I was hoping to avoid that by going sample accurate so I would capture the value from minmax~ using sah~ and jump up to the highest value minmax~ had read, before hitting 0.
Here is the patch with minmax and the delta/edge method.
• Oct 09 2011 | 9:12 pm
sorry i been busy. gonna look into this again soon. in mean time, leave the turning into a float until the last possible moment
• Oct 10 2011 | 10:55 am
I had snapshot at the very end as well and it was filling the float just fine, (though not sample accurate) but the problem is in one of two places.
If I use delta/>0.5 then I'm sampling after it goes 0.01 to 0.99 (as that's the only time that the delta value would be >0.5) which breaks the use of minmax~ as it then reports the highest value (0.99).
If I use the sah~ 0.001, it seems to sample before it goes to 0.99, but the problem is it does it going both directions.
The version that n00b posted only triggers going backwards but I think it's doing it at the same time (post 0.99)
I'm starting to wonder if I should just drop the sample accurate part and hack it with control objects (edge/bang a float, then gate the value going to minmax~ or something, so it works over and over).
Or maybe opening the gate to minmax~ only when going forwards (as I don't care about minmax when going backwards).
• Oct 10 2011 | 11:11 am
Ok, so I tried gating the numbers going to minmax~ based on the direction I was going. So only letting values through when moving forward, as that's all I care about, the "high water mark". When going backwards, I want to jump to the highest value set by minmax~, I don't want minmax~ to report anything at that point.
I tried using delta and >~0 to report when I'm going backwards and it works fine, except that once a cycle, it opens briefly (when going from 0. to 0.9), which breaks minmax~ again.
I then tied the gate to the reverse toggle, and this seems to work except it's back in the control domain.
I tried using delta and >~0.01 like in n00bs posted version but that got me nowhere. Is it possible to close a gate when going backwards without having it pop only momentarily when the cycle wraps around (which is what delta is doing).
Here's the patch with delta~/gate~ and toggle/gate~ versions.
• Oct 10 2011 | 11:22 am
And finally here's a working version (in control domain) of what I want it to do.
It starts playing back the sample, then when you reverse, whatever the highest point you got to, it jumps back up to that on the next play through, and keeps doing that if you go up to a higher number.
• Oct 10 2011 | 2:06 pm
hi rodrigo. sorry about that last patch i posted. was in a rush and it was probably crap.
the last patch you posted above is the best yet and seems to me the way to go. works great and, after all this time in the other thread and in this thread, i think i finally understand what you are trying to do (!!).
i had a couple small points / ideas (e.g., surely you mean to also trigger 'reset' on loop point of forwards, too, in case it goes past that?). i commented your patch a small bit and then took the liberty of making a possibly slightly more accurate version (see the subpatch). working very good here for me:
if you want samplerate triggering, investigate a [play~] solution, and / or wait for Max6 !
cheers.
• Oct 10 2011 | 2:40 pm
Yeah it's difficult trying to communicate something like that, particularly when I'm not great at signal domain control stuff anyways, so I was likely explaining things wrongly anyways.
Yeah I would trigger [reset] more often than that. The actual patch has this wrapped into the recording routine so it would only need to be reset when a new loop is being created (and this whole reversing to max point only happens during that loop creation). It's all to be able to record forwards and backwards when creating the initial loop.
I know that groove~ isn't the best, but I have all of my patch built around it at the moment, and don't want to start it again from scratch completely in the signal domain.
The subpatch you made looks great! I'll give it a good sit down and wrap my ahead around what's happening.
Thanks again for your help with this.
• Oct 12 2011 | 7:26 am
Here's an audio-rate solution (kinda; it might not be exactly what you're after but it does show that it can be done):
HTH!
Chris
• Oct 12 2011 | 7:55 am
Hmm quite interesting! Thanks
Now if I can only stop getting poke to sound like a crap when I record backwards! (https://cycling74.com/forums/zippergritty-distortion-when-writing-with-pokeipoke-backwards-groove-sync)