[LAD] LADI

[Patrick Shirkey]

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 at kokkinizita.net 
> <mailto:fons at 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 at lists.linuxaudio.org
>     <mailto:Linux-audio-dev at lists.linuxaudio.org>
>     http://lists.linuxaudio.org/mailman/listinfo/linux-audio-dev
>
>
>
> _______________________________________________
> Linux-audio-dev mailing list
> Linux-audio-dev at lists.linuxaudio.org
> http://lists.linuxaudio.org/mailman/listinfo/linux-audio-dev
>    
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxaudio.org/pipermail/linux-audio-dev/attachments/20091220/60594970/attachment.html>