Modular environment is great, but integrated environment seems to be more effective. I mean, imho it is not<br>a matter of preference and I am not saying no work should be done on session management. I am just saying that so<br>
far my observations show me that integrated environment has too many benefits over modular environment.<br><br>I am relatively new to linux audio, so I would be grateful if you would explain to me the benefits of modular environment.<br>
<br>So far I've not been able to see any special benefits of such an environment. I mean, it's curious, but it also means lots of open<br>windows, it means the project being dependent on many-many apps. Somehow to me it means working on the problem<br>
from the outside. All the inter-application management seems to be a difficult problematic and even in the long run is doomed<br>to have many problems due to many apps involved. A dev releases new version of his app that has a bug and session<br>
handler cannot connect it - and boom!<br><br><br>But I also have a suggestion.<br>Is it possible to create an integrated environment based on modules? That is, an app which would have "plugins", but not plugins in a<br>
sense like effects and synths only, but plugins as elements of the sequencer itself, like piano roll, song editor, such stuff. A person opens this app<br>and starts adding elements he needs to it. For a particular project he might not need a piano roll, he might need only audio track arranger,<br>
for another projects he takes an audio track arranger and also adds a piano roll.<br>Modules of such an app could be very different, like a loop player like Kluppe, etc - all the apps linux audio has to this day but remade as modules<br>
to an integrated sequencer.<br><br>What do you think?<br><br><br><br>Louigi Verona.<br><br><br><br><br><div class="gmail_quote">On Sun, Dec 20, 2009 at 4:18 AM, Patrick Shirkey <span dir="ltr"><<a href="mailto:pshirkey@boosthardware.com">pshirkey@boosthardware.com</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 bgcolor="#ffffff" text="#000000"><div class="im">
<br>
On 12/20/2009 11:48 AM, Louigi Verona wrote:<br>
<blockquote 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></div>
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><font color="#888888">
<br>
<br>
<br>
<br>
<br>
<br>
<pre cols="72">Patrick Shirkey
Boost Hardware Ltd</pre></font><div><div></div><div class="h5">
<br>
<br>
<br>
<br>
<br>
<br>
<br>
<blockquote 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 href="mailto:fons@kokkinizita.net" target="_blank">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>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><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><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><br>
_______________________________________________<br>
Linux-audio-dev mailing list<br>
<a href="mailto:Linux-audio-dev@lists.linuxaudio.org" target="_blank">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>
<pre><fieldset></fieldset>
_______________________________________________
Linux-audio-dev mailing list
<a href="mailto:Linux-audio-dev@lists.linuxaudio.org" target="_blank">Linux-audio-dev@lists.linuxaudio.org</a>
<a href="http://lists.linuxaudio.org/mailman/listinfo/linux-audio-dev" target="_blank">http://lists.linuxaudio.org/mailman/listinfo/linux-audio-dev</a>
</pre>
</blockquote>
</div></div></div>
<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>
<br></blockquote></div><br>