Thanks, Alex, for this lengthy explanation. I must think about it. I can certainly see<br>the massive advantages of modular approach for complex setups and specific tasks.<br>How good is it for simple things like making an ordinary song?<br>
<br>Also, tell me guys, is session handling a matter of - what? Apps supporting it or is<br>it programmatically a complex problem?<br><br>Louigi Verona.<br><br><div class="gmail_quote">On Sun, Dec 20, 2009 at 2:26 PM, alex stone <span dir="ltr"><<a href="mailto:compose59@gmail.com">compose59@gmail.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;">I'd have to disagree with this. A modular environment makes for better<br>
use of resource.<br>
Plugins occupy the same memory allocation as the app, and the same is<br>
true in win and mac. For all the perceived benefits of a "one stop<br>
shop" as far as workflow goes, there are drawbacks. It's noted that<br>
some users are ok with freezing tracks to best manage limited<br>
resources, but other's aren't. I spent a large chunk of my working<br>
life bouncing tracks on a constant basis, and unlike the linux<br>
environment, i didn't have a choice, no matter the strength of<br>
hardware i was using. It wasn't that long ago that if you wanted to<br>
run a full orchestral template, plus plugins, you needed a cluster of<br>
boxes, or a CRAY. I had a cluster of 5 gig boxes PRECISELY because of<br>
the limitations of allocated app memory space, and i was still<br>
bouncing tracks, if i wanted to run plugins as well.<br>
<br>
The modular environment offers a way out of this workflow killer<br>
(imho), and with the massive advantage of using jack, with its<br>
unlimited port structure, plugins no longer need to reside inside an<br>
app, but can be effectively hosted and ported to and from, outside the<br>
app, and in their own memory allocation.<br>
<br>
So i would vote against a push to put everything in one app. Quite the<br>
contrary, based on experience, and the many many frustrating hours i<br>
put into bouncing tracks, and handling a pandora's box worth of<br>
workarounds, just to get the client's material done.<br>
<br>
Again, i perceive this drive to centralise everything into one "super"<br>
app, as an intent to be "just like" win and mac, including the obvious<br>
and frustrating workflow limitations, along with any<br>
perceived.....advantages, when a little applied imagination on the<br>
part of users would reveal a much greater use of resource, and<br>
workflow satisfaction, in an unlimited workstation, where only the<br>
strength of the hardware, and the corresponding depth of the user's<br>
wallet, applies.<br>
<br>
There's also the perception that having "lots" of plugins inside an<br>
app is somehow.........cool, and "the best way to work". It isn't,<br>
beyond the first hour of use. Managing lots of plugins is as much, and<br>
possibly more of a time killer, than setting up a multiapp template in<br>
a linux audio environment. Been there, done that, and it's no<br>
sinecure.<br>
<br>
So no to centralisation, and yes to developing dedicated external lv2<br>
plugin hosting more effectively. (Multi hosts, for example.) The power<br>
of JACK should not be underestimated in this regard, and the real work<br>
lies (imho) in managing software resource, i.e. sessions, port<br>
connections, save states across clusters, etc... This would focus any<br>
technical lv2 expectations in one spot, and remove the need to hack<br>
sequencers constantly, as the lv2 protocol develops further.<br>
<br>
As for multiple app management, you might be missing the boat a bit<br>
here as well. Unlike Win and Mac, with the commerically imposed<br>
limitations, linux gives you more than one to lead an elephant across<br>
a pond of custard.<br>
<br>
Outside of the mainstream distros, who are generally more<br>
commerical-like in their presentation, there's a wealth of choice for<br>
users to really build a great system, unique to requirements. I run<br>
Gentoo, and the fluxbox window manager, with no icons, and driven by<br>
keybindings. Where an app can run without a GUI, then i do that from a<br>
script, or a terminal, saving resources for something else. Linux is<br>
extremely openended in that regard, and with a bit of effort of the<br>
part of a user, he or she can see a direct relationship between effort<br>
in/reward out. So the resources that are chewed up by endless GUI's,<br>
now go where they belong, into running the DAW, for practical use. (I<br>
have in a normal template 7 apps running, of which only 2 are GUI's<br>
for constant use.)<br>
<br>
Also worth noting here that apps like Jconvolver, for instance, can be<br>
run as a standalone single instance, with multiple ins and outs, each<br>
one of which can be configured in a file. 1 impulse for an entire<br>
project, with each in/out configurable.<br>
There's 65 plugins taken care of right there, in one small cli app............<br>
<br>
So Louigi, i disagree with you, and think it IS a personal preference,<br>
and should not be an imposed workflow.<br>
<br>
Why walk with the rest of the turkeys, when you can soar like an eagle?<br>
<br>
Alex.<br>
<div><div></div><div class="h5"><br>
On Sun, Dec 20, 2009 at 9:33 AM, Louigi Verona <<a href="mailto:louigi.verona@gmail.com">louigi.verona@gmail.com</a>> wrote:<br>
> Modular environment is great, but integrated environment seems to be more<br>
> effective. I mean, imho it is not<br>
> a matter of preference and I am not saying no work should be done on session<br>
> management. I am just saying that so<br>
> far my observations show me that integrated environment has too many<br>
> benefits over modular environment.<br>
><br>
> I am relatively new to linux audio, so I would be grateful if you would<br>
> 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<br>
> 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<br>
> me it means working on the problem<br>
> from the outside. All the inter-application management seems to be a<br>
> 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<br>
> 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<br>
> 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<br>
> 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<br>
> 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<br>
> roll.<br>
> Modules of such an app could be very different, like a loop player like<br>
> 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>
> On Sun, Dec 20, 2009 at 4:18 AM, Patrick Shirkey<br>
> <<a href="mailto:pshirkey@boosthardware.com">pshirkey@boosthardware.com</a>> wrote:<br>
>><br>
>> On 12/20/2009 11:48 AM, Louigi Verona wrote:<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>
>><br>
>><br>
>><br>
>> I prefer to work with a modular environment and want to see session<br>
>> management working properly. I would be very disappointed if no further work<br>
>> was done on session management.<br>
>><br>
>> I am looking forward to the progress that will be made over the next<br>
>> couple of years on that front.<br>
>><br>
>><br>
>><br>
>><br>
>><br>
>><br>
>> Patrick Shirkey<br>
>> Boost Hardware Ltd<br>
>><br>
>><br>
>><br>
>><br>
>><br>
>><br>
>> LMMS is an integrated environment and having Zyn inside it is great. LMMS<br>
>> is very promising.<br>
>> But what isn't there are plugins and synthesizers. As an ambient composer<br>
>> 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>
>> On Sun, Dec 20, 2009 at 1:19 AM, <<a href="mailto:fons@kokkinizita.net">fons@kokkinizita.net</a>> wrote:<br>
>>><br>
>>> 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>
>>> And quite probably the authors of these apps are not very<br>
>>> motivated to make them compatible with session handlers.<br>
>>><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<br>
>>> > for<br>
>>> > them, or it is not the right thing for the Linux platform in their<br>
>>> > opinion.<br>
>>><br>
>>> 'Like to work' may not be the correct interpretation. See (4)<br>
>>><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>
>>> 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>
>>><br>
>>> --<br>
>>> FA<br>
>>><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>
>><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>
>><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>
><br>
><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>
><br>
<br>
<br>
<br>
</div></div><font color="#888888">--<br>
<a href="http://www.openoctave.org" target="_blank">www.openoctave.org</a><br>
<br>
<a href="mailto:midi-subscribe@openoctave.org">midi-subscribe@openoctave.org</a><br>
<a href="mailto:development-subscribe@openoctave.org">development-subscribe@openoctave.org</a><br>
</font></blockquote></div><br>