sampler as buffer/stutter effect?

[soundmind]

I am trying to use sampler as a live buffer looper but i am having problems. First of all when using a seq switches output to activate the record button the recorded loop in the sampler is not the same size (speed) on every pass as the length of the on value from the seq switch. I cannot explain this behavior because it seems to happen randomly. what i am ultimately trying to do is use the sampler as a buffer/stutter effect with a user definable loop length (1/8, 1/16, etc.) to be triggered on each seq switch on and the loop length modulated by a step module. Is there a right and a wrong way to do this? no matter what i try i cannot get consistently accurate timing with the loop. Is there some kind of wait one cycle patch trickery that i am not aware of to make the samplers behave like a tempo synced stutter effect? let me know if more infos are needed. thanks.

[soundmind]

bump! i know there is at least one master on here that knows how to do this!

[gurulogic]

I know I have noticed some subtle timing/sync indescrepencies in the sampler but I'm not sure this would be the same thing you are experiencing. Have you thought about optionally using delay modules to create this type of effect? It seems like it should be possible...

[23fx23]

hi soundmind,
well it can sound frustrating and strange, but im quite sure this is related to the numeric bloc world.

Sampler rec lenght can change cause of the bloc size pb we saw before, the REC being activated/desactivated on a bloc clock.
As related to some tempi, some trigger lenght won't fit an integer nb of blocs, especially with large bloc size, so at some point a roundind in time occurs, and can change the lenght. if you try @ 161.50 bpm, the clock will be never drifting for exemple.
so solutions to get lowest possible drift is to have lowest possible blocsize, combined with a fine tuning tempo.
in any case triggerz are always related to bloc size and master tempo, so im affraid it's a natural limitation that can't be solved/bypassed, execpt this way.

but if you can be in a 32 bloc size there is certainly a 'magical' tempo really close to yours that should fix the pb.
will look if i find back my 'fiting the matrix tempo' calculator...

[nay-seven]

yep , could be cool to have a kind of rules to know for this kind of situation.
i also know an other example where the guy record 2 second of sample , play in loop mode = ok , then record again,but 5 second for example , and this time , not always , the play don't begin correctly at the start of the sample
i think it's the same kind of situation..

[23fx23]

ok, i found back my patch and enhanced a bit.

basically can choose a precision factor from bar to 1/256th, and it returns all tempi that will fit the bloc matrix, linked to usine running blocsize.
if choosing in the list the bpm closest to our usual Bpm should theorically higly reduce/bypass the problem, maybe if some could try and report.. at least here my tests return much stable results-see no drift whereas any other tempo does.

lower blocsize and precision are, higher number of tempi choices and vice_versa.

http://sensomusic.com/forums/uploads.ph ... po%20c.wkp

[23fx23]

deleted reuploded now can clic on tempo to direct apply to usine, avoid typing

http://sensomusic.com/forums/uploads.ph ... o%2001.wkp

[soundmind]

Thanks very much for the replies. Usine would be perfect for this behavior but i see that we are once again limited to the bloc size precision. I will definitely try your patch 23fx23 and report back. gurulogic: yes i think you are right about the delay method. looks like this is the only way to reliably achieve this. maybe in the future there will be the 1 block super usine that exists in our dreams! imagine the possibilities. thanks for the help.

[nay-seven]

Thanks 23fx23, if you 're ok, i could add this patch to the next Utils pack..?

[23fx23]

yup no pb nay!