[LAD] NSM - handling large files

rosea.grammostola rosea.grammostola at gmail.com
Wed Apr 4 19:59:09 UTC 2012


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





More information about the Linux-audio-dev mailing list