Re: [LAD] LADI

Hey guys!

I am not a developer, I am a musician who has decided to try to switch to
Linux.

I am not sure how many times this has been discussed and I have signed up to
this list
being interested in audio linux development, specifically lv2 plugins.

But I can say that in three months of very active work with audio, learning
new concepts,
trying out Ardour, Qtractor, Zyn synth, Patchage, Kluppe, Sooperlooper,
JackRack
and LMMS, I can say that although modular approach has its charm and even
use,
for most of the cases it is very awkward and very difficult to set up and
any potential solution
bumps into many problems since any session management system will have to
work with different
apps and it means more chances for errors - excuse me if I am not correct.

On the other hand, an integrated environment, while opposed by many linux
users and programmers,
gives much more control to the musician both in live performance and studio
work.

I must say that I have used Ardour, Kluppe and Jack Rack and Patchage in
live performance and it was great,
but I had to play only one tune. To set up the tune I had to open 4
instances of Kluppe, one Jack Rack,, open Ardour,
load session, load Patchage, disconnect unnecessary connections, connect
Ardour to Jack Rack (for some reason
it does not save connections to Jack Rack) and then connect all of that to a
midi keyboard. This usually takes around
a minute of time.

If I had to play another tune, it would be a disaster, since I would have to
close lots of stuff and reopen, not to mention that
with a complex setup it is difficult to forget.

As for studio work, setting up a whole big number of apps to work on a tune
is very difficult. It also seems to bring up a technical
problem - please sorry again if my technical conclusions are wrong - but
with an integrated environment it seems it is easier to do
memory management. With several apps Jack can just throw an app out without
warning and it is very frustrating and time consuming.

So, as a musician, I think linux audio developers have to focus on

1. integrated audio environment
2. sotware synthesizers/effects (LV2)

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