james d

I'm trying to create a patch where a signal comes in, and then outputs that input slowed down by a certain percentage. I'd like it to sound equivalent to playing a file with sfplay~ at a speed < 1.

Is this possible? I tried using the tapin~/tapout~ doppler idea I saw in this video: 

https://www.youtube.com/watch?v=uyzY_ZP54pA

, but that preserves the original tempo it seems. I'm thinking there must be some way to write to a buffer~ and then read at a reduced rate, but I'm not sure how to approach this.

Please let me know any ideas, or existing forum topics/patches. Thanks!

I'm trying to create a patch where a signal comes in, and then outputs that input slowed down by a certain percentage.  I'd like it to sound equivalent to playing a file with sfplay~ at a speed < 1.

Is this possible? I tried using the tapin~/tapout~ doppler idea I saw in this video: https://www.youtube.com/watch?v=uyzY_ZP54pA, but that preserves the original tempo it seems.  I'm thinking there must be some way to write to a buffer~ and then read at a reduced rate, but I'm not sure how to approach this.

Please let me know any ideas, or existing forum topics/patches.  Thanks!

I'm trying to create a patch where a signal comes in, and then outputs that input slowed down by a certain percentage.  I'd like it to sound

slow-down-a-real-time-input

Think of time needed to capture realtime input

Some audio will get overwritten before it gets played back...

1 minute recording will be played only up to 30 seconds.


Think of time needed to capture realtime input
and output it at slower rate.
Some audio will get overwritten before it gets played back...
Let's say at 50% speed
1 minute recording will be played only up to 30 seconds.


Thanks for the patch! If I make the buffer and wave long enough, I think this would do for most use cases. Bridging the gap between write and read speeds is quite a predicament though. I still feel like it's possible, but I can't wrap my head around it.

Thanks for the patch! If I make the buffer and wave long enough, I think this would do for most use cases.  Bridging the gap between write and read speeds is quite a predicament though.  I still feel like it's possible, but I can't wrap my head around it.

There are some other approaches using delay line instead of a buffer outlined in this thread:

https://cycling74.com/forums/real-time-audio-sampling-manipulation-%22virtual-turntable-platter%22

There are some other approaches using delay line instead of a buffer outlined in this thread:
https://cycling74.com/forums/real-time-audio-sampling-manipulation-%22virtual-turntable-platter%22 

There are many options, depending on what You really want.

One can also separate recording from playback

or overdub into buffer to keep recorded samples

over more than 1 playback iteration and so on.

In simple record + play at slower speed combination

it will allways remain a problem of some part of audio being erased

before it's turn to be played comes arround.

There are many options, depending on what You really want.
One can also separate recording from playback
and offset them for delay time,
or overdub into buffer to keep recorded samples
over more than 1 playback iteration and so on.
In simple record + play at slower speed combination
it will allways remain a problem of some part of audio being erased
before it's turn to be played comes arround.


Slow Down A Real Time Input