Re: [LAU] Session management with NSM

On Fri, Aug 29, 2014 at 4:01 PM, Harry van Haaren <harryhaaren@email-addr-hidden>
wrote:

> On Fri, Aug 29, 2014 at 8:32 PM, Philipp Überbacher <murks@email-addr-hidden.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
>

One can also just create a symlink of ~/NSM Sessions to something else.
That doesn't seem any more difficult to me than editing a configuration
file. It would probably be nice do have this be configurable in the GUI,
though, for non-cli types. However, keep in mind that the NSM GUI and
daemon don't necessarily have to run on the same host, so things like this
are always more complicated than they seem on the surface. So again, it
seems that the existing methods are simpler.

> >> > 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.
>
>
This is something that would go into the .desktop files of applications as
a capability. Unfortunately, it's a chicken and egg situation where there's
no point in scanning .desktop files for NSM capability until applications
provide it, and there's no point in applications providing it until other
programs do something with the information. On top of that, scanning all
the .desktop files on a system will take some time at startup.

> >> > 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.
>

The existing JACK autostart mechanism works fine as far as I know (although
I don't use it personally), I don't see any need for additional support.
Certainly I have no intention of adding any qjackctl like configuration
features. Just create a ~/.jackdrc and you're done.

>
> >> > 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@email-addr-hidden
> http://lists.linuxaudio.org/listinfo/linux-audio-user
>

_______________________________________________
Linux-audio-user mailing list
Linux-audio-user@email-addr-hidden
http://lists.linuxaudio.org/listinfo/linux-audio-user
Received on Tue Sep 2 00:15:02 2014