26 Mar
2012
26 Mar
'12
5:42 p.m.
On 03/24/2012 11:09 PM, Fons Adriaensen wrote:
On Sat, Mar 24, 2012 at 04:19:03PM +0100,
rosea.grammostola wrote:
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
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).