[PD] Pd as a plugin: concept shift with JACK freewheel

[Chuckk Hubbard]

I think that sounds great.
It's not going to stop me wanting the ability to use Pd as a VST plugin in
which I can load and control other VST plugins. So I agree with all but the
"instead of" part.
I'm currently trying to do basically the same thing, but cross-platform.

Chuckk


On Tue, Mar 12, 2019, 11:14 AM Lorenzo Sutton <lorenzofsutton at gmail.com>
wrote:

> Longish post inspired by the recent discussion about 'Pd as a VST plugin'.
>
> TL:DR: better use a modular JACK (freewheel) approach compared to more
> 'static' Pd as a plugin approach.
>
> I think that on systems with JACK Audio [1] (Linux mostly, but available
> on other platforms, albeit maybe not so common nor supported), it would
> be great to have solid JACK Freewheel [2] support instead of trying to
> embed Pd as a plugin in rather cumbersome, diverse and (probably)
> unstable, ways.
>
> Actually JACK freewheel *does* work with Pd on Linux (audio only) with
> the [jackclock] external by Nicolas Bouillot [3] also used to interact
> with jack transport, although currently a bit cumbersome if interacting
> with other applications. What's the big deal? Freewheel is 'faster than
> realtime', meaning that when activated audio will be generated as fast
> as the CPU can. The key use case is generating audio to a file at the
> same time avoiding things such as xruns or other problems due to
> real-time operation. If you've ever used Ardour  [4] and exported audio,
> it is using JACK freewheel (and in fact you see the playhead moving
> forward faster than realtime as it processes audio...).
>
> Now imagine instead of having Pd as an LV2, VST or whatever plugin in
> Ardour, you have your patch(es) open in usual Pd, connect tracks or
> busses to Pd, reconnect [dac~] to Arour's master et voilà :) - when you
> need to export you just run with freewhel mode.
>
> Indeed, I _was_ already able to connect through JACK an Ardour audio
> output to Pd with some simple audio processing, and then, after
> activating freewheel mode with [jackclock], 'record' the output to a
> .wav file through both jack_capture and [writesf~] internally (the
> former more interesting for this use case).
>
> So, just to shift points of view, IMHO strong JACK (maybe including JACK
> midi) and JACK freewheel support is somewhat more desirable in Pd
> compared to support for the many plugin types and platforms. If one
> thinks about it this is more in line with Pd's modular and dataflow
> approach, also in the long run might be more resilient to plugin format
> changes, license changes (see VST problems), as well as updates in Pd
> itself.
>
>
> Lorenzo.
> PS. Disclosure: this is not my first post advocating a freewheel
> approach in the (Linux) audio ecosystem compared to monolithic do-it-all
> audio software, but just as a user :) [5].
>
> [1] Jack Audio
> [2] Jack Freewheel in the JACK API:
>
> http://jackaudio.org/api/group__ClientCallbacks.html#gae797e2cde20faecb9be510c8873fbdd6
> See also this interesting section in Louigi Verona's 'Linux Audio
> workshop':
>
> https://louigiverona.com/?page=projects&s=writings&t=philosophy&a=philosophy_linuxaudio#2
> [3] https://github.com/nicobou/pd-jackclock
> [4] https://ardour.org/
> [5] See e.g
>
> http://linux-audio.4202.n7.nabble.com/JACK-Freewheel-mode-thoughts-td102077.html
> and
>
> https://www.mail-archive.com/rosegarden-user@lists.sourceforge.net/msg02632.html
>
>
>
> _______________________________________________
> Pd-list at lists.iem.at mailing list
> UNSUBSCRIBE and account-management ->
> https://lists.puredata.info/listinfo/pd-list
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.puredata.info/pipermail/pd-list/attachments/20190312/de10c0ad/attachment.html>