Subject: Re: my take on the "virtual studio" (monolith vs plugins) ... was Re: [linux-audio-dev] ardour, LADSPA, a marriage
From: Benno Senoner (sbenno_AT_gardena.net)
Date: Fri Nov 17 2000 - 19:23:04 EET
On Fri, 17 Nov 2000, you wrote:
> Well, its looks reasonable, though inadequately complex. Lines like this:
>
> >Anyway if we can develop such a model where processing / mixing / routing
> >can be delegated to the virtual studio API, then
> >HDR apps become nothing more than a disk streaming engine, a GUI
> >and a bunch of plugins which do the processing.
>
> seriously underestimate whats needed to give the user a good
> experience. if you want a specific example: how will you implement
> "rewind" and how will the user see that its happening ? generalize
> that for any tape motion at all ? how will you implement monitoring ?
> how about metering ? there are answers to all of these questions
> (obviously), but if the results are to be nicely integrated into HDR
> software, things are *very* much more complex than the example above
> shows.
I agree (sorry for my understimating), I know how difficult it is to write an
app like ardour.
What I was meaning is that with a virtual studio model, you can delegate the
common tasks ( plugin processing, mixing etc) to the server, without being
able to reinvent the wheel over and over again.
Of course transport control, metering and all the other fancy stuff has to be
implemented within the app. (and as said it's far from trivial getting
the job done in an elegant and efficient way)
>
> I am not thinking very clearly about this, and I'm only superficially
> interested in this (once again) abstract discussion.
Yes this abstract discussion may sound boring, because there is neither
a precise plan nor working code available.
But I'd like to hear your opinions about the argument, because you
face real-world problems while coding ardour, so your advices about
what we should pay attention to will be very precious to determine
the specs of this model.
> I say that
> because I'm deep in the middle of actual writing code that implements
> what you are talking about. The lack of a routing architecture in
> ardour is emerging as more and more of a problem, and I'm about to fix
> it once and for all.
That's fine, but what I am interested in, is the inter-application routing:
you can implement the internal routing schemes you like
(within ardour), but what the proposed API should allow is to manage
the routing of data from/to connectors (ins/outs) an application decides
to publish.
So if inside your app, you decide to publish only the audio ins and outs
that's fine, but if one wants to publish other connectors too, he should be
allowed to do so.
(eg the wet signal of a reverb or other connectors of a builtin virtual mixer)
Same applies to GUI elements and MIDI data.
(if the HDR exports all fader controls of the mixer, then another
app (or the main-host), can control it remotely ( = automation).
But such a generalized interface would lead to way more cool stuff:
you could decide to export the transport controls too:
play , record, stop , pause, seek, (preroll / postroll calls)
that way a MIDI sequencer which wants to fire up a few tracks at
bar 32 of the song , calls the preroll/prefill callback at bar 31
(to give ardour time to prepare things) and then at bar 32
it "presses" play (the "instant" version of play).
And the list could go on ....
I think solving this kind of problem would solve the problem of
LADSPA GUI <--> LADSPA plugin communication too,
since it is similar.
end of abstract stuff.
PS: Seriously: should we take this to a private mailinglist until
some of the abstraction goes away ?
If yes then the people interested to the development of this API
should drop me a mail so I can create it.
(as said both programmers, and musicians with experience
with realworld hardware/software ( like Tom Pincince) are needed
to develop a good API)
Otherwise we can simply continue here.
(which I would prefer).
Benno.
This archive was generated by hypermail 2b28 : Fri Nov 17 2000 - 18:32:13 EET