[Ardour-Dev] out-of-process plug-ins

Paul Davis paul at linuxaudiosystems.com
Wed Jan 30 06:25:35 PST 2013


On Wed, Jan 30, 2013 at 9:02 AM, Nedko Arnaudov <nedko at arnaudov.name> wrote:

>
> What about designing "plugins" that can run either in-process or
> out-of-process?



AFAICT that implies either a new plugin API or use of a plugin host, and we
already have the latter.

If the multiclient app support in jack is improved,


i don't see how multiclient app support is relevant here.


> jack
> can route either "plugins" or "apps". The system can be even designed so
> that the plugin/app mode is switchable on the fly, without single xrun.
>

i think this displays a certain simplification of what plugin hosting
actually requires in the real world.


> It is true that it is good to have bugless software, but the reality is
> that bugs will always exist and the system can be made less error
> prone.


errors are one thing, bugs are another. bugs exist in many of the thousands
of win/VST plugins out there, and the majority solution to this problem is
a simple one: people stop using them and/or become very aware of what
triggers the bug(s). having developer A create a somewhat baroque new
architecture in order to fix issues with developer's B code just doesn't
seem smart to me. oh wait,  i just described JACK ....


> And most importantly, user experience may vary, so it is best to
> allow (not force) user to choose whether to pay some CPU load in
> exchange of better system stability.
>

in this context, it is not us but the OS that forces the user to make this
choice. if you want a segfault in a plugin to NOT reduce host stability,
you have to run it out of process. if you run it out of process, you pay
the price of more CPU load. if the OS provided some way to "partition" or
"sandbox" a shared object within a process, perhaps one could get away
without being forced to make this choice. but no OS that i am aware of can
do this for native code.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.ardour.org/pipermail/ardour-dev-ardour.org/attachments/20130130/780635fa/attachment-0002.htm>


More information about the Ardour-Dev mailing list