PLAYER: master vs slave

I would like to discuss the play head mechanics of the SAMPLE PLAYER unit in more depth.

Let me start by identifying the key similarities and differences between continuous looping and repeated triggering:

Case M(ASTER): A looped portion of a sample (start and end) is specified. When the play head reaches the end position, it jumps back to the start position and continues playing. I call this master, because the play head itself is the timing master.

Case S(LAVE): A start position is specified in a sample. Whenever a trigger is received, the play head immediately jumps back to this start position and continues playing. I call this slave, because an external trigger (from outside of the PLAYER unit) is providing the timing.

Some observations:

  • Case M and S sound exactly the same if the trigger period and loop length are the same.
  • Sync is already built into Case S, but you would need to add a reset input to Case M to get syncable loops.
  • In Case M, to control loop length with an external signal, you have two types of strategies: direct mapping of CV range to a time duration (i.e. 0-5V maps to 0-100% of sample length), or CV range is mapped to a multiplication of a given clock (i.e. negative voltages divide a given clock and positive voltages multiply a given clock).
  • Here is the biggest dilemma for Case M: Because the ER-301 has no gate outputs, if you use case M then you have created a time division that you cannot (easily and cheaply) use outside of the ER-301. In other words, you are trying to use the ER-301 as a timing master when it has been designed as a slave.

To summarize, case M needs the following inputs:

  1. Start position.
  2. Loop Length.
  3. Reset input.
  4. (Possibly) Clock input for quantized loop lengths.

Case S needs:

  1. Start position.
  2. Trigger input.

So this is where I’m coming from. I am really leaning towards Case S (and always have) but I sense some confusion in the audience. I would love to hear your opinions and insights. What have I failed to think about?

Of course, one answer to all of this is to just provide two PLAYER units, a slave and a master type. However, let’s just assume that eventually both will exist but we still need to prioritize which one should get the most attention right now.

1 Like

I’m right there with you prioritizing the SLAVE functionality of the 301. Like most modules in euro, I like that the 301 is NOT an independent instrument - you add your own input signals to turn it into a custom digital audio instrument that perfectly fits your needs.

I wouldn’t want this to be a hinderance to the marketing of the 301, but I feel it should be made pretty clear that this is not a good first, second or even 10th module to buy when getting into euro. I feel it should be assumed that a 301 buyer already has a whole arsenal of modules to feed into the 301 for clocking, triggers, modulation etc in addition to experience with some analog versions of the units within the 301?

1 Like

Another thought - as more 301 units start becoming available to people beyond us fanatics (that knew from day 1 what this machine could potentially do in our rig), I could see more novice euro enthusiasts possibly buying it for the specs without fully understanding it. It might be useful to have answers on the 301 page about some simple philosophical choices like:

  1. Why does the 301 have only one knob?

  2. Why is there no CV output?

Along with some basic examples of “301 patches” that showcase it’s modularity?

I wouldn’t want this incredible product to receive any backlash from frustrated users who just might not quite be ready for it yet

1 Like

I prefer the SLAVE approach at the moment as it only requires two inputs (Cv of slice & trigger to start) which is ideal for many sequencers. The MASTER approach has 3 or 4 required inputs which is quite excessive IMHO.
For tempo synced loops I’m making loops at a specific BPM & known bar length and sending a trigger input to start the loop at the start point (beginning of loop) - this is working fine at the moment if I stick with the same BPM.
Hopefully at some point a time stretch player will become available but not I guess this falls outside the scope of this thread.

As long as we assume that both will eventually exist, I think that S would be fine to come out first, but at some point in the future, I would really like for M to be an option.

I can see a lot of creative abuses with M (modulating loop length or CV manipulations of clock div/mult time divisions along with polyrhythmic triggering of reset) to get fun cut-ups of drum loops/vocal samples.

Conceptually, it is somehow easier for me to imagine sliding start and end markers forward and backwards with cv, rather than imagine doing the same things via time intervals between triggers. Ultimately, I’m in love with the possibility to “CV ALL THE THINGS!!!” - that’s the best part of modular, I think :slight_smile:

I think time stretching is on topic. So please continue to talk about that also. If left to my own devices, I would specify time stretch factors via PLL with an incoming clock (probably derived). In either case, I think time stretching doesn’t need to know loop length, it just needs to know where the beats fall which is technically already provided if you put a slice on each beat.

1 Like

This is a good idea and I think I will do some kind of FAQ/What-the-ER-301-is-not page. I hope the situation is not the one depicted in this venn diagram:


