1 Sep
2014
1 Sep
'14
4:28 p.m.
On Sat, 30 Aug 2014 00:01:05 +0100
Harry van Haaren <harryhaaren(a)gmail.com> wrote:
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.
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.
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.
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.
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.
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
On Fri, Aug 29, 2014 at 8:32 PM, Philipp Überbacher
<murks(a)tuxfamily.org> wrote:
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.
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 :) 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. 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. 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. 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