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

Previous message: [thread] [date] [author]
Next message: [thread] [date] [author]
To: Niklas Klügel <niklas.kluegel@...>
Cc: <linux-audio-user@...>
Date: Wednesday, September 2, 2009 - 4:57 pm

--001485f724f0c1717904729b298c
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

On Wed, Sep 2, 2009 at 11:30 PM, Niklas Kl=FCgel w=
rote:

> cunnilinux himself schrieb:

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 trac=
k
and playback the recorded audio instead.

> 1b) keep sequencing and time-information on

if the solution for 1 is enabled then this should also be possible.

> 1c) saving disk-space and processing time by recording only the

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.

> 2) modifying a group of modules in the signal chain and the sequence

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 applicatio=
n
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.

This could potentially be done through dbus... and/or as an extension to LV=
2
etc.

> 4) limit the amount of organization in 1x) and mixing units

5) of course easy recall of chains(+sequence data) etc

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.

--001485f724f0c1717904729b298c
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

On Wed, Sep 2, 2009 at 11:30 PM, Niklas =
Kl=FCgel <n=
iklas.kluegel@mytum.de
> wrote:
cunnilinux himself schrieb:

a similar application for linux.
he
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 ther=
e 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 t=
he system output connections (speakers), or back into the application itsel=
f. The application could then connect the terminating output(s) to the prog=
ram input - do a synchronised record (already possible), close off the sign=
al path for the processing version of the track and playback the recorded a=
udio instead.
=A0
1b) keep sequencing and time-information on
processed/bounced/re-recorded materialif the solu=
tion for 1 is enabled then this should also be possible.=A0

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 miss=
ing something here.
=A0
2) modifying a group of modules in the signal chain and the sequence
data e.g. cloning, deleting, replacing etc.Clonin=
g 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 loa=
ded by the application that replaces Lash (LADI?)... All this should be pos=
sible.
=A0
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 thr=
ough dbus... and/or as an extension to LV2 etc. =A0

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.=A0=

5) of course easy recall of chains(+sequence data) etc
These points are of conceptual nature.This=A0 I=
=A0 understand is the point of having something like LASH (LADI?)...Anyways I am glad you brought up those points... It is somethin=
g severely lacking in the current modular implementation that we have.
Doing things in a modular way through jackd has a lot of potential but real=
ly requires some application managment features to really compete with prop=
rietory workflows.I would love to see a control application that
1) lets you group applications....2) the ability to remove/restore conn=
ections going in or out of=A0 a group.3) the ability to clone a group.<=
br>4) the ability to save/restore groups of applications.

--001485f724f0c1717904729b298c--

Previous message: [thread] [date] [author]
Next message: [thread] [date] [author]

Messages in current thread:
[LAU] off topic (was: Re: ableton live in vmware), cunnilinux himself, (Mon Aug 31, 5:27 pm)
Re: [LAU] off topic (was: Re: ableton live in vmware), Niklas Klügel, (Wed Sep 2, 1:31 pm)
Re: [LAU] off topic (was: Re: ableton live in vmware), Danni Coy, (Wed Sep 2, 4:57 pm)
Re: [LAU] off topic (was: Re: ableton live in vmware), Niklas Klügel, (Thu Sep 3, 7:23 am)
Re: [LAU] off topic (was: Re: ableton live in vmware), Patrick Shirkey, (Thu Sep 3, 12:08 am)
Re: [LAU] modular audio apps and control-communication was: ..., Gabriel M. Beddingfield, (Wed Sep 2, 5:50 pm)
Re: [LAU] modular audio apps and control-communication was: ..., Gabriel M. Beddingfield, (Thu Sep 3, 3:02 am)
Re: [LAU] off topic (was: Re: ableton live in vmware), Patrick Shirkey, (Wed Sep 2, 3:09 pm)
Re: [LAU] off topic (was: Re: ableton live in vmware), Hartmut Noack, (Mon Aug 31, 9:51 pm)
Re: [LAU] off topic (was: Re: ableton live in vmware), Rui Nuno Capela, (Mon Aug 31, 10:20 pm)
Re: [LAU] off topic (was: Re: ableton live in vmware), Hartmut Noack, (Tue Sep 1, 3:47 pm)
Re: [LAU] off topic (was: Re: ableton live in vmware), Rui Nuno Capela, (Tue Sep 1, 7:33 am)
Re: [LAU] off topic (was: Re: ableton live in vmware), Paul Coccoli, (Tue Sep 1, 4:43 pm)
Re: [LAU] off topic (was: Re: ableton live in vmware), Patrick Shirkey, (Tue Sep 1, 1:15 am)
Re: [LAU] off topic (was: Re: ableton live in vmware), Patrick Shirkey, (Tue Sep 1, 10:41 pm)
Re: [LAU] off topic (was: Re: ableton live in vmware), Hartmut Noack, (Wed Sep 2, 3:27 pm)
Re: [LAU] off topic (was: Re: ableton live in vmware), Atte Andre Jensen, (Wed Sep 2, 3:58 pm)
Re: [LAU] off topic (was: Re: ableton live in vmware), Niklas Klügel, (Thu Sep 3, 7:14 am)
Re: [LAU] off topic (was: Re: ableton live in vmware), Thorsten Wilms, (Wed Sep 2, 7:44 am)
Re: [LAU] off topic (was: Re: ableton live in vmware), Brett McCoy, (Tue Sep 1, 10:47 pm)
Re: [LAU] off topic (was: Re: ableton live in vmware), Grammostola Rosea, (Tue Sep 1, 7:52 pm)
Re: [LAU] off topic (was: Re: ableton live in vmware), Nedko Arnaudov, (Wed Sep 2, 11:25 am)
Re: [LAU] off topic (was: Re: ableton live in vmware), Nedko Arnaudov, (Wed Sep 2, 12:52 pm)
Re: [LAU] off topic (was: Re: ableton live in vmware), Brett McCoy, (Tue Sep 1, 12:56 am)
Re: [LAU] What Live is about (was: Re: ableton live in vmware), Robbert Latumahina, (Tue Sep 1, 10:40 am)
Re: [LAU] off topic (was: Re: ableton live in vmware), Patrick Shirkey, (Tue Sep 1, 1:20 am)
Re: [LAU] off topic (was: Re: ableton live in vmware), Ronald Stewart, (Tue Sep 1, 1:31 am)
Re: [LAU] off topic (was: Re: ableton live in vmware), Dave Phillips, (Mon Aug 31, 10:11 pm)
Re: [LAU] back on topic (ableton-like tools for linux), Ken Restivo, (Mon Aug 31, 9:48 pm)
Re: [LAU] back on topic (ableton-like tools for linux), Patrick Shirkey, (Tue Sep 1, 2:05 am)
Re: [LAU] off topic (was: Re: ableton live in vmware), Atte Andre Jensen, (Mon Aug 31, 9:29 pm)
Re: [LAU] off topic (was: Re: ableton live in vmware), Hartmut Noack, (Mon Aug 31, 10:01 pm)
Re: [LAU] off topic (was: Re: ableton live in vmware), Brett McCoy, (Mon Aug 31, 5:35 pm)