Re: [LAD] NSM - handling large files

On 04/04/2012 08:51 PM, Rui Nuno Capela wrote:
> On 04/04/2012 05:19 PM, rosea.grammostola wrote:
>>
>> ... On that topic I conclude that Qjackctl doesn't support infra
>> clients by purpose and that I don't see it happen that there will be
>> another GUI who does support in the near future.
>>
>
> wait, it's not "by purpose" but just "overlooked" ok?
>
> infra-clients (ie. jack clients unaware of jack-session) and exo-clients
> (non-jack applications) are here subjects of a "covenant": the SM in
> charge, by its particular implementation, follows some god-knows-what
> convention which is NOT bounded by the session protocol (or API) at
> all--of course, the suspects are not session-aware to begin with, so any
> SM can raise its own "convention" and make up its own party--it's a free
> world isn't it? :)
>
> as said, infra/exo-clients support on qjackctl (as a JSM) is "in the
> drawer", meaning it's coming out any day soon. so, is there yet another
> convention party in the making, you ask?

That would take away one, for me important, advantage of NSM compared to
JackSession atm (for the user). All though the implementation in
Pyjacksm, is more cumbersome (using configuration file where you have to
set each application you use) compared to NSM (no thinking, just adding
clients).

One might ask why this isn't already in Qjackctl and how long it will
take though. Which brings me to another possible advantage of NSM. The
fact that the developer is clearly dedicated to the ask in time and
motivation. And also important, he uses NSM himself and believes in
session management. (I little reasons to believe that JS devs use
JackSession themselves. Also if I read your words well Rui, I don't
think you use Qjackctls session option yourself). With JackSession you
lack those things atm (no blaming here). It's probably no accident that
in NSM it's all there, whereas for JackSession some features still have
to be implemented (in the GUI). Personally I asked for the infra client
feature way back, but it's still not there. A new project like NSM seems
to be needed to get some new progress, this is not the kind of
dedication such a project needs (no blaming).

But of course, this are not the only reason to prefer one SM above the
other. As mentioned in my previous mails, there are arguments for me atm
to say that NSM gives a user more then JackSession (even with the
hypothetical level-0). NSM seems to be a SM which has a very good and
simple solution, more functionality then JackSession, without the need
of things like Jackdbus (ladish).
Also I've the opinion that the community should go with the best
implementation. Why go for an implementation which lacks useful
functionality when implementation into the apps are more or less the
same effort?
  I think it's essential to the discussion to get the cards on the
table, so everybody can make up his own mind and decides which SM is the
best solution for the Linuxaudio session puzzle. It would be nice if we
could reach agreement on this, but it's a free world indeed. :)

Regards,
\r

_______________________________________________
Linux-audio-dev mailing list
Linux-audio-dev@email-addr-hidden
http://lists.linuxaudio.org/listinfo/linux-audio-dev
Received on Thu Apr 5 00:15:02 2012