Sample player: is there a way to play a new slice before the current one is not finished?

Hi guys

I looked in the forum but could not really find the answer. Is there a way to trigger a new slice while the precedent one is curently playing ?

I don’t need polyphony, to be clearer this is what I need:
trigger + CV1 from sequencer–> Slice 1 plays
Trigger + CV2 -->Slice 1 stops right away (even if it’s not finished yet) and slice 2 is played.

Is this possible or the CV can’t change the slice until it’s fully played?

What you’re asking for is totally possible, if I understand you correctly. I think what you may need is a slight amount of delay on the gate(trigger) to allow the CV to affect the sample player. Something like 5ms should do it.

If you saw my thread o’ babbling as I worked through my own questions, I ended up with what you are looking for - you trigger one sound (drum in my case), and when the second fires, it stops the first.

The sampler can be re-triggered arbitrarily during playback. The slice select value is sampled on each new trigger, regardless of whether or not a slice is already playing.

Having to delay the trigger slightly to ensure reliable slice selection is a separate issue (one might say … “orthogonal”). There is generally a bit of slew on CV sources, but triggers are more or less instantaneous. The ER-301 detects the trigger before the CV has settled on the target value, which can result in the “wrong” slice being selected. Delaying the trigger slightly can correct this problem.

Thanks for your tips guys. When delayed by Maths for exemple the trigger and CV are working together and changing slices. Any idea if it’s going to be fixed or changed on later updates?

Also the problem seems to be the same with manual grains, you have to send a new trigger with each CV changes for it to switch, meaning you can’t change grains really fast if they are long. No way to avoid this yet?

Delaying the trigger is the fix. Perhaps adding a dedicated delay parameter to trigger inputs would be a nicer solution. Using an “audio-grade” delay seems a little heavyweight, since things like wet/dry balance and feedback aren’t really needed.