[LAU] off topic (was: Re: ableton live in vmware)

[Niklas Klügel]

Danni Coy schrieb:
>
>
> On Wed, Sep 2, 2009 at 11:30 PM, Niklas Klügel 
> <niklas.kluegel at mytum.de <mailto:niklas.kluegel at mytum.de>> wrote:
>
>     cunnilinux himself schrieb:
>     >> Some people here (more or less) desperately need a similar
>     application for linux.
>     >>
>     >
>     > off topic, but...
>     > people in linux audio scene always DESPERATELY need something just
>     > like a copy of some fancy (commercial) app on win/mac.
>     > that's the main and only reason why linux is (semi-)deficient in the
>     > pro audio world.
>     >
>     >
>     just to add my 2 cents...
>
>     regarding monolithic vs. modular (across applications):
>     while the latter (theoretically) allows for more flexibility of
>     processing, akin to the proven unix-concepts of pipelining (and
>     therefore the development of something jack-alike for audio/video etc
>     became an obvious evolution for -primarily- LAU/D), it does not allow
>     for certain common concepts in the workflow of composition and dsp.
>     technically - or at least _without hassle_. those include nearly all
>     operations that:
>     1a) allow you to temporarily bounce (aka freezing) parts of the signal
>     chain (tracks, single processed clips, subchannels) - thus saving cpu
>     cycles in rather complex arrangements.
>
>
> This could happen if programs could be smart enough not to do audio 
> processing if there is no input signal and programs are able to trace 
> the signal path(s) till it(they) terminate(s) (either has no output 
> connections, makes itself to the system output connections (speakers), 
> or back into the application itself. The application could then 
> connect the terminating output(s) to the program input - do a 
> synchronised record (already possible), close off the signal path for 
> the processing version of the track and playback the recorded audio 
> instead.
>  
>
>     1b) keep sequencing and time-information on
>     processed/bounced/re-recorded material
>
>
> if the solution for 1 is enabled then this should also be possible.
>  
>
>     1c) saving disk-space and processing time by recording only the
>     necessary parts of the bounce while still being a proper/correct
>     bounce.
>
>
> this should also be possible. for inter application stuff this would 
> just require some form of dead air detection. Or am I missing 
> something here.
no nothing is missing. for external signals you might want to follow the 
volume amplitude very slowly and record until
the recorded signal has not changed for a certain period. for jack maybe 
the flagging of input/output buffers as having been modified would be 
sufficient.
>  
>
>     2) modifying a group of modules in the signal chain and the sequence
>     data e.g. cloning, deleting, replacing etc.
>
>
> Cloning would be an interesting feature to have at the connection and 
> application management layer.
> But providing that the applications are smart enough not to do 
> processing and that groups of applications could be saved and loaded 
> by the application that replaces Lash (LADI?)... All this should be 
> possible.
>  
>
>     3) exchange meta-information such as the set of notes in a track
>     to e.g.
>     allow samplers to efficiently just load the samples needed to play the
>     track, prefetching large chunks of audio-data or sub-track tempi for
>     sync'd f/x.
>
>
> This could potentially be done through dbus... and/or as an extension 
> to LV2 etc.
>  
>
>     4) limit the amount of organization in 1x) and mixing units
>     (pre-/post-fx or mixer or sub-channels and modulation sources
>     across tracks)
>     I am sure you can come up with some more. Those are all points taken
>     care of in halfway sane, up-to-date DAWs that are monolithic and
>     points
>     like 1 & 2 are basic editing operations that - for me - increase the
>     efficiency by a factor of 4 in time spent fiddling with the
>     arrangement.
>     The early versions of Ableton didnt do 1) for example and my time
>     spent
>     on organizing heavy arrangements (30-50 tracks with lots of automated
>     f/x) was unbearable, not to mention that the quality of execution
>     of the
>     sequencing and composition itself suffered due to that. 
>
>
>     5) of course easy recall of chains(+sequence data) etc
>     These points are of conceptual nature.
>
>
> This  I  understand is the point of having something like LASH (LADI?)...
>
> Anyways I am glad you brought up those points... It is something 
> severely lacking in the current modular implementation that we have.
> Doing things in a modular way through jackd has a lot of potential but 
> really requires some application managment features to really compete 
> with proprietory workflows.
>
> I would love to see a control application that
> 1) lets you group applications....
> 2) the ability to remove/restore connections going in or out of  a group.
> 3) the ability to clone a group.
> 4) the ability to save/restore groups of applications.
technically, I wholeheartedly agree that it is possible but my main 
point was that those aren't trivial features to implement for a modular 
environment :)