Re: [LAD] LADI

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
> <mailto: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
> <mailto: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
Received on Sun Dec 20 04:15:06 2009