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