<div dir="ltr"><div class="gmail_default" style="font-family:arial,helvetica,sans-serif">Just cheering for NSM development here... ;-)<br><br>I'd love to see it grow and become fully supported by even more applications. I'm not a developer so I can't help on that end, but I'm thinking about creating some online tutorials and guides. Anything else I could help with, let me know.<br>
<br></div><div class="gmail_default" style="font-family:arial,helvetica,sans-serif">Bruno<br></div></div><div class="gmail_extra"><br><br><div class="gmail_quote">On Fri, Aug 29, 2014 at 4:01 PM, Harry van Haaren <span dir="ltr"><<a href="mailto:harryhaaren@gmail.com" target="_blank">harryhaaren@gmail.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">On Fri, Aug 29, 2014 at 8:32 PM, Philipp Überbacher <<a href="mailto:murks@tuxfamily.org">murks@tuxfamily.org</a>> wrote:<br>

> Thanks a lot for your reply Harry.<br>
Cheers, be careful to not remove the list from replies: its good to<br>
keep everything in the archives for future reference :)<br>
<div class=""><br>
>> That's the correct way to handle this, as far as I know. Its useful to<br>
>> have different directories on one system: it allows subdiving your<br>
>> available sessions into groups like "albums" or<br>
>> "projects-with-certain-people". Although I agree it feels a little<br>
>> clunky, its quite powerful and useful.<br>
><br>
</div>> There could also be a subdivision in the NSM GUI. Well, the current way<br>
> is certainly the simpler implementation, not sure it's simpler for the<br>
> users :)<br>
<br>
Sure, and my original suggestion was a "stepping-stone" type idea,<br>
with hopes to improve the workflow furthur, once this has become the<br>
"biggest" issue NSM has :D<br>
<div class=""><br>
>> > 2. Adding programs to sessions through the GUI ("Add Client to<br>
>> > Session") is the only way? Is there no way to attach running clients<br>
>> > or at least have some comfort like tab completion to add clients?<br>
>> NSM does not support this "attach" workflow, but tab completion or a<br>
>> list of available (fully supported) NSM clients would be a good<br>
>> improvement on workflow. This should be discussed as to how best<br>
>> implement it: i'm not sure.<br>
><br>
</div>> Right, a list of supported Clients would also be nice, however, I see<br>
> two problems:<br>
> 1. The list would need to be updated somehow, and even then it would be<br>
> a bit problematic because different distributions ship different<br>
> versions of the software. NSM might already list a program as supported<br>
> while the installed version of the program does not yet support NSM.<br>
> 2. The other programs, audio or just related, should ideally also be<br>
> listed, and that task is impossible.<br>
<br>
Actually this might be possible to solve with a "packaging" trick as<br>
such: have programs install a file into a specific location (that is<br>
currently *not* used by any program) to denote its NSM support. I'll<br>
suggest installing a file in /usr/share/nsm/ , and if there's a file<br>
there, then the filename without extension represents that a program<br>
is capable of NSM. This would require *all* NSM clients to explicitly<br>
add an NSM file.<br>
<br>
Perhaps other developers more involved in packaging /<br>
"feature-announcing" will have a better idea here, I'm all ears, my<br>
suggestion above is just that: a suggestion.<br>
<div class=""><br>
>> > 3. Jack and NSM. How do you handle that? It is possible to start<br>
>> > jack through NSM proxy and I guess it is OK to do that as long as<br>
>> > jack reliably starts before jackpatch (something I'm not sure of).<br>
>> > First I had just jackpatch in there and it started jack for me with<br>
>> > a whole lot of options that are unfamiliar to me and probably not<br>
>> > needed.<br>
>><br>
>> I imagine that NSM will launch said JACK apps, and if one is set to<br>
>> "start JACK" on jack_client_open() in its code, then it will start<br>
>> JACK with the settings in  ~/.jackdrc   Perhaps the inclusion of a<br>
>> "Start JACK" type client with particular settings can be implemented<br>
>> in order to handle this? I'm open for suggestions too.<br>
><br>
</div>> That seems to be what happens, and its a race. In my experience<br>
> jackpatch wins the race against jackd, so I have to start jack before<br>
> the session.<br>
> A start_jack client could be useful, but from what I have seen all we<br>
> really need is the possibility to start a client before the others.<br>
> The simple way would be a timeout, but you'd still have the<br>
> race. Ideally there would be some way to tell NSM that jack has<br>
> started and is ready. I have doubts that this is possible with plain<br>
> jack1 and NSM proxy, maybe a special start_jack client could help here.<br>
<br>
NSM doesn't *explicitly* require JACK to be running actually: its<br>
probably its most common use right now, but setting an explicit<br>
dependency on JACK should be avoided. Perhaps a flag could be<br>
introduce on a per-client basis, that represents<br>
"start-before-others". This way, a "jackd" or "start-jack" client can<br>
be loaded before the rest. Or even two or more "before-others" clients<br>
could set up whatever needs setting up, before "normal-time" NSM<br>
clients are loaded.<br>
<br>
Again, welcome input from users / devs.<br>
<div class=""><br>
>> > 4. CLI clients. Are they generally not supported? I added the lv2<br>
>> > host that was recommended to me (jalv) and had to do that through<br>
>> > the NSM proxy, so the settings won't be saved even though the<br>
>> > plugin (fabla in this case) can save its settings. This sort of<br>
>> > defeats session management. With all the CLI tools we have it would<br>
>> > be a pitty if that was generally not supported. On a sidenote, can<br>
>> > someone recommend a plugin host that is supported?<br>
>><br>
>> CLI clients are supported just like clients with a GUI, there is no<br>
>> difference to NSM. The issue you're encountering here is that JALV<br>
>> currently doesn't support NSM, which is something that I agree needs<br>
>> fixing. I'll put JALV NSM support on the TODO, its something I've<br>
>> lacked myself too.<br>
><br>
</div>> Ok, great. Does a CLI NSM client exist that I can try?<br>
<br>
None that I know of right now: Indeed JALV needs NSM, and jalv (the<br>
command line version) will then be such a client.<br>
<br>
> I also noticed that JALV keeps hanging around<br>
> after I close the session it is part of, is that expected behavior?<br>
<br>
This can be fixed by sending the "SIGTERM" in the lower part of the<br>
"nsm-proxy" configuration dialog (where you fill in "jalv.gtk", and<br>
the arguments to load a certain plugin).<br>
<div class=""><br>
>> > Well, that's it for now. Last time I heard about NSM I got the<br>
>> > impression that it takes care of session management once and for<br>
>> > all, but the first half our gave me a different impression.<br>
>> OpenAV stands behind NSM: I'm willing to do my best to cooperate with<br>
>> project developers to implement NSM in various programs, and improve<br>
>> the workflow of session management.<br>
>><br>
>> If there's any furthur questions, please ask, in the mean time, I'll<br>
>> try code up some NSM :) -Harry<br>
><br>
</div>> Thanks a lot for your help Harry, we have used crutches for session<br>
> management long enough.<br>
<br>
Agreed, lets try fix this together with the communit in the next<br>
weeks, and never look back ;)<br>
Cheers, -Harry<br>
<div class="HOEnZb"><div class="h5">_______________________________________________<br>
Linux-audio-user mailing list<br>
<a href="mailto:Linux-audio-user@lists.linuxaudio.org">Linux-audio-user@lists.linuxaudio.org</a><br>
<a href="http://lists.linuxaudio.org/listinfo/linux-audio-user" target="_blank">http://lists.linuxaudio.org/listinfo/linux-audio-user</a><br>
</div></div></blockquote></div><br></div>