Re: [LAU] Session management with NSM

Just cheering for NSM development here... ;-)

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.

Bruno

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
>
> >> > 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@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 Sun Aug 31 04:15:01 2014