On Mon, Sep 1, 2014 at 3:28 PM, Philipp Überbacher <murks@xxxxxxxxxxxxx> 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@xxxxxxxxxxxxxxxxxxxx http://lists.linuxaudio.org/listinfo/linux-audio-user
