Sample Recorder/Sample Player shared buffer (clicks, polyphony from a single oscillator)

Hey all!

I am using the sample recorder to continuously record a fundamental drone from an input source osc (dixie), referencing that same buffer with a (looping) sample player next in the series, and using external pitch cv (uO_C) on the sample player v/o control. My goal is to create a four-voice canon using only one ext. oscillator. Can’t seem to rid what I assume are non-zero crossing clicks from the sample player as it resets its loop (I thought fade would address this?). Can post a video, but wanted to throw this out there in text first. Thanks!

This is a known issue. :wink:

  • Discontinuous playback when playing unit shares buffer with another recording unit (play/record head leapfrog bug).
1 Like

Thanks! Should have checked there first. Considering this approach is useful for getting more mileage out of one oscillator, how about a unit which acts as a nest for an oscillator source…something like a mixer but with v/o control? Would cut down on 8x samplers and 4x buffers in this particular case.

Inspired by that Strymon Magneto demo? :thinking:

1 Like

Haven’t seen it yet!

EDIT: I used this approach for my last live set earlier this month, but in retrospect I must have applied enough effects after the sample player that the discontinuous playback was masked.

Ah, well not to completely derail your thread, but this is what I was thinking of:


Wow, that’s impressive! I recently got a uO_C and that is what made me think of trying this approach. I suppose a shift register is a delay anyway, though the strymon result is a bit different in that it outputs stereo audio, vs four discrete cv outs in the case of the uO_C.

Magneto is looking pretty good - thanks for digging that clip up! :slightly_smiling_face:

And now that my brain is turning a bit, and to extend this idea a little further: what about the ability to reference the location of an internal oscillator source (“Global Oscillator”)? Depending on the patch, that could cut down on CPU a great deal.

Put the oscillator unit into a global chain?

1 Like

Thanks #2! I may need some help visualizing this solution completely (currently on a train headed home) - an internal oscillator’s v/o can only be addressed on the oscillator unit itself, right? I may I have some brushing up to do on global chains…:zipper_mouth_face:

As far as I can tell from my vantage at present, the solution for polyphony from a single external oscillator requires the sample recorder/sample player combo. Am I correct there? If so, I would (very humbly :slightly_smiling_face:) put in a request for a sort of small footprint mixer/nest unit for an IN/ABCD source which responds to pitch cv, unless of course it is in your best interest to address the discontinuous playback between recording and playing samplers (and if global chains do not present a solution) Thanks @odevices!

I have spent quite a bit of time trying to do exactly this, @tomk. It’s interesting that @odevices is calling the play/record head crossing a “bug” now whereas I was going to call it more of a “miracle” if he could somehow solve it. :slight_smile:

You can minimize the artifact by making your sample buffer pretty long. 10 sec, 30 sec? The trade off of course is that any changes you make to the external oscillator will have that much latency before they reflect in what you’re hearing. I also found that it helped if I un-punched the recorder when I was happy with the timbre. I think then the only arifact you get is the jump where the start and end of the recording don’t quite match up and the waveform sample has an abrupt jump in value. Which is weird - I would think that would basically be the same thing as the play/record heads crossing but for some reason it seemed to help…

Oh, and of course more complex timbres tend to mask it more than pure/clean ones.


One more thought. This is likely already obvious to you, but just in case - this is what actually works for now.

Record the external OSC and save the buffer. Slice or trim it so that your slice or file becomes one single cycle of the waveform. I actually did this in DAW but I think all of the facilities are here now in 0.3 to do this right inside the ER-301. Either trim or use slice marks in sample player and use the index to select the correct slice. Then you can have X number of sample players playing the sound of your external OSC at different pitches.

It’s no longer a real time thing at that point, of course.

1 Like

Thanks for the input, @joe!

Right there with you on this one, and you’re right the latency can be a downside depending on what is desired.

Cool - I will definitely try this!

Here’s where my audio knowledge might fall a little short: are they ever crossing if the buffer size and playback speed are the same between both units?

In retrospect, this is why the approach has “worked” for me in the past. I was using a complex waveform treated by a series of effects.

When you change the pitch (change v/o) in the standard sample player, you’re speeding up or slowing down the playback speed relative to the recording speed. So that’s why they cross. If you pitch up the play head starts running circles around the record head. The higher the pitch, the faster this happens and the more clicks you get. You can actually watch it in the sample player. Set the V/O to a root note and then set it a lot higher and watch the play head speed up.

Changing the pitch with the grain based sample player is a bit different, but granular has its own set of artifacts.

1 Like

Ahh right right right, that makes sense - which explains why the artifact doesn’t occur in the same place when visually monitoring the player buffer via scope view. :+1:

1 Like

In retrospect, the “improvement” when unpunching might have just been the result of getting kind of lucky with my punch in/out point. Hitting at a place where there was not a big jump in the sample values.

1 Like