Content-Type: text/plain; charset=ISO-8859-1
Thanks, Alex, for this lengthy explanation. I must think about it. I can
the massive advantages of modular approach for complex setups and specific
How good is it for simple things like making an ordinary song?
Also, tell me guys, is session handling a matter of - what? Apps supporting
it or is
it programmatically a complex problem?
On Sun, Dec 20, 2009 at 2:26 PM, alex stone wrote:
> I'd have to disagree with this. A modular environment makes for better
Content-Type: text/html; charset=ISO-8859-1
Thanks, Alex, for this lengthy explanation. I must think about it. I can ce=
rtainly seethe massive advantages of modular approach for complex setup=
s and specific tasks.How good is it for simple things like making an or=
Also, tell me guys, is session handling a matter of - what? Apps suppor=
ting it or isit programmatically a complex problem?Louigi Veron=
a.On Sun, Dec 20, 2009 at 2:26 PM, alex =
I'd have to d=
isagree with this. A modular environment makes for better
use of resource.
Plugins occupy the same memory allocation as the app, and the same is
true in win and mac. For all the perceived benefits of a "one stop
shop" as far as workflow goes, there are drawbacks. It's noted tha=
some users are ok with freezing tracks to best manage limited
resources, but other's aren't. I spent a large chunk of my working<=
life bouncing tracks on a constant basis, and unlike the linux
environment, i didn't have a choice, no matter the strength of
hardware i was using. It wasn't that long ago that if you wanted to
run a full orchestral template, plus plugins, you needed a cluster of
boxes, or a CRAY. I had a cluster of 5 gig boxes PRECISELY because of
the limitations of allocated app memory space, and i was still
bouncing tracks, if i wanted to run plugins as well.
The modular environment offers a way out of this workflow killer
(imho), and with the massive advantage of using jack, with its
unlimited port structure, plugins no longer need to reside inside an
app, but can be effectively hosted and ported to and from, outside the
app, and in their own memory allocation.
So i would vote against a push to put everything in one app. Quite the
contrary, based on experience, and the many many frustrating hours i
put into bouncing tracks, and handling a pandora's box worth of
workarounds, just to get the client's material done.
Again, i perceive this drive to centralise everything into one "super&=
app, as an intent to be "just like" win and mac, including the ob=
and frustrating workflow limitations, along with any
perceived.....advantages, when a little applied imagination on the
part of users would reveal a much greater use of resource, and
workflow satisfaction, in an unlimited workstation, where only the
strength of the hardware, and the corresponding depth of the user's
There's also the perception that having "lots" of plugins ins=
app is somehow.........cool, and "the best way to work". It isn&#=
beyond the first hour of use. Managing lots of plugins is as much, and
possibly more of a time killer, than setting up a multiapp template in
a linux audio environment. Been there, done that, and it's no
So no to centralisation, and yes to developing dedicated external lv2
plugin hosting more effectively. (Multi hosts, for example.) The power
of JACK should not be underestimated in this regard, and the real work
lies (imho) in managing software resource, i.e. sessions, port
connections, save states across clusters, etc... This would focus any
technical lv2 expectations in one spot, and remove the need to hack
sequencers constantly, as the lv2 protocol develops further.
As for multiple app management, you might be missing the boat a bit
here as well. Unlike Win and Mac, with the commerically imposed
limitations, linux gives you more than one to lead an elephant across
a pond of custard.
Outside of the mainstream distros, who are generally more
commerical-like in their presentation, there's a wealth of choice for
users to really build a great system, unique to requirements. I run
Gentoo, and the fluxbox window manager, with no icons, and driven by
keybindings. Where an app can run without a GUI, then i do that from a
script, or a terminal, saving resources for something else. Linux is
extremely openended in that regard, and with a bit of effort of the
part of a user, he or she can see a direct relationship between effort
in/reward out. So the resources that are chewed up by endless GUI's,
now go where they belong, into running the DAW, for practical use. (I
have in a normal template 7 apps running, of which only 2 are GUI's
for constant use.)
Also worth noting here that apps like Jconvolver, for instance, can be
run as a standalone single instance, with multiple ins and outs, each
one of which can be configured in a file. 1 impulse for an entire
project, with each in/out configurable.
There's 65 plugins taken care of right there, in one small cli app.....=
So Louigi, i disagree with you, and think it IS a personal preference,
and should not be an imposed workflow.
Why walk with the rest of the turkeys, when you can soar like an eagle?
On Sun, Dec 20, 2009 at 9:33 AM, Louigi Verona <email@example.com> wrote:
>>> loading a different configuration in a single app, without eve=