On Mon, 1 Sep 2014 10:44:32 -0700
"J. Liles" <malnourite@xxxxxxxxx> wrote:
> On Fri, Aug 29, 2014 at 4:01 PM, 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 :)
> >
> > >> 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
> >
>
>
> 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.
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.
> > >> > 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.
> >
> >
> 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.
> > >> > 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.
> >
>
>
> 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
_______________________________________________
Linux-audio-user mailing list
Linux-audio-user@xxxxxxxxxxxxxxxxxxxx
http://lists.linuxaudio.org/listinfo/linux-audio-user
