Subject: Re: my take on the "virtual studio" (monolith vs plugins) ... was Re: [linux-audio-dev] ardour, LADSPA, a marriage
From: Paul Barton-Davis (pbd_AT_Op.Net)
Date: Fri Nov 17 2000 - 16:54:06 EET
>Paul BD : can you comment please on the last part of this mail :
>( hdr_callback() ) if such a model would be viable to implement your
>record-while-play with instant punch-in/out ?
>hdr_callback() {
>
> - fetch_soundcard_input_buffers() ( basically it consists of reading buffer
> where the soundserver placed the current fragment(s) (for each input
> channel))
>
>- fetch_input_buffers_from_disk_thread() (this is needed if we need to proces
>s
>
>- execute_LADSPA_process_chain()
>
>- send resulting data to soundcard outputs & disk thread (for tracks which
> are being recorded)
>
>}
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 am not thinking very clearly about this, and I'm only superficially
interested in this (once again) abstract discussion. 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.
--p
This archive was generated by hypermail 2b28 : Fri Nov 17 2000 - 17:36:48 EET