<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
<meta content="text/html; charset=ISO-8859-1"
http-equiv="Content-Type">
</head>
<body bgcolor="#ffffff" text="#000000">
<br>
On 12/20/2009 11:48 AM, Louigi Verona wrote:<br>
<blockquote
cite="mid:20aeede50912191648w3c29e29te213a212246da51d@mail.gmail.com"
type="cite"><br>
So, as a musician, I think linux audio developers have to focus on<br>
<br>
1. integrated audio environment<br>
2. sotware synthesizers/effects (LV2)<br>
<br>
</blockquote>
<br>
<br>
<br>
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. <br>
<br>
I am looking forward to the progress that will be made over the next
couple of years on that front.<br>
<br>
<br>
<br>
<br>
<br>
<br>
<pre class="moz-signature" cols="72">Patrick Shirkey
Boost Hardware Ltd</pre>
<br>
<br>
<br>
<br>
<br>
<br>
<br>
<blockquote
cite="mid:20aeede50912191648w3c29e29te213a212246da51d@mail.gmail.com"
type="cite">LMMS is an integrated environment and having Zyn inside it
is great. LMMS is very promising.<br>
But what isn't there are plugins and synthesizers. As an ambient
composer I simply lack the tools<br>
I need,<br>
<br>
Hope any of this was useful.<br>
<br>
Louigi Verona.<br>
<br>
<br>
<br>
<br>
<br>
<br>
<div class="gmail_quote">On Sun, Dec 20, 2009 at 1:19 AM, <span
dir="ltr"><<a moz-do-not-send="true"
href="mailto:fons@kokkinizita.net">fons@kokkinizita.net</a>></span>
wrote:<br>
<blockquote class="gmail_quote"
style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
<div class="im">On Sat, Dec 19, 2009 at 09:15:22PM +0100, rosea
grammostola wrote:<br>
<br>
> 1) The 'one app with plugins' group. People who are focusing on
one big<br>
> app, extended by plugins (Ardour, Qtractor, LV2/DSSI). This group<br>
> doesn't have much interest in a session handler.<br>
<br>
</div>
And quite probably the authors of these apps are not very<br>
motivated to make them compatible with session handlers.<br>
<div class="im"><br>
> 2) The people who likes to work with different, small Jack
applications<br>
> (ams, aeolus, epichord etc.). These people are interested in a
session<br>
> handler. But they think dbus is the wrong approach, it is to
limited for<br>
> them, or it is not the right thing for the Linux platform in their
opinion.<br>
<br>
</div>
'Like to work' may not be the correct interpretation. See (4)<br>
<div class="im"><br>
> 3) Group 3 is the same as group 2, BUT they have chosen dbus as<br>
> solution. It's the LADI group.<br>
<br>
</div>
4. And there's group 4, or maybe that group is just me.<br>
If there are others I'd like to know. For group 4:<br>
<br>
* Sessions are multi-host since there is no other way.<br>
In most cases all but one of the machines involved will<br>
be headless, and whatever is supposed to happen there<br>
is by definition remote controlled instead of being<br>
launched from a local desktop.<br>
<br>
* There are no usable 'single app with plugins' solutions<br>
since none of these comes close to what would be required,<br>
in particular w.r.t. the multi-host situation, and also<br>
because all of these apps silently assume a human user<br>
watching them and being able to take corrective action<br>
if necessary. Anything that could pop up an error dialog<br>
and refuse to proceed until someone reacts is completely<br>
useless in such systems.<br>
<br>
* Any interaction between components of such a system is<br>
supposed to use networked communication from the start.<br>
Dual-layer solutions based on some local IPC system plus<br>
some additional layer that would connect them via a network<br>
are just an unnecessary complication, and probably one that<br>
would not provide the right semantics, since the design would<br>
be based on the single host assumption in blissfull ignorance<br>
of what it takes to make things work together via a network.<br>
<br>
* Given the potential complexity of a networked system, loading<br>
a 'session' would in general not mean a complete teardown and<br>
buildup of all apps and their connections, but could just mean<br>
loading a different configuration in a single app, without even<br>
any others being aware of this.<br>
<br>
People using such systems are *very* motivated to create<br>
some form session handling, since controlling this sort of<br>
thing manually is a real PITA, in particular if you have<br>
to do it a hundred times a day, or if you have to provide<br>
an interface usable by non-experts. Which is why I have<br>
been working on this. And given the quite hostile reactions<br>
shown in recent threads, and the probably minute potential<br>
user base, the chances that the results will be made public<br>
are rather small.<br>
<br>
Ciao,<br>
<font color="#888888"><br>
--<br>
FA<br>
</font>
<div>
<div class="h5"><br>
_______________________________________________<br>
Linux-audio-dev mailing list<br>
<a moz-do-not-send="true"
href="mailto:Linux-audio-dev@lists.linuxaudio.org">Linux-audio-dev@lists.linuxaudio.org</a><br>
<a moz-do-not-send="true"
href="http://lists.linuxaudio.org/mailman/listinfo/linux-audio-dev"
target="_blank">http://lists.linuxaudio.org/mailman/listinfo/linux-audio-dev</a><br>
</div>
</div>
</blockquote>
</div>
<br>
<pre wrap="">
<fieldset class="mimeAttachmentHeader"></fieldset>
_______________________________________________
Linux-audio-dev mailing list
<a class="moz-txt-link-abbreviated" href="mailto:Linux-audio-dev@lists.linuxaudio.org">Linux-audio-dev@lists.linuxaudio.org</a>
<a class="moz-txt-link-freetext" href="http://lists.linuxaudio.org/mailman/listinfo/linux-audio-dev">http://lists.linuxaudio.org/mailman/listinfo/linux-audio-dev</a>
</pre>
</blockquote>
</body>
</html>