Danni Coy schrieb: > > > On Wed, Sep 2, 2009 at 11:30 PM, Niklas Klügel > <niklas.kluegel@xxxxxxxx <mailto:niklas.kluegel@xxxxxxxx>> 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@xxxxxxxxxxxxxxxxxxxx http://lists.linuxaudio.org/mailman/listinfo/linux-audio-user
