bart at max (also BITter)

a simple example list from an audio sample written in buffer~ by using peek~:

what i want to be able to is duplicate every index x times, so that i for example get:

So, the audio sample in buffer~ becomes longer with the same values.

This i want to keep and do in the MSP part.

a simple example list from an audio sample written in buffer~ by using peek~: 

index 1 = value 0.4
index 2 = value 0.2
index 3 = value 0.1
index 4 = value 0.01

what i want to be able to is duplicate every index x times, so that i for example get: 

index 1 = value 0.4
index 2 = value 0.4
index 3 = value 0.4
index 4 = value 0.2
index 1 = value 0.2
index 2 = value 0.2
index 3 = value 0.1
index 4 = value 0.1
index 1 = value 0.1
index 2 = value 0.01
index 3 = value 0.01
index 4 = value 0.01

So, the audio sample in buffer~ becomes longer with the same values. 

This i want to keep and do in the MSP part. 

duplicate-every-index-with-a-value-of-an-audio-sample-in-buffer

index 1 = value 0.4
index 2 = value 0.4
index 3 = value 0.4
index 4 = value 0.2
index 5 = value 0.2
index 6 = value 0.2
index 7 = value 0.1
index 8 = value 0.1
index 9 = value 0.1
index 10 = value 0.01
index 11 = value 0.01
index 12 = value 0.01

make a temp buffer of x-times the size of the source, and uzi the indexes (for offset 1 to x).

sorry i don´t have max installed right nowso i can´t provide code.

if your purpose is to timestretch, this won´t work hat way. for time stretch you duplicate no single samples but partitions.

make a temp buffer of x-times the size of the source, and uzi the indexes (for offset 1 to x). 

if your purpose is to timestretch, this won´t work hat way. for time stretch you duplicate no single samples but partitions.


You can also play the sample at 3rd speed and record it again, though it would sound much better than your method, because its interpolating in between...;-)

But why would you want to do that? It does not add information and needs 3 times the space...

If I read easy to patch questions like that I always have the impression that this could be a bad solution for a much simpler problem...

Just tell us what you want to do and why you think this is a solution...

If I read easy to patch questions like that I always have the impression that this could be a bad solution for a much simpler problem...
Just tell us what you want to do and why you think this is a solution...

about timestretch, i think the partitions are called "frames". you would need to program some interpolation (including some frame overlap handlings) to make it sound good.

there is [gizmo~] on the base of fft-interpretation, like most proper stretching algos. though not sounding great this will go easier than doing it all yourself.

"make a temp buffer of x-times the size of the source, and uzi the indexes (for offset 1 to x)."

Yes, i know but in realtime, these goes overload.

I need a kind of mathematicaly realtime "timestretch" and it doesn't have to sound good/clear.

"You can also play the sample at 3rd speed and record it again."

It's more about mathematicaly visualising the sound and experimenting to send that visualised sound again thru the speakers. :)

That's why i really want to duplicate every index x times and hear what results i get.

Not yet a patch, but thinking about it before i start to patch.

@xidance
"make a temp buffer of x-times the size of the source, and uzi the indexes (for offset 1 to x)."
Yes, i know but in realtime, these goes overload.
I need a kind of mathematicaly realtime "timestretch" and it doesn't have to sound good/clear. 

@stefantiedje
"You can also play the sample at 3rd speed and record it again."
Will take also too much in realtime. 

It's more about mathematicaly visualising the sound and experimenting to send that visualised sound again thru the speakers. :)
That's why i really want to duplicate every index x times and hear what results i get.
But this in a elegant and fast way. 

Not yet a patch, but thinking about it before i start to patch. 

just play the buffer~ at half/quarter speed - this would be the result, if you could get this "stretch" to work; it will shift the pitch down.

It's not a "timestretch", it is indeed a process that the objects themselves can already undertake.

--"You can also play the sample at 3rd speed and record it again."

Too much *what*? Pitchshifting is the easiest, most low-cost process there is, so I am assuming you mean it'll take too much *time* - in which case I'm not sure what you're expecting, really - you can start your low-pitched sound playing, and simultaneously record that into a different buffer~, and start playing that back immediately. So you'll only need to let it write a fraction of a second before you start it.

But even then it doesn't actually make sense; just tell sfplay~ "speed 0.5" or similar, and it'll happily chug along at this new "has more values" setting.

--It's more about mathematicaly visualising the sound and experimenting to send that visualised sound again --thru the speakers. :)

Can you tell us some more about this, because it's so not making sense to me.

just play the buffer~ at half/quarter speed - this would be the result, if you could get this "stretch" to work; it will shift the pitch down.
It's not a "timestretch", it is indeed a process that the objects themselves can already undertake. 

but:
  --@stefantiedje
  --"You can also play the sample at 3rd speed and record it again."
  -- Will take also too much in realtime.

  --It's more about mathematicaly visualising the sound and experimenting to send that visualised sound again     --thru the speakers. :)

Can you tell us some more about this, because it's so not making sense to me.
cheers.


Sorry, it seams that i have explained in a wrong way, forget mathematicaly. I need more sleep!

"just tell sfplay~ "speed 0.5" or similar, and it'll happily chug along at this new "has more values" setting"

Yes, but i want first to visualize this "speed" change and then send to dac~.

visualize in a simple way with [waveform~] or in Jitter like:

AUDIO wave original 2x duplicate every index

Sorry, it seams that i have explained in a wrong way, forget mathematicaly. I need more sleep!
It's more simple then i explained it. 

"just tell sfplay~ "speed 0.5" or similar, and it'll happily chug along at this new "has more values" setting"
Yes, but i want first to visualize this "speed" change and then send to dac~. 

visualize in a simple way with [waveform~] or in Jitter like: 

AUDIO wave original:
AUDIO wave original 2x duplicate every index


AUDIO wave original 6x duplicate every index

No other changes, only duplicate every index x times.

This value x i want to change often and in realtime.

On the complete AUDIO wave and later on parts of it.

No other changes, only duplicate every index x times.
This value x i want to change often and in realtime.

On the complete AUDIO wave and later on parts of it.


duplicate every index with a value of an audio sample in buffer~