Forcing an order on timing

I’ve been struggling with the best approach for making sure a sequence of events “cascading” from a single trigger event happens in the right order.

For example, a clock trigger causes input to be sampled with S&H, and the output of that S&H changes a parameter of a sample player, and then the output of the sample player feeds into an S&H that needs to be triggered. If the trigger to the last S&H comes at the same time as the first it won’t get the right value since the intervening sample player start change hasn’t happened yet.

I have been using arbitrary short delays and trigger-holds to make it all work, but any timeline I make basically sets the max rate that the overall unit can update.

In max or PD there are rules about the order that signals pass through the network that make it possible to sequence these kinds of things with minimal delays. Are there rules like that in the 301?


1 Like

Good question… not that I am aware of! I’d be very interested if there is a solution to this if anyone has any bright ideas :slight_smile:

Intuitively I think this would be possible once the middle layer is exposed and bespoke units can be written in Lua.

May I ask what rules specifically you are referring to?

What I was thinking of is the right-to-left, depth-first propagation of messages… so in a max or PD patch, one can predict when a signal will arrive at a particular node and use “trigger” or other sequencing primitives to control the order of evaluation.

I know the 301 isn’t the same, basically everything is a “signal” rather than a “message” in the pd sense, but the problem of trying to figure out when a unit’s inputs are all set up and ready to sample is the same.

I guess as a practical matter it comes down to “what’s the minimum delay before we can be sure a change in an input has propagated to the output”… is it one sample, one block, or something else?


I’d be very interested in some sort of “trigger”-like workflow as well. I’m so used to it in max that I don’t even think about it anymore and I did stumble across similar problems before with the modular - Although I don’t think it’s a ER-301 issue in particular, as the same problem arises when you have multiple modules in a patch that have different latencies in their response to triggers (I’ve had that happen multiple times before). But certainly, when you’re talking about the same signal input on a single module, it feels even more confusing to not be able to predict the order of events.

May we talk about just this particular example for a second? What parameter of the Sample Player is the first S&H changing?

Internally, there is zero delay from one unit to the next (unless the unit’s algorithm is doing something to delay the audio such as a delay line or the natural group delay of a LPF or when there is grain starvation in a granular player and so on). Processing is in blocks of audio but each block is pushed through the entire chain of units on each frame sync. So all units in the chain “see” the current block of audio within the same frame.

What parameter of the Sample Player is the first S&H changing?

It’s changing the “start” parameter. I’m using the sample player as a lookup table to do a math calculation, and I set the “start” to the “x” coordinate, trigger the sample player, then trigger the S&H to catch the output. Those 3 events need to happen in that order to get the right answer out.

The Sample Player has no “start” parameter. Perhaps you are referring to the Manual Grains unit?

The Sample Player has no “start” parameter. Perhaps you are referring to the Manual Grains unit?

Sorry, I meant “shift”. I wasn’t sitting in front of the unit at the time.

Does it work when you trigger slowly but then stop working when you trigger faster than about 200Hz?

I haven’t tried to find the minimum delay – that was partly the reason for this thread :slight_smile:

I think I have been using about 10 ms successfully, and 0 ms unsuccessfully, so 5 ms could reasonably be the cutoff.

No I mean without the delay.

I suspect that my rate throttle on slice activation is interfering with what you want to do…
At the moment a slice is only allowed to be activated once per block of samples which is about 375Hz for the 48kHz firmware.