Thanks, Alex, for this lengthy explanation. I must think about it. I can
certainly see
the massive advantages of modular approach for complex setups and specific
tasks.
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?
Louigi Verona.
On Sun, Dec 20, 2009 at 2:26 PM, alex stone <compose59@email-addr-hidden> wrote:
> I'd have to disagree 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 that
> 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 obvious
> 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
> wallet, applies.
>
> There's also the perception that having "lots" of plugins inside an
> app is somehow.........cool, and "the best way to work". It isn't,
> 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
> sinecure.
>
> 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?
>
> Alex.
>
> On Sun, Dec 20, 2009 at 9:33 AM, Louigi Verona <louigi.verona@email-addr-hidden>
> wrote:
> > Modular environment is great, but integrated environment seems to be more
> > effective. I mean, imho it is not
> > a matter of preference and I am not saying no work should be done on
> session
> > management. I am just saying that so
> > far my observations show me that integrated environment has too many
> > benefits over modular environment.
> >
> > I am relatively new to linux audio, so I would be grateful if you would
> > explain to me the benefits of modular environment.
> >
> > 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
> > windows, it means the project being dependent on many-many apps. Somehow
> to
> > me it means working on the problem
> > from the outside. All the inter-application management seems to be a
> > difficult problematic and even in the long run is doomed
> > to have many problems due to many apps involved. A dev releases new
> version
> > of his app that has a bug and session
> > handler cannot connect it - and boom!
> >
> >
> > But I also have a suggestion.
> > Is it possible to create an integrated environment based on modules? That
> > is, an app which would have "plugins", but not plugins in a
> > 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
> > 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,
> > for another projects he takes an audio track arranger and also adds a
> piano
> > roll.
> > 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
> > to an integrated sequencer.
> >
> > What do you think?
> >
> >
> >
> > Louigi Verona.
> >
> >
> >
> >
> > On Sun, Dec 20, 2009 at 4:18 AM, Patrick Shirkey
> > <pshirkey@email-addr-hidden> wrote:
> >>
> >> On 12/20/2009 11:48 AM, Louigi Verona wrote:
> >>
> >> So, as a musician, I think linux audio developers have to focus on
> >>
> >> 1. integrated audio environment
> >> 2. sotware synthesizers/effects (LV2)
> >>
> >>
> >>
> >>
> >> 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.
> >>
> >> I am looking forward to the progress that will be made over the next
> >> couple of years on that front.
> >>
> >>
> >>
> >>
> >>
> >>
> >> Patrick Shirkey
> >> Boost Hardware Ltd
> >>
> >>
> >>
> >>
> >>
> >>
> >> LMMS is an integrated environment and having Zyn inside it is great.
> LMMS
> >> is very promising.
> >> But what isn't there are plugins and synthesizers. As an ambient
> composer
> >> I simply lack the tools
> >> I need,
> >>
> >> Hope any of this was useful.
> >>
> >> Louigi Verona.
> >>
> >>
> >>
> >>
> >>
> >>
> >> On Sun, Dec 20, 2009 at 1:19 AM, <fons@email-addr-hidden> wrote:
> >>>
> >>> On Sat, Dec 19, 2009 at 09:15:22PM +0100, rosea grammostola wrote:
> >>>
> >>> > 1) The 'one app with plugins' group. People who are focusing on one
> big
> >>> > app, extended by plugins (Ardour, Qtractor, LV2/DSSI). This group
> >>> > doesn't have much interest in a session handler.
> >>>
> >>> And quite probably the authors of these apps are not very
> >>> motivated to make them compatible with session handlers.
> >>>
> >>> > 2) The people who likes to work with different, small Jack
> applications
> >>> > (ams, aeolus, epichord etc.). These people are interested in a
> session
> >>> > handler. But they think dbus is the wrong approach, it is to limited
> >>> > for
> >>> > them, or it is not the right thing for the Linux platform in their
> >>> > opinion.
> >>>
> >>> 'Like to work' may not be the correct interpretation. See (4)
> >>>
> >>> > 3) Group 3 is the same as group 2, BUT they have chosen dbus as
> >>> > solution. It's the LADI group.
> >>>
> >>> 4. And there's group 4, or maybe that group is just me.
> >>> If there are others I'd like to know. For group 4:
> >>>
> >>> * Sessions are multi-host since there is no other way.
> >>> In most cases all but one of the machines involved will
> >>> be headless, and whatever is supposed to happen there
> >>> is by definition remote controlled instead of being
> >>> launched from a local desktop.
> >>>
> >>> * There are no usable 'single app with plugins' solutions
> >>> since none of these comes close to what would be required,
> >>> in particular w.r.t. the multi-host situation, and also
> >>> because all of these apps silently assume a human user
> >>> watching them and being able to take corrective action
> >>> if necessary. Anything that could pop up an error dialog
> >>> and refuse to proceed until someone reacts is completely
> >>> useless in such systems.
> >>>
> >>> * Any interaction between components of such a system is
> >>> supposed to use networked communication from the start.
> >>> Dual-layer solutions based on some local IPC system plus
> >>> some additional layer that would connect them via a network
> >>> are just an unnecessary complication, and probably one that
> >>> would not provide the right semantics, since the design would
> >>> be based on the single host assumption in blissfull ignorance
> >>> of what it takes to make things work together via a network.
> >>>
> >>> * Given the potential complexity of a networked system, loading
> >>> a 'session' would in general not mean a complete teardown and
> >>> buildup of all apps and their connections, but could just mean
> >>> loading a different configuration in a single app, without even
> >>> any others being aware of this.
> >>>
> >>> People using such systems are *very* motivated to create
> >>> some form session handling, since controlling this sort of
> >>> thing manually is a real PITA, in particular if you have
> >>> to do it a hundred times a day, or if you have to provide
> >>> an interface usable by non-experts. Which is why I have
> >>> been working on this. And given the quite hostile reactions
> >>> shown in recent threads, and the probably minute potential
> >>> user base, the chances that the results will be made public
> >>> are rather small.
> >>>
> >>> Ciao,
> >>>
> >>> --
> >>> FA
> >>>
> >>> _______________________________________________
> >>> Linux-audio-dev mailing list
> >>> Linux-audio-dev@email-addr-hidden
> >>> http://lists.linuxaudio.org/mailman/listinfo/linux-audio-dev
> >>
> >>
> >> _______________________________________________
> >> Linux-audio-dev mailing list
> >> Linux-audio-dev@email-addr-hidden
> >> http://lists.linuxaudio.org/mailman/listinfo/linux-audio-dev
> >>
> >>
> >> _______________________________________________
> >> Linux-audio-dev mailing list
> >> Linux-audio-dev@email-addr-hidden
> >> http://lists.linuxaudio.org/mailman/listinfo/linux-audio-dev
> >>
> >
> >
> > _______________________________________________
> > Linux-audio-dev mailing list
> > Linux-audio-dev@email-addr-hidden
> > http://lists.linuxaudio.org/mailman/listinfo/linux-audio-dev
> >
> >
>
>
>
> --
> www.openoctave.org
>
> midi-subscribe@email-addr-hidden
> development-subscribe@email-addr-hidden
>
_______________________________________________
Linux-audio-dev mailing list
Linux-audio-dev@email-addr-hidden
http://lists.linuxaudio.org/mailman/listinfo/linux-audio-dev
Received on Sun Dec 20 16:15:02 2009
This archive was generated by hypermail 2.1.8 : Sun Dec 20 2009 - 16:15:02 EET