30 Aug
2014
30 Aug
'14
1:01 a.m.
On Fri, Aug 29, 2014 at 8:32 PM, Philipp Überbacher <murks(a)tuxfamily.org> 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
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.
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.
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.
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
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