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

From: Niklas Klügel <niklas.kluegel@email-addr-hidden>
Date: Thu Sep 03 2009 - 10:23:26 EEST

Danni Coy schrieb:
>
>
> On Wed, Sep 2, 2009 at 11:30 PM, Niklas Klügel
> <niklas.kluegel@email-addr-hidden <mailto:niklas.kluegel@email-addr-hidden>> 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 :)
_______________________________________________
Linux-audio-user mailing list
Linux-audio-user@email-addr-hidden
http://lists.linuxaudio.org/mailman/listinfo/linux-audio-user
Received on Thu Sep 3 12:15:02 2009

This archive was generated by hypermail 2.1.8 : Thu Sep 03 2009 - 12:15:02 EEST