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
<[email protected] <mailto:[email protected]>> 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
<[email protected] <mailto:[email protected]>> 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
<[email protected] <mailto:[email protected]>>
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
_______________________________________________
[email protected] mailing list
UNSUBSCRIBE and account-management ->
https://lists.puredata.info/listinfo/pd-list
