I found a way to get sound into an array without setting the size manually in before. I looked for it on here before and couldnt find anything so i thought i'd share.
The trick is to send the sound into a delay line and have a counter increase the time of the delay in realtime, so the signal is held up in the delayline. when the recording is stopped the array is reset to the current value of the counter and the audio is played back into it. I tried to explain it in this patch.record_array_example.pd
hope it helps, have a wonderful day.

Nice one!

Thinking twice, since you have a fixed buffer with [delwrite~] and since you can send the message "stop" to [tabwrite~], why not have a table that can hold up to one minute of audio, and when you want to stop recording send [stop( to [tabwrite~] and calculate [phasor~]'s frequency according to the milliseconds you recorded?
This patch does essentially the same thing, and uses only one table and no delay line arbitrary_rec_length.pd

it comes in handy for looping stuff i find. also its easier on memory

why easier on memory? eventually you save the audio to an array, plus you reserve memory for the delay line..
Also, what's wrong with looping if no delay line is used? Looping occurs by reading the table with [phasor~], in both implementations.

Here's the way I've been doing it. extendingrecord.pd

@sunji said:

Here's the way I've been doing it. extendingrecord.pd

I like this solution, it's simple and effective, but the sound clicks and glitches everytime the array resizes. I've tried to put the array in another patch but didn't help...

Is there any solution to this problem?

Keep in mind that resizing an array necessarily will rebuild the dsp graph. This means:

1. dsp is suspended
2. Pd sorts all the signal objects in the running Pd instance so that each will receive its input before generating output
3. once finished, dsp is restored to whatever state it was in before

The reason this must happen is because all of the array handling signal objects like [tabread~] and others cache the array and its size so they don't have to look it up every dsp tick.

Now, if you have audio running and you resize the array, Pd needs some way to immediately tell all the table-related objects the new size. For example-- suppose you are shrinking the array. If Pd doesn't update the relevant objects to cache the new array size, a signal object may try to index past the end of the array. This would end up causing a crash in Pd. (Not to mention that a resized array might live in a new location in memory, but that's another story.)

So the question is-- how does Pd immediately tell all the table-related objects which have cached a particular array that you've just resized that array?

Unfortunately, Pd's internal API doesn't have a standard method by which to update the array/size for table-related classes. The only required method it has is "dsp" which adds a signal object to the dsp graph. Most of the table-related objects have a "set" method, but it's not required and I'm not sure if every external array-handling class has one.

That means the only way to tell the table objects to update their array size is to trigger their "dsp" methods. And the only way to do that safely is to rebuild the entire dsp graph. So that's what Pd does.

Anyway, the rebuilding happens all at once. So if your patch is pretty small Pd might be able to sneak a graph rebuild into a single dsp tick on schedule and avoid dropouts. For larger, complex patches it's probably impossible to avoid dropouts. (Plus who knows what the worst-case time is for allocating memory for a large array.)

@jancsika I see, that's exactly what happens, even the console gives me an I/O error when the sound is suspended during the resize calculation. So, knowing that resizing an array in the fly will give dsp suspensions, is there any way to record an array continuously extending its size while the audio is recording?

I've tried using writesf on a premade sound file and I can record without supensions indefinitely, but I need to loop the recording just after recording it, so the interruption in this case happens when the file has to be opened and written into an array.

@JackPD Do you really need to support an arbitrary-length array? Is there really no maximum length to the content you will be recording?

@JackPD Do you need to write it to an array for the looping, after using [writesf~]...?
It depends whether you are simply playing the sample (or part of it) repeatedly forwards at normal speed again?
[readsf~] will loop it, and will take an onset as well if needs be. You could use a timer to set an endpoint too.
I don't think it should be true with an ssd that you "must open the soundfile in advance (a couple of seconds before you'll need it)" as it says in the help file (pre-2009?). It seems be pretty much instant nowadays.
David