Hi. I have 8 looping arrays, they're all sized 65535 (so 64kb each). They have fades at the start and at the end.

My question is this.

I would like to (have control of the) offset of playback.

So, let's say I have a plucked melodic sound in two arrays. The pluck-sound starts right at the beginning of the array.

I would like to de-sync them (they would currently play at exactly the same speed, so both plucks "pluck" at the same time).

I would like to offset the other. How would I go about doing that? This would let me "kind of" do tape looping where they keep triggering but so that they are slowly going off sync.

Since you're using [tabread4~] its as simple as adding a [+~] after the [*~] object. Whatever integer you add to the scaled up ramp will be the offset. But you'll have to deduct it from what you're multiplying with (number of samples). Which will give you another sync problem. And if you compensate for it by changing the frequency of the ramp you'll have an out of tune problem.

Sooo, best way is to add the offset as a fraction (offset in samples / total samples) then run the ramp through a [wrap~] before you scale it up with the multiplier. Like this:

[phasor~][/~] <- offset/length
|/
[+~]
|
[wrap~]
|
[*~] <- multiply by sample length
|
[tabread4~]

Voila

hmm, so i would be adding the offset length and +~ and wrap~ and then continuing with the *~ 65536, right?

hmm.. thing is.. and i might be doing this wrong now, but everytime i move a knob, this causes audible clicks

i'm taking input from [p8-offset] which sends 0...1 and after that i tried to create what you suggested but maybe i misunderstood

@esaruoho You will be jumping to different signal levels which will always produce clicks.
The easiest solution is to duck the audio while you change the knob.
.....[line~]
.....|
[*~]
As [line~] is signal rate you can duck and come back again very fast. 5msec might be more than you need.
David.

@whale-av said:

The easiest solution is to duck the audio while you change the knob.
.....[line~]
.....|
[*~]
As [line~] is signal rate you can duck and come back again very fast. 5msec might be more than you need.

Thanks! although i'm not entirely sure where to put it, because it outputs signal and only takes in numbers

@bocanegra said:

Since you're using [tabread4~] its as simple as adding a [+~] after the [*~] object. Whatever integer you add to the scaled up ramp will be the offset.

so.. just to try and make sure i understand what you're saying..

you're telling me to add a
[+~]
after the
[*~]
object, which is currently the
[*~ 65536]
object, right?

@bocanegra said:

[phasor~][/~] <- offset/length
|/
[+~]
|
[wrap~]
|
[*~] <- multiply by sample length

[*~ 65536]
right ?

if i understand right, is this kind of what's going on, but apart from the [/~] being connected to the [+~], right?

so now, i'll have to do something so that the [r p8-offset] (which is 0...1) can be used to offset the numbering. i'll try and do it so that i multiply the p8-offset with [* 65536] and then put that into the [+~] and hope for the best..?

@esaruoho Yup. That should do the trick.

@esaruoho Use it to duck the signal output of a particular sampler while adjustment numbers are coming in.
Something like.

For the onset, yes, you are correct.
The [phasor~] is outputting a sawtooth ramp. 0 >> 1 jump to 0..... 0 >> 1 again, at a frequency that is the length in time of you sample.
Its output is multiplied by the length of your sample in samples (+3 due to the cubic interpolation) so that it reads all the samples in that time.
When you add a number to the output of [phasor~] you shift its output by that number...... so when it sends zero [tabread4~] gets 0+ your number...... and starts the sample playback there.... the onset.

The sample to be played is now shorter, but you want it played at the same speed (values coming in at the same rate), and to stop when [tabplay~] receives the number [65536]....... and start again.
[wrap~] does that for you.

But it is better to use the onset inlet of [tabread4~]...... see B15.tabread4~-onset.pd in the doc folder.
David.

@bocanegra said:

@esaruoho Yup. That should do the trick.

i must still be doing something wrong. i start twisting a knob, and i hear a kind of bitcrushing effect...

if i get to 0 with the knob, then the sound is okay. if i get to 1 with the knob (0...1 [* 65536] and then [+~] before [wrap~] - the sound is hyper-bitcrushed..

@whale-av said:

The sample to be played is now shorter, but you want it played at the same speed (values coming in at the same rate), and to stop when [tabplay~] receives the number [65536]....... and start again.

hmm.. i'm not looking for the sample to be shorter, i'm looking for the sample to be the same length (65536) yet start at, say, "at halftime" of the sample, so if i have two sounds going

[tschii]
and
[tschii]

then the other one plays [chiits] .. hmm..

@esaruoho said:

@bocanegra said:

@esaruoho Yup. That should do the trick.

i must still be doing something wrong. i start twisting a knob, and i hear a kind of bitcrushing effect...

if i get to 0 with the knob, then the sound is okay. if i get to 1 with the knob (0...1 [* 65536] and then [+~] before [wrap~] - the sound is hyper-bitcrushed..

Leave out the multiplier on the offset. The ramp goes from 0 to 1. The wrap module wraps around 1.

But you will hear clicks and stuff changing the offset realtime regardless, unless you do the ducking whale suggests

@esaruoho said:

@whale-av said:

The sample to be played is now shorter, but you want it played at the same speed (values coming in at the same rate), and to stop when [tabplay~] receives the number [65536]....... and start again.

hmm.. i'm not looking for the sample to be shorter, i'm looking for the sample to be the same length (65536) yet start at, say, "at halftime" of the sample, so if i have two sounds going

Sorry, I should have been more precise "the part of the sample to be played is now shorter".
David.

@bocanegra said:

Leave out the multiplier on the offset. The ramp goes from 0 to 1. The wrap module wraps around 1.

hi, i realizd that there was no reason for me to do any multiplication on the knob input (p8-offset) because it already sends 0...1 so for that to be multiplied by 65536 was useless.

now all i need to do is smoothen the output so it doesn't click. that's next:

thanks for all your assistance thus far! i'll see what whale suggested next now that i can verify that there is an offset occurring in this

@whale-av said:

@esaruoho Use it to duck the signal output of a particular sampler while adjustment numbers are coming in.
Something like.

hmm.. did i get this right? that.. if the sampler receives offsetnumbers, just close the volume out of that sampler and then when it stops, return it back? so in this case, first set [*~]. to 0 for 5 ms (?) then delay 5 ms, then set it back up to 1 in 5 ms?

@esaruoho That is the idea. You could try less than 5msec. It needs to ramp in a time that is not perceived as a click. As you are (almost certainly) jumping on onset to a value that is not zero you need to ramp to it.

Also you might have missed in my previous post that if you are using long samples you should use the double-precision onset inlet of [tabread4~] rather than shifting the phasor, and you could of course use it for all your samples.
David.

@whale-av

i'm using 64kb samples for everything, all arrays are 64kb of size..

i'm now getting a "silence" which then stops and the sound fades back in, when moving a knob. sometimes it crackles, sometimes it doesn't. i wonder how i could make this better.

@esaruoho It gets more complicated then. But not too much.
You will need to use [samphold~].
There is an example F09.declickit.pd in the doc folder.
David.

@esaruoho PS....... you are not using [line~]..... you are using [line].
With [line~] it should be fine.
You will need to remove the "1" from the [*~ 1] of course.
It is very hard for us to test, communicate or make corrections unless you upload your patch...... and extremely hard to spot any errors.
Try this....... Microsound-granular.pd ........... if you get clicks then there could be a different problem..........
David.

@whale-av said:

@esaruoho PS....... you are not using [line~]..... you are using [line].
With [line~] it should be fine.

thing is, where would [line~] be connected to? directly to [+~] or to [tabread4~]?