Hey guys!<br><br>I am not a developer, I am a musician who has decided to try to switch to Linux.<br><br>I am not sure how many times this has been discussed and I have signed up to this list<br>being interested in audio linux development, specifically lv2 plugins.<br>
<br>But I can say that in three months of very active work with audio, learning new concepts,<br>trying out Ardour, Qtractor, Zyn synth, Patchage, Kluppe, Sooperlooper, JackRack<br>and LMMS, I can say that although modular approach has its charm and even use,<br>
for most of the cases it is very awkward and very difficult to set up and any potential solution<br>bumps into many problems since any session management system will have to work with different<br>apps and it means more chances for errors - excuse me if I am not correct.<br>
<br>On the other hand, an integrated environment, while opposed by many linux users and programmers,<br>gives much more control to the musician both in live performance and studio work.<br><br>I must say that I have used Ardour, Kluppe and Jack Rack and Patchage in live performance and it was great,<br>
but I had to play only one tune. To set up the tune I had to open 4 instances of Kluppe, one Jack Rack,, open Ardour,<br>load session, load Patchage, disconnect unnecessary connections, connect Ardour to Jack Rack (for some reason<br>
it does not save connections to Jack Rack) and then connect all of that to a midi keyboard. This usually takes around<br>a minute of time.<br><br>If I had to play another tune, it would be a disaster, since I would have to close lots of stuff and reopen, not to mention that<br>
with a complex setup it is difficult to forget.<br><br>As for studio work, setting up a whole big number of apps to work on a tune is very difficult. It also seems to bring up a technical<br>problem - please sorry again if my technical conclusions are wrong - but with an integrated environment it seems it is easier to do<br>
memory management. With several apps Jack can just throw an app out without warning and it is very frustrating and time consuming.<br><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>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 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></div><div class="h5"><br>
_______________________________________________<br>
Linux-audio-dev mailing list<br>
<a href="mailto:Linux-audio-dev@lists.linuxaudio.org">Linux-audio-dev@lists.linuxaudio.org</a><br>
<a 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>