Subject: Re: Plugin chains and EDLs, was Re: [linux-audio-dev] ardour, LADSPA, a marriage
From: Paul Winkler (slinkp23_AT_yahoo.com)
Date: Tue Nov 14 2000 - 19:13:13 EET
David Olofson wrote:
>
> On Mon, 13 Nov 2000, Paul Winkler wrote:
> > In my message last night, which I wrote when really too tired and
> > incoherent, I first proposed building a mixer entirely out of LADSPA
> > plugins, and then deleted it, thinking it was too messy of a project
> > for a Simple Plugin Architecture.
>
> On the contrary, this is the way I want the mixer in my new digital
> studio to be built. I can't see any serious technical problems with
> it.
Good. :)
> > But if plugins are the only good way
> > to get this job done, I have to ask, can this be done with LADSPA?
>
> Sure, LADSPA should work for most things, and I can't see why you
> would use a more complex API with more overhead for the majority of
> the parts of a mixer.
>
> (There *might* be an issue with extreme forms of mixer automation,
> though, but I'd think it's rather unusual to modulate mixer controls
> with higher frequencies than 100 Hz or so... No point in optimizing
> the entire system for the extreme cases - that kind of stuff belongs
> in modular synths.)
I suspect you're right, as long as things like "mute" that you want to
respond quickly can do so.
(snip)
> > 2) I had the impression that LADSPA is mostly intended for
> > single-input / single-output plugins, but a mixer has several
> > sub-sections where inputs != outputs.
>
> Can't see a problem - LADSPA supports all kinds of configurations me
> might need, unless I've missed something...
>
> What *might* be a problem is dynamic numbers of ins/outs. (Required?)
Depends what you mean by "dynamic". I think being able to completely
reconfigure the mixer is important, but I don't see a big problem with
having to stop playback in order to do so.
(snip)
> > Each input channel is simple at first - it's just a linear chain.
> > But then you hit bus assignment and/or panning. Let's leave out
> > panning for now (again for sake of discussion). We have reached a part
> > of the chain where we need to select which bus(ses) will get the
> > output of this channel. THis is pretty simple, it's just a switch
> > really; question is whether to do it with the host or with plugins?
> > The latter would be probably best in the long run from a user point of
> > view, in terms of flexibility.
>
> It's just a matter of using plugins that can do adding processing
> with output gain control. Connect all outputs to the same buffer, and
> there's your bus! :-)
>
> As to pure switching/bus selection, it's just a batter of connecting
> the plugins to the buffers representing the desired busses. (The same
> goes for inputs tapping audio from busses.)
Cool. I hadn't grasped that before. But as PBD points out this
requires run_adding in all the plugins.
But given that, panning between two busses is pretty easy, too; just
split the signal and feed them to two busses with inverted gain
control on one of them. Then it's just a matter of getting the "feel"
of the pan knob right.
(snip)
> > THis leads me to another thought. Every application is going to want
> > to have a way to save descriptions of plugin networks so you can
> > re-create your session later. Maybe saved as XML for example. A
> > complete mixer setup could be saved as one such description. What
> > would be REALLY REALLY COOL would be if different applications could
> > read and write the same description.
>
> Yes, that sounds very interesting... :-)
>
> Besides, starting out with a standard like that, the next thing might
> be applications that are actually only user interfaces/net editors for
> other engines. That is, throw your net description and perhaps a
> bunch of special plugins at any standard compliant engine, and fire
> up. No need to hack your own engine.
> Advantage: Multiple applications can use the same engine at the same
> time without latency problems.
>
Now you're talking. :)
> > For example, if I'm using snd and I discover a chain of effects that
> > does something really, really useful to me, I'd like to easily re-use
> > that same chain in ecasound, or ardour, or a video production suite or
> > whatever.
>
> Why not just having snd publish the chain in question, so that other
> applications connected to the engine could connect to it right away?
> That may, you can tweak the chain in real time without a stop A/save
> from A/load from B/start B cycle.
Good idea, but you're still going to want to save them for later
re-use.
Or for posting them on the internet!
(snip)
> > In fact these
> > same ideas could apply to VST or whatever. But since each host is
> > going to have to deal with these issues (at least if to decide not to
> > deal with them), we really should think about general solutions.
>
> Yeah, this is the messy part... :-)
What makes it messy? (he said naively...)
> > One question is: are plugin chains or networks just part of an edit
> > decision list? Or is it a separate issue?
> > To me they're conceptually separate, but I suppose a plugin setup
> > could just be saved as an EDL with no edits.
>
> Well, yeah, provided the *EDL* actually cares about what you insert.
> Why not just make it deal only with connections, and have a different
> layer deal with the routing (single plugins, chaing, public
> connections etc) of these connections?
(snip)
> I think EDLs and chain/net descriptions should be considered two
> strictly separate things. EDLs see chains, nets, external stuff etc
> as black boxes, just as if they were all single plugins.
That makes sense to me.
> Hmm... How about "virtual plugins"?
>
> That is, plugins that are actually descriptions of nets, rather than
> real plugins. The logic behind that is that using this "chain manage
> layer", everything is a chain, and all installed plugins (possibly
> using different APIs) are registered as chains. Just pick and chose.
YES! That's EXACTLY what I want.
It's like if you've been programming in a crippled Basic without even
a GOTO, and all of a sudden you can define functions.
Maybe I'm exaggerating a little, I haven't looked at Basic in about 20
years :)
> > This *could* all be handled by EDLs if the EDLs were sufficiently
> > smart about encapsulating other EDLs, but I still wonder if there's
> > something to be gained by separating the issues.
>
> I don't think EDLs have got anything to do with this. They're
> supposed to deal with edit desicions, not the details of how applied
> effects are actually implemented.
Point taken.
> > Of course for such plugin network descriptions to be portable, the
> > hosts supporting it would have to provide a common base of equivalent
> > patching functionality. So we'd have to hash out what that should be.
> > There could be various levels of support. Level 1 would be very simple
> > - just single-channel series chains. Everything above that would take
> > some work to define and agree on.
>
> Yep, especially if it's supposed to support more than one plugin API.
> No problem for applications that don't host plugins themselves, but
> engine implementations would be rather messy.
>
> However, plugins hosting plugins is one way to sort things out...
> Could be the way, at least for "normal" hosts. (A generic "standard"
> host for remote control from host-less applications would probably
> use a more optimized approach.)
Both interesting ideas.
I'll leave that to people who are actually capable of implementing
either solution.
:-p
> > Now look at it the other way around. If a network of plugins can be
> > thought of as a discrete object; if networks of plugins can contain
> > sub-networks of plugins and keep the logical distinction between them;
> > if these networks can be used by a number of different applications...
> > I'm thinking this could be a step forward comparable to the
> > introduction of the plugin concept itself.
>
> Yes. This is exactly the way I'd like, although, I'd also like it all
> to work in real time, without moving files around. :-)
Now that you brought it up, me too!
--
................. paul winkler ..................
slinkP arts: music, sound, illustration, design, etc.
web page: http://www.slinkp.com
A member of ARMS: http://www.reacharms.com
This archive was generated by hypermail 2b28 : Tue Nov 14 2000 - 20:16:48 EET