1 Sep
2014
1 Sep
'14
11:46 p.m.
On Mon, 1 Sep 2014 10:44:32 -0700
"J. Liles" <malnourite(a)gmail.com> wrote:
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.
I like the desktop file idea a bit more, simply because it uses an
existing mechanism. I understand that scanning desktop files could
increase startup time, but I have no idea how long it would actually
take. On my machine I have around 180 files in /usr/share/applications,
but maybe another directory would also need to be scanned. In case it
takes significant time something like a simple cache could help to
speed things up on subsequent runs. I have no idea how long reading
those files takes.
I don't think that the chicken-egg problem is significant. You could
suggest to developers to add a desktop file with the necessary
information. I wouldn't require it but strongly suggest it. It is an
almost trivial amount of work.
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.
Thanks for reminding me of the ~/.jackdrc. However, a simple jackstart
client (or a generic mechanism that can be used for this purpose) would
allow different sessions to use different jack settings. A simple
example: One session may require jack to run at 48 kHz, another at 44.1
kHz, a third might require jack to run at a very low latency setting.
~/.jackdrc does not help in this case.
Best regards,
Philipp
On Fri, Aug 29, 2014 at 4:01 PM, Harry van Haaren
<harryhaaren(a)gmail.com> wrote:
For me the symlink is not an option since I don't want to have yet
another directory hang around in my home directory. Too many programs
still do that. I want to have some programs data directories somewhere
else, not in with my personal stuff.
The GUI could show different sessions, depending on to which nsmd it is
connected to. I see how this may complicate things a little, but I
don't see a big problem.
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
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. 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.
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. > 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.