I for one would welcome some sort of looping functionality. It doesn’t need to be a quantized perfect sync to clock type of thing, but more like something to experiment with and create happy accidents. The syncing I need is taken care of by triggering a reset or changing the start point.

Being able to loop and setting the length of the loop either to a percentage of a splice length or as a time value from a start point, controllable with cv, enables rhythmical variations beyond that of a clock and/or gate sequencer. And of course creation of padlike sounds and all sorts of fun. Not that I’m not having fun with the 301 as it is.

And as a bonus maybe a setting for loop type like ping pong :slight_smile:

1 Like

Devil’s advocate mode ON.

@Mario, I think you can get the same happy accidents from just using two clocks that are not sync’ed. So I’m still left with the question of what does a length-oriented UI get you over a trigger-oriented UI? In a trigger-oriented UI, loop length is controlled by the frequency knob of your trigger source. This type of control has a lot more depth, sophistication and history then, say, CV over length.

Devil’s advocate mode OFF.


For instance, being able to polyrhythmically step sequence cv manipulations of clock div/mult of a given clock for loop length combined with cv manipulation of sample slice selection would be fun for days :slight_smile:


“CV manipulations of clock div/mult”

So this sounds like you are describing the same trigger/clock-based approach which I’m currently soapboxing. Or did I read that wrong?

There are lots of idiosyncratic modules and music devices (drum machines etc) that need to be master – you can’t have more than one of those in your setup if you depend on sync. Play nice with others first, imho.

I would def vote for case S.

In another vein… but on the topic of loopers:
I use a very simple looper with only 1 input and 1 knob for interaction. Multiple behaviors are baked into that 1 knob, and I love it for its simplicity. Is it a good time to talk about things like that, or is that something for later or a separate thread?

I guess what I’m describing for the CV divisions of clock div/mult and slice length is a sort of hybrid approach. How I see it in my head is having cv control over slice selection that I can then trigger, and then cv control of loop length from that slice forward (possibly wrapping) as determined by multiplication/division of musically meaningful subdivisions (x2,x3,x4… /2,/3/4… or … quarter note quarter triplet, 8th, 8th trip, 16th, 16th trip, …) (as derived by incoming clock (or original loop length maybe?)

Hopefully that isn’t confusing. Basically I would like to select slices, trigger those slices (starting a loop which possibly could wrap around the end of the sample) with the ability to modulate the loop length (aka the end point) via cv-controlled metric quantization.

My thought was that you could then polyrhythmically sequence those parameters to get all sorts of drum slicery/glitchery going on. That being said, perhaps that is overcomplicated when I could just use a clock mult/divider as a trigger and modulate mult/div by CV and there is a different way to get conceptually the same thing

So pardon my rambling and thinking out loud if it is confusing. For me, one of the joys of eurorack is abusing CV modulations to get unexpected things. Modulating loop start and end points tightly is a lot of fun, and having the ability to do it in a metrical way seems like a doorway into all sorts of stuttery and glitchy goodness

1 Like

I agree that there probably are equal opportunities for happy accidents and creative variations in Case S. I think my brain is somehow defaulting to the concept of sliding start and end markers, like @giftculture said, and not to manipulation of several triggers to manipulate samples. I’m more than happy to get accustomed to Case S and all the possibilities it offers.

I am definitely in favour of the SLAVE approach too, I am not sure I would like the MASTER approach at all.

Looking forward to the time stretching, that will close the loop for me :wink:

I know it has been mentioned before but for me having the reverse playback of samples working again in the forthcoming update would be great!
So if I set the speed to minus (or if you want to add in a reverse button - trigger able between forward playback and reverse playback - that would be awesome too!) and then trigger my sample then it should hopefully play the sample in reverse! On one of the old firmware’s it was working but now it is broken.

My vote is for S now, M (as separate player) later

Hmm. This works for me…
The only thing that doesn’t work yet AFAIK, is that when playing in reverse, the play head will not stop until it wraps around and hits the next slice (in the forward direction) from the other side.

In other words, if you have 3 slices: A, B and C where B is the currently active slice. On a trigger, the play head will start at B and stop at C regardless of the direction. (Really it should stop at A when playing in the reverse direction.)

Ah wait! Now I remember what confused things. You need to have at least 2 slices in the sample. If you have only one then it uses the beginning of the sample as the “other slice”.

I’m going to play devils advocate and suggest there is no case M. Specifically, if you provide an EOC signal on a(n) (internal) buss, you can satisfy case M while working on the case S dominant use-case. (I say dominant since it fits better in the synced play paradigm of MIDI samplers.) If you allow EOC as a trigger signal, blam! Best of both worlds. $.02.