[linux-audio-dev] Freeze?

[Benjamin Flaming]

On Thursday 26 February 2004 10:25 am, Paul Davis wrote:
> >     I want my plug-ins frozen the instant I close the parameter editor.
> > ;)
>
> oh, you don't want to do any graphical editing of plugin parameter
> automation? :))

     Well then - as soon as I stop editing the automation data ;)

> >     Agreed, it's a very definite trade-off - storage space for CPU
> > cycles. It is my observation, however, that storage space is cheap, and
> > readilly available.
>
> not my experience.

     It's a renewable resource.  When I archive a multi-gigabyte song, I have 
more storage space.  My CPU power stays the same, however.  It's also 
(generally) easy to throw in another hard drive - giving me the storage I had 
before *plus* whatever I've added.  If I change the CPU, the old one 
(normally) can't contribute DSP anymore.

> sure, but thats a subset of all busses. its not a bus per se.

     It's not terribly common right now because lots of extra aux inputs make 
for a bulkier and harder-to-manage mix.  Effects sends would be less 
important when working with a tree structure, because the impact of the 
inherent DSP savings would be diminished by offline rendering.

> have you actually experienced how long it takes to "re-render"?
> steve's suggestion is an interesting one (use regular playback to
> render), but it seems to assume that the user will play the session
> from start to finish. if you're mixing, the chances are that you will
> be playing bits and pieces of of the session. so when do you get a
> chance to re-render? are you going to tie up disk bandwidth and CPU
> cycles while the user thinks they are just editing? OK, so you do it
> when the transport is idle - my experience is that you won't be done
> rendering for a long time, and you're also going to create a suprising
> experience for the user at some point - CPU utilization will vary
> notable over time, in ways that the user can't predict.

     You bring up some interesting points here.  One thing I hadn't mentioned 
is that Tinara is intended for eventual use with a render farm.  I quickly 
realized, however, that it needed to be capable of running on a single 
machine - if only for testing purposes.  Understand, therefore, that local 
offline rendering in this project is little more than a stopgap measure.  The 
question of when rendering takes place on a local machine is one which I've 
changed my mind on countless times.  I'd played with the idea of writing live 
playback to the disk as a rendering technique, but things like reverbs need 
to be processed in an uninterrupted stream.

     I admit that the idea of stopping rendering when playback starts was 
short-sighted.  I tend to spend a lot of time editing, and this clouded my 
thinking.  As previously stated, however, I've changed my mind on this kind 
of thing quite often - particularly over the past couple of weeks.

> you also seem to assume that the transport being stopped implies no
> audio streaming by the program. in ardour (and most other DAWs), this
> simply isn't true. ardour's CPU utilization doesn't vary very much
> whether the transport is idle or not, unless you have a lot of track
> automation, in which case it will go up a bit when rolling.

     I'm aware of this - Pro Tools is the same way.  The decision to stop 
processing when the transport is stopped was based on two factors:

1. It allows more DSP power for local offline rendering.
2. Things like reverb will stop with the transport anyway, once they've been 
rendered.  I thought the behavior should be as consistent as possible.

     OTOH, it would be nice to hear the reverb tail while editing the 
parameters - so maybe this wasn't such a good idea after all.  In fact, I 
think you've talked me out of it :)

> the focusing part seems great, but seems to be more of a GUI issue
> than a fundamental backend one. it would be quite easy in ardour, for
> example, to have a way to easily toggle track+strip views rather than
> display them all.

     There are other reasons for the tree structure.  It makes it very easy to 
navigate to a particular audio element, and process it with an external 
program.  It also allows storage and organization of non-audio data, such as 
Csound instruments or Hydrogen songs, inside the same directory hierarchy.  
You could, for instance, store the Hydrogen song right inside the Drums 
branch, and a future version of Tinara could automatically open the file in a 
future version of Hydrogen, connecting the two applications via JACK.

     I looked very seriously at trying to implement the things I want in 
Ardour.  My conclusion, however, was that there are some fundmental design 
differences which would make some of my overall goals impractical.  (More on 
this below).

> the DSP power part seems like a good idea, but i think its much, much
> more difficult than you are anticipating. i've been wrong many times
> before though.

     It will be very difficult - but it's the program I've been wanting to use 
for years.  Now that I've started, I'm highly motivated to see it through :)

> and btw, the reason Ardour looks a lot like PT is that it makes it
> accessible to many existing users. whether or not ardour's internal
> design looks like PT, i don't know. i would hope that ardour's
> development process has allowed us to end up with a much more powerful
> and flexible set of internal objects that can allow many different
> models for editing, mixing and so forth to be constructed. the backend
> isn't particularly closely connected in any sense, including the
> object level, to the GUI.

     Part of the reason I'm skeptical of using Ardour as a foundation for what 
I'm trying to do, is that I think there are some fundamental differences in 
what we are trying to accomplish.

     Ardour is intended to function as a real-time DAW, with offline rendering 
capabilities.  Tinara is intended to be an offline compositing system, with a 
front-end for editing and real-time previewing - which may sometimes be lower 
quality than the final rendered result.

     Ardour is a DAW system with many powerful new features, which still 
remains comfortably familiar to users of other high-end audio applications (I 
consider this a Very Good Thing(TM) BTW).  Tinara is a node-based compositing 
system which would probably be of little interest to most experienced DAW 
users - it will require a different working style, and it will require 
thinking about editing, mixing, and processing, in a fundmentally different 
way, if it is to be used effectively.

     Ultimately, Ardour is what the audio industry wants, and Tinara is what I 
want ;)  I may yet end up deciding to use parts of Ardour for things like 
live disk streaming, but I think both projects have something to offer which 
is unique enough to justify separate development.

|)
|)enji