On Sat, 30 Aug 2014 00:01:05 +0100
Harry van Haaren <harryhaaren@xxxxxxxxx> wrote:
> On Fri, Aug 29, 2014 at 8:32 PM, Philipp Überbacher
> <murks@xxxxxxxxxxxxx> 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 :)
Sorry for the mixup, it seems my client can't automatically reply to
list if the list is in the cc (and it seems that is what gmail does by
default, even though it would be perfectly fine if it sent the email
just to the list). The list as second to: (like in this case) seems even
worse, I needed to manually copy the list address into the to: field.
Automation that works 90% of the time really sucks :)
I changed my list options to send duplicate messages, hopefully that
will help my client to do the right thing.
> >> 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
I think the flexibility the command line option offers is nice, but the
documentation could use an example, especially the necessary ' -- ' in
there tripped me up.
> >> > 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.
I guess this packaging trick would work, but for some reason I really
don't like it.
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.
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. I guess this is reasonable but
it fails to help in the initial discovery process. Maybe add a
safe default list, anything with nsm support in debian stable or
something like that.
Finally just having bash completion would be helpful. No idea how hard
it is, probably not too hard. Otherwise it would be useful to just use
an external program like dmenu and pipe that into nsm.
> >> > 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.
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.
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. 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'm not quite sure on what to do if it does not manage to start jack.
Last night I forgot that I had the browser open and a youtube video
on pause. I started jack but it failed since the audio device was still
hogged by the browser. I didn't notice that jack failed and when I
started the NSM session every single program tried to start jack and
failed. The session was still established, sort of. It seems NSM
currently just ignores any errors that occur. With the jackstart client
that might be a bad idea, because if it fails for some reason and
something else succeeds you might run jack with completely wrong
options without noticing. On the other hand, you can't catch all
possible user error.
> >> > 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.
That would be great.
> > 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).
Thanks, but it does not work here. I see this line in the NSM output:
[nsmd] Client NSM Proxy terminated because we told it to.
But the client keeps hanging around.
> >> > 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
It is great that you are lending a helping hand Harry, thanks.
Best Regards,
Philipp
_______________________________________________
Linux-audio-user mailing list
Linux-audio-user@xxxxxxxxxxxxxxxxxxxx
http://lists.linuxaudio.org/listinfo/linux-audio-user
