linuxaudio.org

On 03/24/2012 11:09 PM, Fons Adriaensen wrote:

quoted text
> On Sat, Mar 24, 2012 at 04:19:03PM +0100, rosea.grammostola wrote:

>

>> More devs with an opinion? Fons, Torben, Paul, Emanual, ... ?

>

> I haven't used it so far (that is just a matter of limited

> time and priorities). But on reading the available docs my

> first impression is that there is some serious thinking

> behind this. There are quite a few features/choices that

> I do like/agree with.

>

> 1. The use of OSC, defining only the messages and leaving

>     the actual implementation of the OSC interfaces to the

>     application author. This instead of the all too common

>     practice of imposing the use of some library that would

>     integrate badly with the existing framework of an app,

>     duplicate existing functionality or be in conflict with

>     it, or pull in unwanted dependencies.

>

> 2. The use of jackpatch to manage jack connections instead

>     of interfering with Jack itself. It's not clear from the

>     specs, but if this means that NSM will (or can be told

>     to) leave Jack completely alone I'll like it even more.

>

> 3. Clearly defining the way an app should behave w.r.t. its

>     File menu entries (when managed). This is quite intrusive

>     to existing clients, but it is IMHO absolutley essential.

>     Kudos to the designer(s) for the having the courage to do

>     this instead of allowing application developers to take

>     the 'least effort' way (which would of course be better

>     marketing, but invite later misery).

At this point we can at least conclude that the people who have spoken

out about session management and 'the modular approach' in the last

couple of years and/or are involved in thinking about or building a

session manager solution, agree more or less about the fact that NSM has

a nice design and is probably useful in the different workflows. These

people are, to name a few, Fons, Liles (author of NON) and Nedko (all

though he thinks a session manager should do even more, that's what

Ladish does. But ladish supports also JS and NSM (soon)). The JS

developers didn't speak out clearly yet.
What could be an advantage of JS, is that it has JACK as only dependency

and is integrated in JACK. Others however, have pointed out that not

depending on JACK is a big plus for them or even a demand. It gives more

possibilities to have other apps in the session.
As mentioned before, NSM seems to have some advantages JS doesn't have

and lacks some disadvantages Ladish have (you need jackdbus). To call

NSM a good compromise wouldn't give NSM the credits it deserves, but on

the other hand, NSM could probably be a widely supported session API

within the LAD/LAU community. This would be a unique situation.
It's to early to settle down our conclusions though. It would be nice if

more developers dive into it, study the API, study the practical

implications, use NSM and probably even try to build a patch for it into

their program, so we could have a better overview about how developers

think about NSM. It could be that developers prefer a other session API

then NSM. Maybe it's good to give your arguments. It's good to have

disagreements and unity has it's disadvantages, but for an session API

it's also good have agreements. Actually, you need enough of them to be

successful as a Linuxaudio session API...
Best regards,

\r

_______________________________________________

Linux-audio-dev mailing list

Linux-audio-dev@lists.linuxaudio.org

http://lists.linuxaudio.org/listinfo/linux-audio-dev