On Fri, Aug 29, 2014 at 8:32 PM, Philipp Überbacher <murks@tuxfamily.org> wrote:
> Thanks a lot for your reply Harry.
Cheers, be careful to not remove the list from replies: its good to
keep everything in the archives for future reference :)

>> That's the correct way to handle this, as far as I know. Its useful to
>> have different directories on one system: it allows subdiving your
>> available sessions into groups like "albums" or
>> "projects-with-certain-people". Although I agree it feels a little
>> clunky, its quite powerful and useful.
>

> There could also be a subdivision in the NSM GUI. Well, the current way
> is certainly the simpler implementation, not sure it's simpler for the
> users :)

Sure, and my original suggestion was a "stepping-stone" type idea,
with hopes to improve the workflow furthur, once this has become the
"biggest" issue NSM has :D

>> > 2. Adding programs to sessions through the GUI ("Add Client to
>> > Session") is the only way? Is there no way to attach running clients
>> > or at least have some comfort like tab completion to add clients?
>> NSM does not support this "attach" workflow, but tab completion or a
>> list of available (fully supported) NSM clients would be a good
>> improvement on workflow. This should be discussed as to how best
>> implement it: i'm not sure.
>

> Right, a list of supported Clients would also be nice, however, I see
> two problems:
> 1. The list would need to be updated somehow, and even then it would be
> a bit problematic because different distributions ship different
> versions of the software. NSM might already list a program as supported
> while the installed version of the program does not yet support NSM.
> 2. The other programs, audio or just related, should ideally also be
> listed, and that task is impossible.

Actually this might be possible to solve with a "packaging" trick as
such: have programs install a file into a specific location (that is
currently *not* used by any program) to denote its NSM support. I'll
suggest installing a file in /usr/share/nsm/ , and if there's a file
there, then the filename without extension represents that a program
is capable of NSM. This would require *all* NSM clients to explicitly
add an NSM file.

Perhaps other developers more involved in packaging /
"feature-announcing" will have a better idea here, I'm all ears, my
suggestion above is just that: a suggestion.

>> > 3. Jack and NSM. How do you handle that? It is possible to start
>> > jack through NSM proxy and I guess it is OK to do that as long as
>> > jack reliably starts before jackpatch (something I'm not sure of).
>> > First I had just jackpatch in there and it started jack for me with
>> > a whole lot of options that are unfamiliar to me and probably not
>> > needed.
>>
>> I imagine that NSM will launch said JACK apps, and if one is set to
>> "start JACK" on jack_client_open() in its code, then it will start
>> JACK with the settings in  ~/.jackdrc   Perhaps the inclusion of a
>> "Start JACK" type client with particular settings can be implemented
>> in order to handle this? I'm open for suggestions too.
>

> That seems to be what happens, and its a race. In my experience
> jackpatch wins the race against jackd, so I have to start jack before
> the session.
> A start_jack client could be useful, but from what I have seen all we
> really need is the possibility to start a client before the others.
> The simple way would be a timeout, but you'd still have the
> race. Ideally there would be some way to tell NSM that jack has
> started and is ready. I have doubts that this is possible with plain
> jack1 and NSM proxy, maybe a special start_jack client could help here.

NSM doesn't *explicitly* require JACK to be running actually: its
probably its most common use right now, but setting an explicit
dependency on JACK should be avoided. Perhaps a flag could be
introduce on a per-client basis, that represents
"start-before-others". This way, a "jackd" or "start-jack" client can
be loaded before the rest. Or even two or more "before-others" clients
could set up whatever needs setting up, before "normal-time" NSM
clients are loaded.

Again, welcome input from users / devs.

>> > 4. CLI clients. Are they generally not supported? I added the lv2
>> > host that was recommended to me (jalv) and had to do that through
>> > the NSM proxy, so the settings won't be saved even though the
>> > plugin (fabla in this case) can save its settings. This sort of
>> > defeats session management. With all the CLI tools we have it would
>> > be a pitty if that was generally not supported. On a sidenote, can
>> > someone recommend a plugin host that is supported?
>>
>> CLI clients are supported just like clients with a GUI, there is no
>> difference to NSM. The issue you're encountering here is that JALV
>> currently doesn't support NSM, which is something that I agree needs
>> fixing. I'll put JALV NSM support on the TODO, its something I've
>> lacked myself too.
>

> Ok, great. Does a CLI NSM client exist that I can try?

None that I know of right now: Indeed JALV needs NSM, and jalv (the
command line version) will then be such a client.

> I also noticed that JALV keeps hanging around
> after I close the session it is part of, is that expected behavior?

This can be fixed by sending the "SIGTERM" in the lower part of the
"nsm-proxy" configuration dialog (where you fill in "jalv.gtk", and
the arguments to load a certain plugin).

>> > Well, that's it for now. Last time I heard about NSM I got the
>> > impression that it takes care of session management once and for
>> > all, but the first half our gave me a different impression.
>> OpenAV stands behind NSM: I'm willing to do my best to cooperate with
>> project developers to implement NSM in various programs, and improve
>> the workflow of session management.
>>
>> If there's any furthur questions, please ask, in the mean time, I'll
>> try code up some NSM :) -Harry
>

> Thanks a lot for your help Harry, we have used crutches for session
> management long enough.

Agreed, lets try fix this together with the communit in the next
weeks, and never look back ;)
Cheers, -Harry

_______________________________________________
Linux-audio-user mailing list
Linux-audio-user@lists.linuxaudio.org
http://lists.linuxaudio.org/listinfo/linux-audio-user