matyas

Apologies if this has been covered elsewhere. I'm trying to find the best way to realize my musical goal for a piece I'm working on, involving realtime time compression of an audio stream.

The basic processing chain I'm envisioning looks like this:

I've been playing around with Timo Rozendal's excellent diracLE~ object for the time compression. It works and sounds great, but I'm kind of at a loss as to how to get the real-time audio stream into a buffer for processing. Using tapin~/tapout~ doesn't work. (I can change pitch that way, but not time.)

Recording into a buffer~ and trying to play from the buffer~ while still recording into it doesn't seem to work either.

To give a little more context, the piece I'm trying to set up a series of canons based on time compression. Each voice in the canon is delayed and time compressed proportionately so that they all end at the same time, along with the live singer whose voice is being processed. For example, assuming the piece is 10 minutes long, the first artificial voice may enter after a 1-minute delay, with the audio being time-compressed by 10%.

I suppose I could have a series of buffers~ that get triggered either automatically or manually and which replace their contents, but is there any good way to go with my original plan of a single large buffer that is written to and accessed continually? Note that I'm not looping audio.

Hello,
Apologies if this has been covered elsewhere. I'm trying to find the best way to realize my musical goal for a piece I'm working on, involving realtime time compression of an audio stream.
The basic processing chain I'm envisioning looks like this:

I've been playing around with Timo Rozendal's excellent diracLE~ object for the time compression. It works and sounds great, but I'm kind of at a loss as to how to get the real-time audio stream into a buffer for processing. Using tapin~/tapout~ doesn't work. (I can change pitch that way, but not time.)
Recording into a buffer~ and trying to play from the buffer~ while still recording into it doesn't seem to work either.

To give a little more context, the piece I'm trying to set up a series of canons based on time compression. Each voice in the canon is delayed and time compressed proportionately so that they all end at the same time, along with the live singer whose voice is being processed. For example, assuming the piece is 10 minutes long, the first artificial voice may enter after a 1-minute delay, with the audio being time-compressed by 10%.
I suppose I could have a series of buffers~ that get triggered either automatically or manually and which replace their contents, but is there any good way to go with my original plan of a single large buffer that is written to and accessed continually? Note that I'm not looping audio.

best-way-to-do-live-realtime-time-compression

Have you looked at the grainstretch external? It does pitch-independent time compression very well. With tapout I think you would need several of them and some complex maths to do repitching and compression in the time domain. And it's not strictly "realtime" if the compressed voices are delayed. Do you know how to write to and read a buffer? This sounds like an interesting project.

Hi
Have you looked at the grainstretch external? It does pitch-independent time compression very well. With tapout I think you would need several of them and some complex maths to do repitching and compression in the time domain. And it's not strictly "realtime" if the compressed voices are delayed. Do you know how to write to and read a buffer? This sounds like an interesting project.

iiiii, think, this might be achieved by having a constantly changing delay time, fed into tapout~ at signal rate.

Say you want to hear the first sample at minute 1 ; then the first delay value is of 60 seconds. Then, ten minutes later, the delay will be of 0 seconds - then you need a decreasing ramp controlling the delay that goes from 60 seconds at start to 0 seconds at end (ten minutes, or 600 seconds later). You could do that simply with line~ and tapin~/tapout~ (it will jsut be a huge amount of delay but should be possible).

I'm not sure though, iirc it's possible to workaround audio distorsions that will necessarly result from a constantly changing delay time, using tain~/tapout~, especially if it's changing slowly over 10 minutes ; but you gotta try...

iiiii, think, this might be achieved by having a constantly changing delay time, fed into tapout~ at signal rate.
Say you want to hear the first sample at minute 1 ; then the first delay value is of 60 seconds. Then, ten minutes later, the delay will be of 0 seconds - then you need a decreasing ramp controlling the delay that goes from 60 seconds at start to 0 seconds at end (ten minutes, or 600 seconds later). You could do that simply with line~ and tapin~/tapout~ (it will jsut be a huge amount of delay but should be possible).
I'm not sure though, iirc it's possible to workaround audio distorsions that will necessarly result from a constantly changing delay time, using tain~/tapout~, especially if it's changing slowly over 10 minutes ; but you gotta try...


Thanks for the tips. I probably didn't do a very good job of explaining a few things and where exactly my hangups are.

First of all, I did forget to mention that I will be using a a continuously decreasing delay. As Vichug points out, there may be a possibility for some audio distortion. I'm not quite sure how to solve that problem yet.

I have tried grainstretch~. The issue is that both grainstretch~ and diracLE~ seem to require the output of a buffer~ to do time compression/expansion. The way I've always used buffers in the past involves recording into the buffer~, stopping the recording, and then playing back the buffer. I was envisioning having something like a constantly running buffer that basically never stops recording. I know that's more or less what tapin~/tapout~ does, and for whatever reason I can't seem to get diracLE~ (or grainstretch~) to perform time compression/expansion on the streaming output of a tapin~/tapout~ pair, even with a substantial delay. Why buffer~ works and tapin~/tapout~ doesn't is kind of a mystery to me.

So my new plan is to have a series of buffers that get written to and played back sequentially. There will still be a tapin~/tapout~ pair somewhere in the signal chain (probably before the buffers)

Thanks for the tips. I probably didn't do a very good job of explaining a few things and where exactly my hangups are.
First of all, I did forget to mention that I will be using a a continuously decreasing delay. As Vichug points out, there may be a possibility for some audio distortion. I'm not quite sure how to solve that problem yet.
I have tried grainstretch~. The issue is that both grainstretch~ and diracLE~ seem to require the output of a buffer~ to do time compression/expansion. The way I've always used buffers in the past involves recording into the buffer~, stopping the recording, and then playing back the buffer. I was envisioning having something like a constantly running buffer that basically never stops recording. I know that's more or less what tapin~/tapout~ does, and for whatever reason I can't seem to get diracLE~ (or grainstretch~) to perform time compression/expansion on the streaming output of a tapin~/tapout~ pair, even with a substantial delay. Why buffer~ works and tapin~/tapout~ doesn't is kind of a mystery to me.
So my new plan is to have a series of buffers that get written to and played back sequentially. There will still be a tapin~/tapout~ pair somewhere in the signal chain (probably before the buffers)


I'd go with vdb's for this. I've done work with time compression there, and it just worked so well.

I don't think you'll ever do away with audio distortion; it's time stretching, after all, but variable delay buffers handle these things surprisingly gracefully.

(it also helps that they do away with the need to record to buffer~s, expensive granular stretching and so on)

I'd go with vdb's for this. I've done work with time compression there, and it just worked so well. 

(it also helps that they do away with the need to record to buffer~s, expensive granular stretching and so on)


Best way to do live, realtime time compression