Hi!

I made this patch, whose purpose is to write sound to a buffer, then play it on loudspeakers and record it with a microphone, again and again... at this point maybe some of you will guess the name of the piece it will play

First question: can I write to the same buffer I'm reading? This patch works, but there is a CPU peak on each play/record. One of my device crashes sometimes (ULN-8), the other not (RME UCX II)

Second question: the "loop" can last between 30'' and 2'', so the initial array should be at least 48000 * 120 (after the first iteration it will be resized), but PD warn me it's about to create an array with {a lot of} points! (with some xruns in jackd). So what's the problem with creating a 2' array?

Thank you for your help!

ImSitting.pd

A long delay line with feedback may be a more efficient way to implement this.

hjh

Thank you hjh,

not sure to understand, where goes the delay?

@Blindekinder In case @ddw_music has passed his bedtime......
[delwrite~] and [delread~]
See their help files, and start again.
Here is one I made a while ago for the same purpose in live performance...... which will probably throw errors because it uses some externals.....
loop.zip
You can grab the externals in Pd through Help... find externals.
Don't run the .bat files..... they will be incorrect for your setup... !
Turn off the click if you don't need it..... we use it to keep the musicians synced using in-ear monitoring.
Or make your own using just the delay line with feedback that you will find in "the_loop.pd"
David.

Actually I was wrong -- in the famous Lucier piece, the feedback occurs in the air! So there is no need for it in software.

The goal is to record audio, and then play it back /n/ seconds later.

During the subsequent playback, new audio is recorded, to be played back /n/ seconds later.

The easiest mechanism for this is a circular buffer, of which a delay line is the simplest implementation.

During the initial reading of the text, the source audio comes from the mic input... and during the loop-backs, the source audio comes from the mic input... so there isn't even a need for any fancy switching.

[adc~]
|
[delwrite~ lucier 121000]

(and)

[delread~ lucier 120000]
|
[dac~]

... and tune the audio system to avoid blowups and it should be ok. (Untested though.)

hjh

Thank you both!

I rewrote the patch with delwrite~, it works perfectly, at least in the room i'm sitting in. We perform saturday, I'll tell you how it went.!
I put some filters plugins on the microphones inputs and speakers output, so I can manage frequencies.
Screenshot_20230330_145116.png

The piece was really nice.
I used a neumann canon MS at 1m of a small Genelec monitor, and the original speech was recorded with a DPA headset. I raised the quadriphonic PA up slightly during the performance. I killed the too resonant freqs with an eq on the mic input.

Thank you for your help!!

there are various reasons why it would be a dumb ides to use the same buffer for reading and playing, not only technical ones releated to the pd object.

@Obineg said:

there are various reasons why it would be a dumb idea to use the same buffer for reading and playing...

That's exactly what a circular buffer does, which is the basis of delay lines. It's perfectly fine as long as you take care not to collide the recording and playback positions. This is guaranteed in a fixed-time delay line because the recording and playback positions move at the same rate -- representing them as lines, they are parallel and thus can't intersect. Even modulating the delay time, it's not hard to find the boundary and avoid crossing over. You can even do a granular delay using delwrite~ and delread4~ (not my original idea -- works a treat though).

In Pd vanilla, circular buffers are delay lines, period, no other option. Allowing externals, I think there's also ipoke~ but scaling the phasor up to the buffer's number of samples is inexact; I don't trust that way.

hjh

@ddw_music

that´s why tapping buffers do exist: because you cant do the same with the regular buffer object.

using a tapping buffer is probably more work (think of all the logic needed to find the right record position, size the buffer, restart the next round) and more risky (no chance to save your work in progress?) compared to using simply 2 different buffer objects alternately. (you just give them the size of your loop and alternate play and record commands at sample 0)

@Obineg said:

that´s why tapping buffers do exist: because you cant do the same with the regular buffer object.

Actually, in SC you can do it with a regular buffer, because it has a Phasor suited to the task (and you use LFSaw for a pd-style phasor~).

using a tapping buffer is probably more work (think of all the logic needed to find the right record position, size the buffer, restart the next round)

I think all that's required is that the delay line max size is longer than one cycle -- bang a timer once at the start, and once for the second cycle, and let this set the delay time. Then it runs on autopilot after that (at least for the Lucier piece).

(no chance to save your work in progress?) compared to using simply 2 different buffer objects alternately.

That's fair -- if you need to save an intact buffer, two buffers would be the way to go.

hjh