On 12/20/2009 11:48 AM, Louigi Verona wrote:
So, as a musician, I think linux audio developers have to focus on
1. integrated audio environment
2. sotware synthesizers/effects (LV2)
I prefer to work with a modular environment and want to see session
management working properly. I would be very disappointed if no further
work was done on session management.
I am looking forward to the progress that will be made over the next
couple of years on that front.
Patrick Shirkey
Boost Hardware Ltd
LMMS is an integrated environment and having Zyn inside it is great.
LMMS is very promising.
But what isn't there are plugins and synthesizers. As an ambient
composer I simply lack the tools
I need,
Hope any of this was useful.
Louigi Verona.
On Sun, Dec 20, 2009 at 1:19 AM, <[email protected]
<mailto:[email protected]>> wrote:
On Sat, Dec 19, 2009 at 09:15:22PM +0100, rosea grammostola wrote:
> 1) The 'one app with plugins' group. People who are focusing on
one big
> app, extended by plugins (Ardour, Qtractor, LV2/DSSI). This group
> doesn't have much interest in a session handler.
And quite probably the authors of these apps are not very
motivated to make them compatible with session handlers.
> 2) The people who likes to work with different, small Jack
applications
> (ams, aeolus, epichord etc.). These people are interested in a
session
> handler. But they think dbus is the wrong approach, it is to
limited for
> them, or it is not the right thing for the Linux platform in
their opinion.
'Like to work' may not be the correct interpretation. See (4)
> 3) Group 3 is the same as group 2, BUT they have chosen dbus as
> solution. It's the LADI group.
4. And there's group 4, or maybe that group is just me.
If there are others I'd like to know. For group 4:
* Sessions are multi-host since there is no other way.
In most cases all but one of the machines involved will
be headless, and whatever is supposed to happen there
is by definition remote controlled instead of being
launched from a local desktop.
* There are no usable 'single app with plugins' solutions
since none of these comes close to what would be required,
in particular w.r.t. the multi-host situation, and also
because all of these apps silently assume a human user
watching them and being able to take corrective action
if necessary. Anything that could pop up an error dialog
and refuse to proceed until someone reacts is completely
useless in such systems.
* Any interaction between components of such a system is
supposed to use networked communication from the start.
Dual-layer solutions based on some local IPC system plus
some additional layer that would connect them via a network
are just an unnecessary complication, and probably one that
would not provide the right semantics, since the design would
be based on the single host assumption in blissfull ignorance
of what it takes to make things work together via a network.
* Given the potential complexity of a networked system, loading
a 'session' would in general not mean a complete teardown and
buildup of all apps and their connections, but could just mean
loading a different configuration in a single app, without even
any others being aware of this.
People using such systems are *very* motivated to create
some form session handling, since controlling this sort of
thing manually is a real PITA, in particular if you have
to do it a hundred times a day, or if you have to provide
an interface usable by non-experts. Which is why I have
been working on this. And given the quite hostile reactions
shown in recent threads, and the probably minute potential
user base, the chances that the results will be made public
are rather small.
Ciao,
--
FA
_______________________________________________
Linux-audio-dev mailing list
[email protected]
<mailto:[email protected]>
http://lists.linuxaudio.org/mailman/listinfo/linux-audio-dev
_______________________________________________
Linux-audio-dev mailing list
[email protected]
http://lists.linuxaudio.org/mailman/listinfo/linux-audio-dev
_______________________________________________
Linux-audio-dev mailing list
[email protected]
http://lists.linuxaudio.org/mailman/listinfo/linux-audio-dev
