[LAU] Session management with NSM

From: Harry van Haaren <harryhaaren@email-addr-hidden>
Date: Mon Sep 01 2014 - 18:19:48 EEST

On Mon, Sep 1, 2014 at 3:28 PM, Philipp Überbacher <murks@tuxfamily.org> wrote:
> I guess this packaging trick would work, but for some reason I really
> don't like it.

Well... it is the best way to have NSM-supporting programs announce
that they support NSM, but also gives an opportunity to say "use this
icon file for display in the NSM UI", and various other tweaks...

> An alternative idea: NSM could ship with a list of programs that are
> supported, including the information since which version nsm is
> supported. It could then check the installed version and I guess the
> tricky part is to do that reliably.

Not good: parsing output of programs to identify NSM is a
horrible, tedious and error prone "solution"... or "not solution".

> Another idea: NSM could keep a list of nsm-capable programs that were
> started on this particular machine. Once you started zynaddsubfx
> through nsm it will show up on the list.
Possible, installing a new machine, or users who are just starting won't
know what programs support it: as you mention about discovery.

I feel strongly that the solution here should instantly make it easy
for any application to announce its NSM capability, and that no
user interaction should take place (as begining users won't know that).

> Finally just having bash completion would be helpful.
I've not yet coded that type of functionality: but I presume some
regex search on the contents of $PATH is sufficient. Perhaps there's
a library for such out there.

> Actually jackconnect already does something similar, just the other way
> round. NSM waits for a certain period until all clients are loaded and
> sent ready. If some clients are not fast enough or ports are not there
> it still says that the session has been established and after that
> happened jackconnect starts to connect the ports that are there and
> ignores the ones that are not there.

Actually JackPatch just scan's the JACK graph when new ports arrive,
and attaches them if it "knows" about them in the save-file. There is
no delayed loading and such AFAIK.

> Doing something similar is probably not hard, a jackstart client would
> need to figure out when jack was successfully started (not sure how
> hard that is) and signal nsm to start all other clients.

Yep: it doesn't need to explicitly be "JACK started" as such, just a
"pre-startup" command, that announces "OK" when its done its
setup-job. It can continue to run, and have different / related
functionality then.

> A more generic client that could do the same thing for other clients could be useful,
> but I guess not necessary unless someone actually comes up with a need
> for it.

I program as concise and generic as possible:
when somebody does find a use, it will already be supported.

Cheers, -Harry
_______________________________________________
Linux-audio-user mailing list
Linux-audio-user@lists.linuxaudio.org
http://lists.linuxaudio.org/listinfo/linux-audio-user
Received on Mon Sep 1 20:15:04 2014

This archive was generated by hypermail 2.1.8 : Mon Sep 01 2014 - 20:15:04 EEST