michelez

I am using sah~ as a trigger for envelopes as well as for sending out samples. I stored patterns into buffers so that I can do everything in MSP without using any max. this is because as soon as I start introducing objects like edge~ or change~ the timing get really sloppy.

So... I came up with a solution that seems to work but needs to rely on a delay line. Since the delay is consistent for all of the triggered events, I can live with it but, still, it's not ideal. If you check out the attached patch if you change the value in in the number~ object sah~ will output it and trigger and envelope. If I don't use the tapin~/out the value that sah~ outputs is NOT the last one but the one before.

Can anyone chime in and tell me if there is a way to avoid the 50/100 ms delay?

So... I came up with a solution that seems to work but needs to rely on a delay line. Since the delay is consistent for all of the triggered events, I can live with it but, still, it's not ideal. If you check out the attached patch if you change the value in in the number~ object sah~ will output it and trigger and envelope. If I don't use the tapin~/out the value that sah~  outputs is NOT the last one but the one before.
Can anyone chime in and tell me if there is a way to avoid the 50/100 ms delay?

sah-trigger

While I appreciate your posting a concise example, it's not clear to me exactly what you're trying to do and why the delay is there. Are you trying to achieve "When the value exceeds the threshold, grab it and maintain it till it goes below the threshold and comes back up above the threshold again"?

I guess it was a little too concise. I have a buffer with stored values between 0 and 1 that are placed at specific time intervals. A msp step sequencer.

All values >= 0 trigger events and output the value while a -1 value is ignored. Therefore I need the value output by sah~ to be tested first and, if >= 0, trigger a cascade of processes including the envelope in the example above.

The problem with the sah~ without delay is that whenever the value changes it will trigger the envelope but output the value previously stored, not the current one. This is a problem since the -1 value is supposed to be "silent" .

I attached a new example which should clarify. Thanks for looking into this.

I guess it was a little too concise. I have a buffer with stored values between 0 and 1 that are placed at specific time intervals. A msp step sequencer.
All values  >= 0 trigger events and output the value while a -1 value is ignored. Therefore I need the value output by sah~ to be tested first and, if >= 0, trigger a cascade of processes including the envelope in the example above.
The problem with the sah~ without delay is that whenever the value changes it will trigger the envelope but output the value previously stored, not the current one. This is a problem since the -1 value is supposed to be "silent" .

I attached a new example which should clarify. Thanks for looking into this.


I think whatever problems you're experiencing are due to your use of interpolating objects such as slide~ and wave~, rather than to any flaw in sah~. The values that will come out of those objects (slide~ and wave~) are pretty unpredictable because they're calculating new values (that don't exist anywhere in your buffer~) based on the precise value of the input and the buffer~ contents.

I made some controlled experiments in an attempt to demonstrate/examine exactly what sah~ is doing. Open it with MSP audio turned off. On the left side of the patch I created a buffer~ of 256 samples, set them all to -1, then set sixteen of the samples (indices 15, 31, 47, 63, ... 255) to unique values (0, 0.0625, 0.125, 0.1875, ... 0.9375). Now you can test the other three parts of the patch by turning audio on and off.

If you step through that buffer~ at exactly the sample rate, using count~ and index~, you can see that sah~ behaves properly, using the value in its right inlet to determine whether to sample and hold the value in its left inlet. Notice that the triggering value must 

 than the threshold, not just equal to it, and must have been preceded by a value that was below the threshold.

If you want to use phasor~ to try to read through the the buffer~ at some other precise rate, you should scale the output of the phasor~ to the size of the buffer~ in samples (in this case 256) and use that as an input to index~ to look up the buffer~ value at that precise index. In the second example, the output of phasor~ will go from 0 to almost 256, so it will always be providing a lookup location from 0 to 255 to the index~ object. It's important to note that index~ does 

 interpolate between buffer~ values, it just truncates the index number it receives from phasor~ and uses that location in the buffer~, so it will always send out the correct value from the buffer~. I chose 100 Hz for the phasor~ so that it would read through the buffer~ in exactly 441 samples (assuming a sample rate of 44,100 samples per second). You can see that it gets through the buffer~ twice in 882 samples.

Using wave~ is not so advisable, because it takes in the input value from 0 to 1, scales that to the size of the buffer~ (or the portion of the buffer~ that you specify), and then finds the appropriate value at that location in the buffer~. But in most cases the input will result in a buffer~ location with a fractional part, such as 127.875, and wave~ will then calculate a value that is interpolated 7/8 of the way between the value at index 127 and the value at index 128.

If you step through that buffer~ at exactly the sample rate, using count~ and index~, you can see that sah~ behaves properly, using the value in its right inlet to determine whether to sample and hold the value in its left inlet. Notice that the triggering value must surpass the threshold value (must be greater than the threshold, not just equal to it, and must have been preceded by a value that was below the threshold.

If you want  to use phasor~ to try to read through the the buffer~ at some other precise rate, you should scale the output of the phasor~ to the size of the buffer~ in samples (in this case 256) and use that as an input to index~ to look up the buffer~ value at that precise index. In the second example, the output of phasor~ will go from 0 to almost 256, so it will always be providing a lookup location from 0 to 255 to the index~ object. It's important to note that index~ does not interpolate between buffer~ values, it just truncates the index number it receives from phasor~ and uses that location in the buffer~, so it will always send out the correct value from the buffer~. I chose 100 Hz for the phasor~ so that it would read through the buffer~ in exactly 441 samples (assuming a sample rate of 44,100 samples per second). You can see that it gets through the buffer~ twice in 882 samples.

Thank you so much for the super informative post.

Also this allows me to only write the samples I need instead of filling the whole buffer, it is more economical and I can get rid of the delay.

Thank you so much for the super informative post.
Also this allows me to only write the samples I need instead of filling the whole buffer, it is more economical and I can get rid of the delay.
Have a great Sunday!


sah~ trigger