9 Jul
2005
9 Jul
'05
1:41 p.m.
I have been thinking about the problem of apps not remembering their
connections etc. and also the problem with manually loading patches etc.
The fact that my desktop can automatically restore previous state (with
reasonable accuracy) makes me thing that this should not be a really big
problem (although I recognise the fine detail is more problematic).
I may be really underestimating the complexity here, but it seems to me
that the best way to achieve this would be to have a kind of sub-shell or
sub-window manager sandbox just for the audio apps. You then launch the
apps within this, and have the ability to save state ( which just
replicates your actions within the window for a future session).
Anyone got any thoughts on this? It is a bit beyond my mediocre Python
skills (I think), but I know there are developers here who might be able
to pick up and run with this idea.
The beauty of it, as I see it, is that apps don't have to be aware of the
structure: they just do their thing and the sandbox remembers all the
human input to get them into the correct state.
So what do you all think? possible? impossible? already done?
James
9 Jul
9 Jul
2:34 p.m.
On Sat, Jul 09, 2005 at 04:40:53PM +0100, James Stone wrote:
I may be really underestimating the complexity here, but it seems to me
that the best way to achieve this would be to have a kind of sub-shell or
sub-window manager sandbox just for the audio apps. You then launch the
apps within this, and have the ability to save state ( which just
replicates your actions within the window for a future session).
Saving state is not all simple. What to do with audio files from
a daw or in a sample editor? If there are changes not currently
saved, you have to save them on closing/saving the session.
Not that such issues can't be dealt with in a sensible way.
So what do you all think? possible? impossible?
already done?
http://lash-audio-session-handler.org/
The project is pretty much in deep freeze, even though several
developers are interested in it. There has been quite some
talk in the #lad irc channel.
---
Thorsten Wilms
5:06 p.m.
New subject: [linux-audio-user] Re: Audio sandbox..
On Sat, 09 Jul 2005 18:34:47 +0200, Thorsten Wilms wrote:
Yes, the laddca/lash thing never seemed to quite make it. I think the fact
that programs need to be laddca aware is a big problem with it, but if it
became universally used, it would be the ideal solution.
James
On Sat, Jul 09, 2005 at 04:40:53PM +0100, James Stone
wrote:
Yes I realise that patch loading is a problem, but I would personally find
a program that started up all the audio apps I was using, with the correct
audio and midi connections very helpful. If there was a notepad window to
remind me which patches to load, that would be even better (a bit clunky I
know, but pretty useful).
I may be really underestimating the complexity here, but it seems to me
that the best way to achieve this would be to have a kind of sub-shell
or sub-window manager sandbox just for the audio apps. You then launch
the apps within this, and have the ability to save state ( which just
replicates your actions within the window for a future session).
Saving state is not all simple. What to do with audio files from a daw or
in a sample editor? If there are changes not currently saved, you have to
save them on closing/saving the session. Not that such issues can't be
dealt with in a sensible way.
So what do you
all think? possible? impossible? already done?
http://lash-audio-session-handler.org/
The project is pretty much in deep freeze, even though several developers
are interested in it. There has been quite some talk in the #lad irc
channel. 
5:13 p.m.
On Sat, Jul 09, 2005 at 04:40:53PM +0100, James Stone wrote:
The fact that my desktop can automatically restore
previous state (with
reasonable accuracy) makes me thing that this should not be a really big
problem (although I recognise the fine detail is more problematic).
Well, it's easy for your desktop because so much of the work has
already been done. There's an X11 extension that specifically
implements session management. This provides a fully functional
session management implementation for things like Gnome and KDE
to look at and use.
Check the manpage for xsm for some details - I'm aware of this stuff
but don't really know how to use it. smproxy lets you session apps
that don't support the X11R6 Session Management Protocol.
You should be able to hack something basic together with this stuff -
ie, have a "Recording" session that loads up jack, ardour, jack-rack,
etc.
Unfortuantely, the deficiency of apps to save their own state is sort
of outside the scope - you'll still need to load the jack-rack plugins
you want.
--
Ross Vandegrift
ross(a)lug.udel.edu
"The good Christian should beware of mathematicians, and all those who
make empty prophecies. The danger already exists that the mathematicians
have made a covenant with the devil to darken the spirit and to confine
man in the bonds of Hell."
--St. Augustine, De Genesi ad Litteram, Book II, xviii, 37
8:08 p.m.
New subject: [linux-audio-user] Re: Audio sandbox..
Well, it's easy for your desktop because so much
of the work has already
been done. There's an X11 extension that specifically implements session
management. This provides a fully functional session management
implementation for things like Gnome and KDE to look at and use.
Check the manpage for xsm for some details - I'm aware of this stuff but
don't really know how to use it. smproxy lets you session apps that don't
support the X11R6 Session Management Protocol.
You should be able to hack something basic together with this stuff - ie,
have a "Recording" session that loads up jack, ardour, jack-rack, etc.
Yep.. the most simple way I can think of is to have a terminal app from
which you type in the path of the audio apps to launch, and then specify
the audio and midi connections. It then creates a bash script to
automatically launch the same setup for you in the future. Good if you use
the same set of apps linked in the same way. I would be able to write this
myself, I think, using jack_connect and aconnect.
I like the idea of it happening automatically, but this is really beyond
my powers at present! I will have a look at the stuff you suggested though.
Unfortuantely, the deficiency of apps to save their
own state is sort of
outside the scope - you'll still need to load the jack-rack plugins you
want.
Yes. I realise this. I think the apps need to give some info about state
on shutdown, and allow command-line loading of patches to work with this
system.
James
7081
days inactive
7081
days old
linux-audio-user@lists.linuxaudio.org
4 comments
3 participants
participants (3)
-
James Stone -
ross＠jose.lug.udel.edu -
Thorsten Wilms