In my click tracker I use [array set] to generate the resulting audio in 3 tracks (3 sources), and then zexy's [.] for amplitude scaling and iem_tab's [tab_add] to join all 3 tracks. iem_tab has also lots of other interesting things.

But that's all copy-paste, no audio processing (except with [.] )

this sounds interesting. i've also successfully written to an array. i've always liked this idea, it makes no sense to compute something over and over again if you already know what's going to be computed. playing back a bit stream from RAM is always going to be faster. 

i can have some fun with this and i know exactly the application to use it for as i've (ab)used this sort of "render to sample" feature in Renoise. 

On Mon, Aug 17, 2020 at 12:48 AM Alexandre Torres Porres <porres@gmail.com> wrote:

I'm having so much fun, thanks!

working on a "batch record" abstraction now :)

I'm only now frustrated I can't batch record myself playing live, for like, 5 minutes... maybe Miller will figure out a way of doing so in 0.52 :) 

Em dom., 16 de ago. de 2020 às 21:54, Christof Ressi <info@christofressi.com> escreveu:

Hey,

but I still needed an example to see how to make this happen :) 

Attached you find a simple example for recording N ms of sound to disk.

that's used n the help file of [samplerate~] but I agree it should also be included in this new documentaton section. Anyway, what else would you use it for?

It's useful for preventing "angry vline~s": if you accidentally keep sending messaes to a [vline~] while DSP is off, it will eventually bring Pd to its knees. The solution is to use a [spigot] which is opened on "pd-dsp-started" and closed on "pd-dsp-stopped".

Actually, the issue should be mentioned in vline~-help.pd, together with the possible solution.

Christof

On 17.08.2020 02:25, Alexandre Torres Porres wrote:

On 16.08.2020 05:52, Miller Puckette via Pd-list wrote:
> An artificial example (for simplicity) - I want to apply a Pd effect to a
> soundfile and write the result out to another file, without having to wait
> for the length of the file to get the result.  This could be done from the
> command line using a batch command, but while you're developing the patch to
> do it it's much easier to be able to set the process off with a button from
> inside Pd.

Great, kind of what I was expecting, but I still needed an example to see how to make this happen :) 

Em dom., 16 de ago. de 2020 às 08:16, Christof Ressi <info@christofressi.com> escreveu:

My use case was that I had a patch which either produced some generative
music or processed some soundfile and I wanted to record N seconds as
fast as possible. It's basically like the render function in a DAW
(usually you don't have to start the DAW from the command line to render
your project :-).

I also thought about that and I'm really excited to test both things. Hopefully I can have an example of this in my tutorial rght now and release an update. But my attempts here failed and froze Pd :) 

Have you already messed with it, Christof?

 

But I agree that this needs to documented. Generally, there should be a
section to document all (public) Pd messages, like [pd dsp(, [pd quit(,
etc. (What can be considered "public"?)

I opened an issue for that ( https://github.com/pure-data/pure-data/issues/1125 ) and can take care of it as I'm usually handling documentation issues.

 

Also [r pd-dsp-started] and [r pd-dsp-stopped], which most people don't
know about, I guess.

that's used n the help file of [samplerate~] but I agree it should also be included in this new documentaton section. Anyway, what else would you use it for?

 
Porres