Re: [LAD] LADI

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 listLinux-audio-dev@email-addr-hidden://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
Received on Sun Dec 20 12:15:02 2009