Polybuffer~ behavior
I'm making a polyphonic sampler that allows me to record a live input into a regular buffer~ object, then the contents of the buffer are copied into a slot in a polybuffer~. Everything in the patch works perfectly except when I am recording while playing back other previously recorded slots of the polybuffer~. It seems as though when I modify a polybuffer~ slot, it will affect the other slots causing a glitch if they are playing.
Is polybuffer~ then just one long buffer with some extra controls? How do I manipulate certain slots of the polybuffer~ while not affecting the others?
Copying audio from "regular" buffer to polybuffer could maybe
produce that glitches.
Recording into one buffer, while
playing back from another buffer should not do so.
Yes, it was the copying. It caused my cpu to spike to 100 while audio was on.
Maybe You can drop copying the buffer alltogether.
and simply change recording head to any buffer
using set message.
By the way how do You copy between buffers ?
Yeah, I've since abandoned the copy buffers approach, I was using a very rudimentary method with peek~ and uzi.
The goal of this patch is to create similar functionality as the sp404 hardware sampler but with the added functionality of live sampling/resampling and other features. I'm already passed most of the sp functions (contextual parameter controls based on the last pad pressed, different triggering modes such as gate and loop), but struggling to incorporate live sampling without to many clicks or too much cpu usage.
Each pad, or key, is assigned to a sample. I want to be able to overwrite the sample with a live recording that is of arbitrary length, even if that sample is being played back. I'm know trying to implement a 2 polybuffer system, where, if a new sample is recorded to a pad that is playing back, then the new sample will be recorded to an adjacent buffer and crossfaded in.
Is such playing buffer going to be overwriten in real time
without stoping playback ?
That would be tricky, because new loop size will be different,
and might sound strange when end of new recording
cuts the old loop at some strange point...
Can be done, no problem, but mignt not sound really ...
If Playback stops when new reording takes places - (the "usual" way)
then all is easy.
I don't think You need 2 polybuffers, I would use only one buffer for recording
and copy the recording to dedicated buffer for playback.
Only using something else than uzi peek, because that is a problem
while playing back.
My best choice is el.buffet~ from e.lyon, but maybe it is not working on
max 8, I don't know.
There are other options, like using duplicate or set messages to buffer.
I never used polybuffer for looping, rather dedicated buffer for each loop
so I can't tell how polybuffer reacts when copy takes place.