On Sun, Dec 20, 2009 at 2:26 PM, alex stone <compose59@gmail.com> 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@gmail.com> 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@boosthardware.com> 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@kokkinizita.net> 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@lists.linuxaudio.org
>>> http://lists.linuxaudio.org/mailman/listinfo/linux-audio-dev
>>
>>
>> _______________________________________________
>> Linux-audio-dev mailing list
>> Linux-audio-dev@lists.linuxaudio.org
>> http://lists.linuxaudio.org/mailman/listinfo/linux-audio-dev
>>
>>
>> _______________________________________________
>> Linux-audio-dev mailing list
>> Linux-audio-dev@lists.linuxaudio.org
>> http://lists.linuxaudio.org/mailman/listinfo/linux-audio-dev
>>
>
>
> _______________________________________________
> Linux-audio-dev mailing list
> Linux-audio-dev@lists.linuxaudio.org
> http://lists.linuxaudio.org/mailman/listinfo/linux-audio-dev
>
>

--
www.openoctave.org

midi-subscribe@openoctave.org
development-subscribe@openoctave.org