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 
31 Aug
31 Aug
2:28 a.m.
New subject: Session management with NSM
Just cheering for NSM development here... ;-)
I'd love to see it grow and become fully supported by even more
applications. I'm not a developer so I can't help on that end, but I'm
thinking about creating some online tutorials and guides. Anything else I
could help with, let me know.
Bruno
On Fri, Aug 29, 2014 at 4:01 PM, Harry van Haaren <harryhaaren(a)gmail.com>
wrote:
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
_______________________________________________
Linux-audio-user mailing list
Linux-audio-user(a)lists.linuxaudio.org
http://lists.linuxaudio.org/listinfo/linux-audio-user
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 
1 Sep
1 Sep
4:28 p.m.
New subject: Session management with NSM
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 
7:44 p.m.
New subject: Session management with NSM
On Fri, Aug 29, 2014 at 4:01 PM, Harry van Haaren <harryhaaren(a)gmail.com>
wrote:
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.
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.
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
_______________________________________________
Linux-audio-user mailing list
Linux-audio-user(a)lists.linuxaudio.org
http://lists.linuxaudio.org/listinfo/linux-audio-user
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. 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
11:46 p.m.
New subject: Session management with NSM
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. 
2 Sep
2 Sep
12:42 a.m.
New subject: Session management with NSM
On Mon, 1 Sep 2014, Philipp Überbacher wrote:
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.
Yes there are other directories to search, but in general they are session
specific and should not have application *.desktop files in them. The one
other place that may need to be looked in would be:
~/.local/share/applications/
For user added files... though to be honest, I do not think alacart or any
user is likely to add anything worth your looking at anyway.
A cache file would help for sure. Keeping the m date in there of the
directory may be enough to know if anything has changed since the last
time.
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.
One has to start somewhere :) Many developers do not make desktop files
for their work, so it ends up getting done by the packager (man pages too
by the way).
> The existing JACK autostart mechanism works fine
as far as I know
No. Jackdbus conflicks with jackd and there seems to be no way for auto
starting jackdbus. There are functions that are not possible without
jackdbus. So having an appliocation autostart jackd kills jackdbus. I
ended up chmod -x jackd.
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.
With jackdbus many of these things can be changed "on the fly". However,
that is not the best as some applications don't like getting these things
changed while they are running. Latency can be changed at any time with
jackd too.
--
Len Ovens
www.ovenwerks.net
8:42 p.m.
New subject: Session management with NSM
On Mon, Sep 1, 2014 at 6:44 PM, J. Liles <malnourite(a)gmail.com> wrote:
This is something that would go into the .desktop
files of applications as a
capability
Cool: then its time to make it work in the UI, and after that bug-report every
app that is useful with NSM and doesn't have it in its .desktop.
Certainly I have no intention of adding any qjackctl
like configuration features.
Which also isn't what I'm suggesting
Just create a ~/.jackdrc and you're done.
That doesn't work per session, and mixing / live-performance have a need
for very different JACK settings, perhaps even different interfaces.
It could be discussed to "highjack" ~/.jackdrc by copying an NSM sessions
.jackdrc to ~/ although a hack solution for a power-user, I think its not
a good way to go for beginners. We need something to fix this... ideas?
--
Cheers, -Harry
www.openavproductions.com
10:01 p.m.
New subject: Session management with NSM
On Tue, 2 Sep 2014 19:42:16 +0100
Harry van Haaren <harryhaaren(a)gmail.com> wrote:
I agree here too. All I imagine is something that is able to start jack
before everything else, nothing more than that. On the UI side it could
be a simple field where you enter the jackd command you want to use
for this session.
For my taste this solution is far too hackish. I would not expect or
want any program to modify my ~/.jackdrc.
If jack is already running when the programs start then the ~/.jackdrc
is irrelevant. I'm still in favor of a simple jackstart program
(generic if possible or especially for jack).
The only issue I see with such a program is that it may be hard to tell
when jack is actually started. Maybe I'm wrong and there is an easy way
to tell that I'm not aware of. Maybe something in the jackd API would
help? Would jackctl_server_start() work?
http://jackaudio.org/api/group__ControlAPI.html#ga0ee7d8a3386503ce677f1adbd…
Regards,
Philipp
On Mon, Sep 1, 2014 at 6:44 PM, J. Liles
<malnourite(a)gmail.com> wrote:
Agreed, I think it's doable. It is little work per-program. I think it
would be sensible to check how real the performance issue is, but the
mtime check Len suggested plus some caching would take care of it most
of the time if the performance issue is real at all.
This is something that would go into the .desktop
files of
applications as a capability
Cool: then its time to make it work in the UI, and after that
bug-report every app that is useful with NSM and doesn't have it in
its .desktop. Certainly I
have no intention of adding any qjackctl like
configuration features.
Which also isn't what I'm suggesting Just create a
~/.jackdrc and you're done.
That doesn't work per session, and mixing /
live-performance have a
need for very different JACK settings, perhaps even different
interfaces.
It could be discussed to "highjack" ~/.jackdrc by copying an NSM
sessions .jackdrc to ~/ although a hack solution for a power-user,
I think its not a good way to go for beginners. We need something to
fix this... ideas?
11:30 p.m.
New subject: Session management with NSM
On Tue, 2 Sep 2014, Philipp Überbacher wrote:
The only issue I see with such a program is that it
may be hard to tell
when jack is actually started. Maybe I'm wrong and there is an easy way
to tell that I'm not aware of. Maybe something in the jackd API would
help? Would jackctl_server_start() work?
http://jackaudio.org/api/group__ControlAPI.html#ga0ee7d8a3386503ce677f1adbd…
Ya, that is an issue. I use jackdbus on my system and have found that the
auto start jack when an app finds it is not runniing very frustrating.
This is perhaps not so much of a problem with jackd, but in the case you
are talking about where the user wants jack started with other than
~.jackdrc it would also be a pain. You would almost have to include the
dreaded killall -9 jackd... Even in this case race conditions could make
it not work. I think a failed jack_client_open() would give some clue, but
would not help with a hung jackd process.
--
Len Ovens
www.ovenwerks.net
11:32 p.m.
New subject: Session management with NSM
On Tue, Sep 2, 2014 at 1:00 PM, Philipp Überbacher <murks(a)tuxfamily.org>
wrote:
For my taste this solution is far too hackish. I would not expect or
want any program to modify my ~/.jackdrc.
If jack is already running when the programs start then the ~/.jackdrc
is irrelevant. I'm still in favor of a simple jackstart program
(generic if possible or especially for jack).
The only issue I see with such a program is that it may be hard to tell
when jack is actually started. Maybe I'm wrong and there is an easy way
to tell that I'm not aware of. Maybe something in the jackd API would
help? Would jackctl_server_start() work?
http://jackaudio.org/api/group__ControlAPI.html#ga0ee7d8a3386503ce677f1adbd…
Regards,
Philipp
_______________________________________________
Linux-audio-user mailing list
Linux-audio-user(a)lists.linuxaudio.org
http://lists.linuxaudio.org/listinfo/linux-audio-user
On Tue, 2 Sep 2014 19:42:16 +0100
Harry van Haaren <harryhaaren(a)gmail.com> wrote:
I agree here too. All I imagine is something that is able to start jack
before everything else, nothing more than that. On the UI side it could
be a simple field where you enter the jackd command you want to use
for this session.
The whole idea of killing and restarting JACK is totally incompatible with
session 'switch' functionality. All clients would have to be killed, JACK
killed, JACK restarted, and clients restarted. Probably even if the
configuration isn't different, as it would be a PITA to try to model JACK's
state in that way.
To me, this looks like creating problems and complexity for no real
benefit. If autostart doesn't work, then that's a JACK problem and should
be fixed there. Or--just don't rely on autostart in the first place. IMHO
that's more of a workaround to allow 'desktop' type use of JACK apps
(probably with auto-connect as well) and doesn't apply to a production
workflow.
On Mon, Sep 1, 2014 at 6:44 PM, J. Liles
<malnourite(a)gmail.com> wrote:
Agreed, I think it's doable. It is little work per-program. I think it
would be sensible to check how real the performance issue is, but the
mtime check Len suggested plus some caching would take care of it most
of the time if the performance issue is real at all.
This is something that would go into the .desktop
files of
applications as a capability
Cool: then its time to make it work in the UI, and after that
bug-report every app that is useful with NSM and doesn't have it in
its .desktop. Certainly
I have no intention of adding any qjackctl like
configuration features.
Which also isn't what I'm suggesting Just create a ~/.jackdrc and you're done.
That doesn't work per session, and mixing / live-performance have a
need for very different JACK settings, perhaps even different
interfaces.
It could be discussed to "highjack" ~/.jackdrc by copying an NSM
sessions .jackdrc to ~/ although a hack solution for a power-user,
I think its not a good way to go for beginners. We need something to
fix this... ideas?
11:50 p.m.
New subject: Session management with NSM
On Tue, 2 Sep 2014 14:31:59 -0700
"J. Liles" <malnourite(a)gmail.com> wrote:
On Tue, Sep 2, 2014 at 1:00 PM, Philipp Überbacher
<murks(a)tuxfamily.org> wrote:
I have the feeling that we are talking past each other for some reason.
You kill and start all programs anyway if you switch sessions, why not
jack as well? It would only be natural. To be honest, I did not
consider the killing jack part so far.
How would you go about things as it is now if you want to switch
between sessions that require different sample rates?
You would close session one, kill jack, restart jack with the settings
required for session two and start session two. Why not include that in
the session management? It seems like the logical thing to do.
I do not want to rely on autostart, I want to explicitly start jack
with specific per-session settings as part of the session management.
I hope that makes things a bit clearer.
Regards,
Philipp
On Tue, 2 Sep 2014 19:42:16 +0100
Harry van Haaren <harryhaaren(a)gmail.com> wrote:
I agree here too. All I imagine is something that is able to start
jack before everything else, nothing more than that. On the UI side
it could be a simple field where you enter the jackd command you
want to use for this session.
The whole idea of killing and restarting JACK is totally incompatible
with session 'switch' functionality. All clients would have to be
killed, JACK killed, JACK restarted, and clients restarted. Probably
even if the configuration isn't different, as it would be a PITA to
try to model JACK's state in that way.
To me, this looks like creating problems and complexity for no real
benefit. If autostart doesn't work, then that's a JACK problem and
should be fixed there. Or--just don't rely on autostart in the first
place. IMHO that's more of a workaround to allow 'desktop' type use
of JACK apps (probably with auto-connect as well) and doesn't apply
to a production workflow. On Mon, Sep 1, 2014 at 6:44 PM, J. Liles
<malnourite(a)gmail.com>
wrote:
Agreed, I think it's doable. It is little work per-program. I think
it would be sensible to check how real the performance issue is,
but the mtime check Len suggested plus some caching would take care
of it most of the time if the performance issue is real at all.
This is something that would go into the .desktop
files of
applications as a capability
Cool: then its time to make it work in the UI, and after that
bug-report every app that is useful with NSM and doesn't have it
in its .desktop. Certainly
I have no intention of adding any qjackctl like
configuration features.
Which also isn't what I'm suggesting
3 Sep
3 Sep
12:06 a.m.
New subject: Session management with NSM
On Tue, Sep 2, 2014 at 2:50 PM, Philipp Überbacher <murks(a)tuxfamily.org>
wrote:
On Tue, 2 Sep 2014 14:31:59 -0700
"J. Liles" <malnourite(a)gmail.com> wrote:
I do not do that though. NSM is the only session manager to support live
'switch'ing of sessions--no programs have to be restarted that support the
'switch' functionality (all the non stuff does).
The only reason I can think of that you'd want to swtich to a session with
a different sample rate is if you're swtiching between e.g. making music
and doing cinema sound track or somesuch and there are many other things
you'd likely want to change for that as well.
I think it's stretching quite a bit to argue that this (including JACK's
setup in the session) is necessary functionality.
To make my position clear, let me define an example of my workflow:
1. Make coffee
2. Start JACK with the desired parameters for the type of work I'm planning
to do. E.g. buffer size
3. Run NSM
4. Open session and work on it.
5. Switch to other (related sessions) [why would these be at any other
sample rate
6. If I need to alter JACK's parameters, stop session, run e.g.
jack_bufsize, reopen session
7. Get work done instead of dreaming up ways to implement complicated
features nobody actually needs
But wait, there's more...
Now I want to work on the road, so I sync the relevant sessions to my
laptop. My laptop has a different sound card and requires different JACK
settings (and it much more limited in ability to achieve low latencies).
In my workflow, this presents no problem. If I implemented this JACK
configuration feature, then I would have CREATED a problem where there were
none before.
Hopefully you can see why I'm not interested in implementing this feature.
On Tue, Sep 2, 2014 at 1:00 PM, Philipp
Überbacher
<murks(a)tuxfamily.org> wrote:
I have the feeling that we are talking past each other for some reason.
You kill and start all programs anyway if you switch sessions, why not
jack as well? It would only be natural. To be honest, I did not
consider the killing jack part so far.
How would you go about things as it is now if you want to switch
between sessions that require different sample rates?
You would close session one, kill jack, restart jack with the settings
required for session two and start session two. Why not include that in
the session management? It seems like the logical thing to do.
I do not want to rely on autostart, I want to explicitly start jack
with specific per-session settings as part of the session management.
I hope that makes things a bit clearer.
On Tue, 2 Sep 2014 19:42:16 +0100
Harry van Haaren <harryhaaren(a)gmail.com> wrote:
The whole idea of killing and restarting JACK is totally incompatible
with session 'switch' functionality. All clients would have to be
killed, JACK killed, JACK restarted, and clients restarted. Probably
even if the configuration isn't different, as it would be a PITA to
try to model JACK's state in that way.
To me, this looks like creating problems and complexity for no real
benefit. If autostart doesn't work, then that's a JACK problem and
should be fixed there. Or--just don't rely on autostart in the first
place. IMHO that's more of a workaround to allow 'desktop' type use
of JACK apps (probably with auto-connect as well) and doesn't apply
to a production workflow. On Mon, Sep 1, 2014 at 6:44 PM, J. Liles
<malnourite(a)gmail.com>
wrote:
> This is something that would go into the .desktop files of
> applications as a capability
Cool: then its time to make it work in the UI, and after that
bug-report every app that is useful with NSM and doesn't have it
in its .desktop.
Agreed, I think it's doable. It is little work per-program. I think
it would be sensible to check how real the performance issue is,
but the mtime check Len suggested plus some caching would take care
of it most of the time if the performance issue is real at all.
> Certainly I have no intention of adding any
qjackctl like
> configuration features.
Which also isn't what I'm suggesting
I agree here too. All I imagine is something that is able to start
jack before everything else, nothing more than that. On the UI side
it could be a simple field where you enter the jackd command you
want to use for this session.
Regards,
Philipp
_______________________________________________
Linux-audio-user mailing list
Linux-audio-user(a)lists.linuxaudio.org
http://lists.linuxaudio.org/listinfo/linux-audio-user
12:22 a.m.
New subject: Session management with NSM
On Tue, Sep 2, 2014 at 11:06 PM, J. Liles <malnourite(a)gmail.com> wrote:
In my workflow, this presents no problem. If I
implemented this JACK
configuration feature, then I would have CREATED a problem where there were
none before.
Hopefully you can see why I'm not interested in
implementing this feature.
Yep. Good point, it seemed like something that would be
nice to handle in NSM,
but i now agree that NSM should *not* handle jack settings. The user has to do
this manually: its not feasible to script / auto-save JACK settings reliably.
So before starting the NSM UI / nsmd, it might be worth checking if JACK is
running, and if its not, providing an option to ask
A) Do you want to start JACK a la ~/.jackdrc
B) Continue without JACK
C) Quit
Does that seem reasonable? I'm thinking about beginner users, who are not
familiar with the eco-system, and making this as usable as possible.
Cheers, -Harry
www.openavproductions.com
12:57 a.m.
New subject: Session management with NSM
On Tue, 2 Sep 2014 23:22:56 +0100
Harry van Haaren <harryhaaren(a)gmail.com> wrote:
On Tue, Sep 2, 2014 at 11:06 PM, J. Liles
<malnourite(a)gmail.com>
wrote:
Well, I still think it is a good idea. It would not create problems for
you, simply because you're not forced to use this if it is realised as
a client in the spirit of jackconnect.
I did not know that nsm supports live switching of sessions without
restarting clients, but in case you need to change the jack sample rate
you most likely can't do that anyway. I guess that with that
functionality in use 'live switching' would not be possible or
only in special cases (identical jack settings).
That would be the only drawback I can see.
Regards,
Philipp
In my workflow, this presents no problem. If I
implemented this JACK
configuration feature, then I would have CREATED a problem where
there were none before.
Hopefully you can see why I'm not interested
in implementing this
feature.
Yep. Good point, it seemed like something that would be nice to
handle in NSM, but i now agree that NSM should *not* handle jack
settings. The user has to do this manually: its not feasible to
script / auto-save JACK settings reliably.
So before starting the NSM UI / nsmd, it might be worth checking if
JACK is running, and if its not, providing an option to ask
A) Do you want to start JACK a la ~/.jackdrc
B) Continue without JACK
C) Quit
Does that seem reasonable? I'm thinking about beginner users, who are
not familiar with the eco-system, and making this as usable as
possible.
Cheers, -Harry
2:32 a.m.
New subject: Session management with NSM
On Tue, Sep 2, 2014 at 3:57 PM, Philipp Überbacher <murks(a)tuxfamily.org>
wrote:
On Tue, 2 Sep 2014 23:22:56 +0100
Harry van Haaren <harryhaaren(a)gmail.com> wrote:
Theoretically there's no conflict between sample rate changes and
switching--assuming of course that A) all of the clients involved can deal
with runtime sample rate changes and B) that none of them will complain if
the JACK sample rate and the project sample rate differ (however briefly).
And likewise, theoretically it's fine to change sample rate and buffer size
without stopping JACK clients.
In fact, I do test all the Non stuff for this scenario. But I don't usually
do that in practice though. Too many bad memories from the time when
running jack_bufsize with clients attached would crash stuff.
On Tue, Sep 2, 2014 at 11:06 PM, J. Liles
<malnourite(a)gmail.com>
wrote:
Well, I still think it is a good idea. It would not create problems for
you, simply because you're not forced to use this if it is realised as
a client in the spirit of jackconnect.
I did not know that nsm supports live switching of sessions without
restarting clients, but in case you need to change the jack sample rate
you most likely can't do that anyway. I guess that with that
functionality in use 'live switching' would not be possible or
only in special cases (identical jack settings).
That would be the only drawback I can see.
In my workflow, this presents no problem. If I
implemented this JACK
configuration feature, then I would have CREATED a problem where
there were none before.
Hopefully you can see why I'm not interested
in implementing this
feature.
Yep. Good point, it seemed like something that would be nice to
handle in NSM, but i now agree that NSM should *not* handle jack
settings. The user has to do this manually: its not feasible to
script / auto-save JACK settings reliably.
So before starting the NSM UI / nsmd, it might be worth checking if
JACK is running, and if its not, providing an option to ask
A) Do you want to start JACK a la ~/.jackdrc
B) Continue without JACK
C) Quit
Does that seem reasonable? I'm thinking about beginner users, who are
not familiar with the eco-system, and making this as usable as
possible.
Cheers, -Harry Regards,
Philipp
_______________________________________________
Linux-audio-user mailing list
Linux-audio-user(a)lists.linuxaudio.org
http://lists.linuxaudio.org/listinfo/linux-audio-user
3:08 a.m.
New subject: Session management with NSM
On Tue, 2 Sep 2014, J. Liles wrote:
And likewise, theoretically it's fine to change
sample rate and buffer size without
stopping JACK clients.
In fact, I do test all the Non stuff for this scenario. But I don't usually do that
in
practice though. Too many bad memories from the time when running jack_bufsize with
clients attached would crash stuff.
I do use jack_bufsize, a jack client can deal with it. Ardour will keep
playing back thorugh a bufer size change with only an audible glitch going
the wrong way, but Phasex will sound strange untill buff size goes back to
where it started or is restarted. I haven't had anything crash when I do
this ... yet :)
--
Len Ovens
www.ovenwerks.net
5:49 a.m.
New subject: Session management with NSM
On 09/02/2014 11:57 PM, Philipp Überbacher wrote:
I did not know that nsm supports live switching of
sessions without
restarting clients, but in case you need to change the jack sample rate
you most likely can't do that anyway.
FYI: You can change sample rate on the fly (e.g. without stopping JACK)
if you use JACK2 and switch-master.
When this happens clients will receive buffer-size and sample-rate
change callbacks.
9:04 a.m.
New subject: Session management with NSM
So the problem here, as I see it, is that Jack itself is not an NSM
aware client.
My perception of NSM always was that it is not strictly bound to jack
but jack is another client. If jack would be a NSM client which supports
switch and saves it settings in the session folder you can save the
samplerate (and the connections, without a special program).
On the other hand that binds a session to specific jack settings again,
which is bad. Are there any examples of NSM clients that deal with
system-specific settings?
Nils
On 03.09.2014 05:49, Filipe Coelho wrote:
On 09/02/2014 11:57 PM, Philipp Überbacher wrote:
I did not know that nsm supports live switching
of sessions without
restarting clients, but in case you need to change the jack sample rate
you most likely can't do that anyway.
FYI: You can change sample rate on the fly (e.g. without stopping
JACK) if you use JACK2 and switch-master.
When this happens clients will receive buffer-size and sample-rate
change callbacks.
_______________________________________________
Linux-audio-user mailing list
Linux-audio-user(a)lists.linuxaudio.org
http://lists.linuxaudio.org/listinfo/linux-audio-user
8:57 p.m.
New subject: Session management with NSM
On Wed, Sep 3, 2014 at 12:04 AM, Nils <list(a)nilsgey.de> wrote:
So the problem here, as I see it, is that Jack itself
is not an NSM aware
client.
My perception of NSM always was that it is not strictly bound to jack but
jack is another client. If jack would be a NSM client which supports switch
and saves it settings in the session folder you can save the samplerate
(and the connections, without a special program).
On the other hand that binds a session to specific jack settings again,
which is bad. Are there any examples of NSM clients that deal with
system-specific settings?
The problem is also in thinking of JACK as something *inside* a session. I
don't think of it that way. Nor do I consider Xorg to be inside the
session. JACK is external infrastrucutre.
Having an NSM client that just persists JACK's buffer size and sample rate
settings is certainly doable and anyone is welcome to write one--it would
indeed be trivial. IMHO it would create more problems than it would solve
though. For one thing, you'd have to make sure all the software you use can
handle those changes at runtime.
Barring that, NSM would need to have some degraded session mode where
everything is killed/restarted upon switching and clients are restarted
one-after-the-other in some defined sequence instead of in parallel (to
ensure that the jack settings client does its work before any other clients
are started). But, again, this is very regressive, and for what? To support
one very strange workflow that is already supported just fine by dealing
with it 'manually'.
(when I go from recording to mixing I usually change the JACK buffer
size... is NSM supposed to do this for me automatically? I don't see how or
why it would).
To me this is a non-issue. Same kind of stuff that comes up every time
anything is discussed on LAD or LAU... People bring up all these supposedly
show-stopping scenarios that in reality either doen't come up or don't
matter.
My oppinon is: it's not a problem until it's a problem. Let's concentrate
on the real issues and leave the imaginary ones alone.
Nils
On 03.09.2014 05:49, Filipe Coelho wrote:
On 09/02/2014 11:57 PM, Philipp Überbacher
wrote:
_______________________________________________
Linux-audio-user mailing list
Linux-audio-user(a)lists.linuxaudio.org
http://lists.linuxaudio.org/listinfo/linux-audio-user
I did not know that nsm supports live switching
of sessions without
restarting clients, but in case you need to change the jack sample rate
you most likely can't do that anyway.
FYI: You can change sample rate on the fly (e.g. without stopping JACK)
if you use JACK2 and switch-master.
When this happens clients will receive buffer-size and sample-rate change
callbacks.
_______________________________________________
Linux-audio-user mailing list
Linux-audio-user(a)lists.linuxaudio.org
http://lists.linuxaudio.org/listinfo/linux-audio-user
9:27 p.m.
New subject: Session management with NSM
On Wed, Sep 3, 2014 at 7:57 PM, J. Liles <malnourite(a)gmail.com> wrote:
workflow that is already supported just fine by
dealing
with it 'manually'.
Yes, manually setting JACK before starting a session is
the only and best
solution that scales. As you mentioned, transporting a session to another
machine would mean JACK's settings get borked: therefor this is *not*
something NSM should worry about, or implement.
To me this is a non-issue.
Pun intended? ;)
My oppinon is: it's not a problem until it's a
problem.
I'll agree: but I have to say from a users POV, I first misunderstood the
complexity and the use-cases, that would suggest having JACK settings
for each session would be useful.
Let's concentrate on the real issues and leave the
imaginary ones alone.
Yes: what will we prioritize? I think the .desktop feature to
discover NSM
capable apps is a very important one: removing the need for users to know
the binary's name for programs is essential for good workflow.
Pro-active: I've created a feature-request ticket on the NSM repo to
discuss details of .desktop files and integration:
https://github.com/original-male/non/issues/136
To a good outcome! -Harry
www.openavproductions.com
11:08 p.m.
New subject: Session management with NSM
On Wed, 3 Sep 2014 20:27:11 +0100
Harry van Haaren <harryhaaren(a)gmail.com> wrote:
On Wed, Sep 3, 2014 at 7:57 PM, J. Liles
<malnourite(a)gmail.com> wrote:
I completely disagree. Moving the session from one machine to another
may be one use case, but a rather special one. At least it's not
something I would do.
On the other hand, remembering which jack settings are required for
which session is something that NSM should remember for me.
And given that I proposed the jackstart client as an optional client,
something you can use or not use, same as jackconnect, your argument
falls flat on its face since you could just not use the jackstart
client and still handle jack manually.
You would also not need to start all clients in a pre-defined order,
you'd just need to make sure that jackstart starts before all others.
And be honest about one point: How many clients manage to 'live
switch'? I guess that most don't. Even if they do, what's the cost? A
few seconds at session switch time at most, which is completely
negligible IMHO. I know that for you this is a feature that is
important because other session management systems don't do it, but I
seriously doubt that it matters for any other reason.
Regards,
Philipp
workflow that is already supported just fine by
dealing
with it 'manually'.
Yes, manually setting JACK before starting a session
is the only and
best solution that scales. As you mentioned, transporting a session
to another machine would mean JACK's settings get borked: therefor
this is *not* something NSM should worry about, or implement. 
11:28 p.m.
New subject: [Bulk] Re: Session management with NSM
On Wed, 2014-09-03 at 23:08 +0200, Philipp Überbacher wrote:
I completely disagree. Moving the session from one
machine to another
may be one use case, but a rather special one. At least it's not
something I would do.
On the other hand, remembering which jack settings are required for
which session is something that NSM should remember for me.
Why? Because your hardware is limited? Or for the reason I mentioned,
that applications, at least older versions of Qtractor had no or a at
least an un-perfect latency compensation?
That's one issue caused by session managers and one reason I use
scripts.
11:33 p.m.
New subject: Session management with NSM
On Wed, 2014-09-03 at 23:28 +0200, Ralf Mardorf wrote:
On Wed, 2014-09-03 at 23:08 +0200, Philipp Überbacher
wrote:
PS: Another sound card, other IOs, is another issue :D.
I completely disagree. Moving the session from
one machine to another
may be one use case, but a rather special one. At least it's not
something I would do.
On the other hand, remembering which jack settings are required for
which session is something that NSM should remember for me.
Why? Because your hardware is limited? Or for the reason I mentioned,
that applications, at least older versions of Qtractor had no or a at
least an un-perfect latency compensation?
That's one issue caused by session managers and one reason I use
scripts.
4 Sep
4 Sep
2:27 a.m.
New subject: Session management with NSM
On Wed, Sep 3, 2014 at 2:08 PM, Philipp Überbacher <murks(a)tuxfamily.org>
wrote:
On Wed, 3 Sep 2014 20:27:11 +0100
Harry van Haaren <harryhaaren(a)gmail.com> wrote:
The complexity isn't much less if it's only one client. And then NSM needs
to know to treat that client specially...
On Wed, Sep 3, 2014 at 7:57 PM, J. Liles
<malnourite(a)gmail.com> wrote:
I completely disagree. Moving the session from one machine to another
may be one use case, but a rather special one. At least it's not
something I would do.
On the other hand, remembering which jack settings are required for
which session is something that NSM should remember for me.
And given that I proposed the jackstart client as an optional client,
something you can use or not use, same as jackconnect, your argument
falls flat on its face since you could just not use the jackstart
client and still handle jack manually.
You would also not need to start all clients in a pre-defined order,
you'd just need to make sure that jackstart starts before all others.
workflow that is already supported just fine by
dealing
with it 'manually'.
Yes, manually setting JACK before starting a session
is the only and
best solution that scales. As you mentioned, transporting a session
to another machine would mean JACK's settings get borked: therefor
this is *not* something NSM should worry about, or implement.
And be honest about one point: How many clients manage to 'live
switch'? I guess that most don't. Even if they do, what's the cost? A
few seconds at session switch time at most, which is completely
negligible IMHO. I know that for you this is a feature that is
important because other session management systems don't do it, but I
seriously doubt that it matters for any other reason.
You can lead a horse to water...
People said the same thing about kernel suspend to RAM/disk. Yes, it took a
while to get everything working and there are still some drivers that don't
cooperate, but once you've seen the light you won't want to go back to
rebooting ever again. Seems like the dark ages now.
Regards,
Philipp
_______________________________________________
Linux-audio-user mailing list
Linux-audio-user(a)lists.linuxaudio.org
http://lists.linuxaudio.org/listinfo/linux-audio-user
10:50 a.m.
New subject: Session management with NSM
On Wed, 3 Sep 2014 17:27:11 -0700
"J. Liles" <malnourite(a)gmail.com> wrote:
Ad hominem.
On Wed, Sep 3, 2014 at 2:08 PM, Philipp Überbacher
<murks(a)tuxfamily.org> wrote:
That part was clear pretty much from the start, as you can see from the
discussion between Harry and me.
On Wed, 3 Sep 2014 20:27:11 +0100
Harry van Haaren <harryhaaren(a)gmail.com> wrote:
The complexity isn't much less if it's only one client. And then NSM
needs to know to treat that client specially... On Wed, Sep 3, 2014 at 7:57 PM, J. Liles
<malnourite(a)gmail.com>
wrote:
I completely disagree. Moving the session from one machine to
another may be one use case, but a rather special one. At least
it's not something I would do.
On the other hand, remembering which jack settings are required for
which session is something that NSM should remember for me.
And given that I proposed the jackstart client as an optional
client, something you can use or not use, same as jackconnect, your
argument falls flat on its face since you could just not use the
jackstart client and still handle jack manually.
You would also not need to start all clients in a pre-defined order,
you'd just need to make sure that jackstart starts before all
others.
workflow that is already supported just fine by
dealing
with it 'manually'.
Yes, manually setting JACK before starting a session
is the only
and best solution that scales. As you mentioned, transporting a
session to another machine would mean JACK's settings get borked:
therefor this is *not* something NSM should worry about, or
implement. And be honest
about one point: How many clients manage to 'live
switch'? I guess that most don't. Even if they do, what's the cost?
A few seconds at session switch time at most, which is completely
negligible IMHO. I know that for you this is a feature that is
important because other session management systems don't do it, but
I seriously doubt that it matters for any other reason.
You can lead a horse to water... People said the same thing about kernel suspend to
RAM/disk. Yes, it
took a while to get everything working and there are still some
drivers that don't cooperate, but once you've seen the light you
won't want to go back to rebooting ever again. Seems like the dark
ages now.
You can keep this red herring.
I've made my suggestions with the goal to improve the user experience of
nsm, take the or leave them.
Regards,
Philipp
11:34 a.m.
New subject: Session management with NSM
Taking this thread back to its topic: please use new topics for
discussion of OT.
On Thu, Sep 4, 2014 at 9:50 AM, Philipp Überbacher <murks(a)tuxfamily.org> wrote:
I've made my suggestions with the goal to improve
the user experience of
nsm, take the or leave them.
Thanks for the feedback; as a dev promoting NSM, we
need more user input as
to use cases and workflow issues. You've been helpful, and I value your input.
I've created a feature-request for an "official" NSM .desktop file,
that programs
can announce thier NSM capability.
I'd like feedback, and if the this seems a good proposal, lets give this a green
light, and start adding the functionality to .desktop files and NSM.
https://github.com/original-male/non/issues/136
Cheers, -Harry
www.openavproductions.com
1:51 p.m.
New subject: Session management with NSM
On Thu, Sep 04, 2014 at 10:50:14AM +0200, Philipp Überbacher wrote:
On Wed, 3 Sep 2014 17:27:11 -0700
"J. Liles" <malnourite(a)gmail.com> wrote:
Sorry to butt in here, but JFTR, that is *NOT* an Ad hominem
argument/attack.
--
"If you're not careful, the newspapers will have you hating the people
who are being oppressed, and loving the people who are doing the
oppressing." --- Malcolm X
You can lead a horse to water...
Ad hominem. 
3 Sep
3 Sep
9:44 p.m.
New subject: Session management with NSM
On Wed, Sep 03, 2014 at 11:57:05AM -0700, J. Liles wrote:
The problem is also in thinking of JACK as something
*inside* a session. I
don't think of it that way. Nor do I consider Xorg to be inside the
session. JACK is external infrastrucutre.
I agree 100% with that. And not only Jack, even some apps may be
considered infrastructure instead of being particular to a session.
RE switching sample rates, I really wonder what's the point. If
you switch between 48 and 96 kHz that will in most cases have some
inpact on your HW as well: ADAT or MADI channels for example. So
that will require manual intervention anyway, no session manager
can do that for you.
There is not point in switching between 48 adn 44.1 kHz, just use
48 kHz all the time. Even if you record a CD. And how many Linux
Audio users are recording CDs anyway. Many sound cards are designed
for optimal performance at 48 kHz, with 44.1 being some compromise.
RE switching buffer sizes, if your system works reliably with some
size, there is no reason to use a larger one.
To me this is a non-issue. Same kind of stuff that
comes up every time
anything is discussed on LAD or LAU... People bring up all these supposedly
show-stopping scenarios that in reality either doen't come up or don't
matter.
NSM is IMHO the only decent session manager because it *doesn't* try
to do things it shouldn't, and does those that it should do the right
way. I'd love to see *some* changes to it, but certainly not the ones
discussed in this thread.
Ciao,
--
FA
A world of exhaustive, reliable metadata would be an utopia.
It's also a pipe-dream, founded on self-delusion, nerd hubris
and hysterically inflated market opportunities. (Cory Doctorow)
10:32 p.m.
New subject: Session management with NSM
On Wed, Sep 03, 2014 at 11:57:05AM -0700, J. Liles
wrote:
> Nor do I consider Xorg to be inside the session.
I use scripts to store and restore my sessions. Perhaps X is
unimportant, but some folks perhaps want that some apps open on another
workspace/virtual desktop than other apps do. I even don't care about
this, but IMO session managers can't provide what a user's script could
provide. For example, jackd settings are very important, assumed you use
an app as Qtractor. Qtractor does move audio recordings as good as it
can (not really perfect) depending to the jackd latency, assumed you
should change the latency, then your audio tracks and MIDI tracks would
be out of sync.
The problem is also in thinking of JACK as something
*inside* a
session.
IOW an app as Qtractor with a "strange" latency compensation is unusable
in combination with a session manager that doesn't care about jackd?
Btw. I just read one mail, not the whole thread, but I'm very amused
about this unworldly point of view.
"NSM (Non session management) support." -
http://qtractor.sourceforge.net/qtractor-index.html
:D
Am I missing something?
10:38 p.m.
New subject: Session management with NSM
On Wed, Sep 03, 2014 at 10:32:25PM +0200, Ralf Mardorf wrote:
I use scripts to store and restore my sessions.
Perhaps X is
unimportant, but some folks perhaps want that some apps open on another
workspace/virtual desktop than other apps do. I even don't care about
this, but IMO session managers can't provide what a user's script could
provide. For example, jackd settings are very important, assumed you use
an app as Qtractor. Qtractor does move audio recordings as good as it
can (not really perfect) depending to the jackd latency, assumed you
should change the latency, then your audio tracks and MIDI tracks would
be out of sync.
Which, if true, would only mean that Qtractor does its latency
compensation the wrong way. Note the 'if true'.
Ciao,
--
FA
A world of exhaustive, reliable metadata would be an utopia.
It's also a pipe-dream, founded on self-delusion, nerd hubris
and hysterically inflated market opportunities. (Cory Doctorow)
10:43 p.m.
New subject: Session management with NSM
On Wed, 2014-09-03 at 20:38 +0000, Fons Adriaensen wrote:
On Wed, Sep 03, 2014 at 10:32:25PM +0200, Ralf Mardorf
wrote:
For the versions of Qtractor I used it is true. An issue for me, because
I like to be able to use different latencies, at different work stages.
I'm aware that Ardour's latency compensation is smarter. But IMO it's
important, that Linux users who prefer session managers, at least get
informed about such issues, what ever applications they use.
I use scripts to store and restore my sessions.
Perhaps X is
unimportant, but some folks perhaps want that some apps open on another
workspace/virtual desktop than other apps do. I even don't care about
this, but IMO session managers can't provide what a user's script could
provide. For example, jackd settings are very important, assumed you use
an app as Qtractor. Qtractor does move audio recordings as good as it
can (not really perfect) depending to the jackd latency, assumed you
should change the latency, then your audio tracks and MIDI tracks would
be out of sync.
Which, if true, would only mean that Qtractor does its latency
compensation the wrong way. Note the 'if true'.
11:06 p.m.
New subject: Session management with NSM
On Wed, Sep 03, 2014 at 10:43:35PM +0200, Ralf Mardorf wrote:
On Wed, 2014-09-03 at 20:38 +0000, Fons Adriaensen
wrote:
There's nothing smart about it, it's not rocket science.
If Li and Lo are the current input and output latencies, then
* When recording a track, adjust the logical postion (the start offset
relative to whatever the session uses as reference) of the data by Li.
* When playing a track, adjust its logical position by Lo.
This will do the right thing, even when period sizes etc. change.
And a session manager should not try to compensate for design errors
in applications. Once you start to do that, there is no end to the
amount of misery you will cause.
Ciao,
--
FA
A world of exhaustive, reliable metadata would be an utopia.
It's also a pipe-dream, founded on self-delusion, nerd hubris
and hysterically inflated market opportunities. (Cory Doctorow)
Which, if true, would only mean that Qtractor
does its latency
compensation the wrong way. Note the 'if true'.
For the versions of Qtractor I used it is true. An issue for me, because
I like to be able to use different latencies, at different work stages.
I'm aware that Ardour's latency compensation is smarter. But IMO it's
important, that Linux users who prefer session managers, at least get
informed about such issues, what ever applications they use.
11:17 p.m.
New subject: Session management with NSM
On Wed, 2014-09-03 at 21:06 +0000, Fons Adriaensen wrote:
On Wed, Sep 03, 2014 at 10:43:35PM +0200, Ralf Mardorf
wrote:
Rui likely should know more about Qtractor's current abilities, than I
do.
OT: Jimi Hendrix's post death release of The Cry of Love IMO used much
un-synced tape affects and I bet a lot of amateur audio engineers
nowadays use the pan pot to emulate funny phasing panning effects.
I suspect nowadays sync anyway is out of stile. At least lip-sync died
out.
On Wed, 2014-09-03 at 20:38 +0000, Fons
Adriaensen wrote:
There's nothing smart about it, it's not rocket science.
If Li and Lo are the current input and output latencies, then
* When recording a track, adjust the logical postion (the start offset
relative to whatever the session uses as reference) of the data by Li.
* When playing a track, adjust its logical position by Lo.
This will do the right thing, even when period sizes etc. change.
And a session manager should not try to compensate for design errors
in applications. Once you start to do that, there is no end to the
amount of misery you will cause.
Ciao, Which, if true, would only mean that Qtractor
does its latency
compensation the wrong way. Note the 'if true'.
For the versions of Qtractor I used it is true. An issue for me, because
I like to be able to use different latencies, at different work stages.
I'm aware that Ardour's latency compensation is smarter. But IMO it's
important, that Linux users who prefer session managers, at least get
informed about such issues, what ever applications they use. 
4 Sep
4 Sep
12:15 a.m.
New subject: Session management with NSM
On 09/03/2014 10:17 PM, Ralf Mardorf wrote:
On Wed, 2014-09-03 at 21:06 +0000, Fons Adriaensen
wrote:
qtractor does try to adjust the so called logical position or start
offset by Li as Fons explained; the Li (input latency) value is the one
given by jack_port_get_latency_range() at the time capture/recording
takes place; the actual offset is however quantized/rounded to MIDI
resolution (in ticks per quarter-note or beat)--this fact alone might
add to its "strangeness" i guess.
cheers
--
rncbc aka Rui Nuno Capela
rncbc(a)rncbc.org
On Wed, Sep 03, 2014 at 10:43:35PM +0200, Ralf
Mardorf wrote:
Rui likely should know more about Qtractor's current abilities, than I
do.
On Wed, 2014-09-03 at 20:38 +0000, Fons
Adriaensen wrote:
There's nothing smart about it, it's not rocket science.
If Li and Lo are the current input and output latencies, then
* When recording a track, adjust the logical postion (the start offset
relative to whatever the session uses as reference) of the data by Li.
* When playing a track, adjust its logical position by Lo.
This will do the right thing, even when period sizes etc. change.
And a session manager should not try to compensate for design errors
in applications. Once you start to do that, there is no end to the
amount of misery you will cause.
Ciao, Which, if true, would only mean that Qtractor
does its latency
compensation the wrong way. Note the 'if true'.
For the versions of Qtractor I used it is true. An issue for me, because
I like to be able to use different latencies, at different work stages.
I'm aware that Ardour's latency compensation is smarter. But IMO it's
important, that Linux users who prefer session managers, at least get
informed about such issues, what ever applications they use.
12:19 a.m.
New subject: Session management with NSM
On Wed, Sep 03, 2014 at 11:15:25PM +0100, Rui Nuno Capela wrote:
qtractor does try to adjust the so called logical
position or start
offset by Li as Fons explained; the Li (input latency) value is the
one given by jack_port_get_latency_range() at the time
capture/recording takes place; the actual offset is however
quantized/rounded to MIDI resolution (in ticks per quarter-note or
beat)--this fact alone might add to its "strangeness" i guess.
Why do that ? There's really no reason for it.
Ciao,
--
FA
A world of exhaustive, reliable metadata would be an utopia.
It's also a pipe-dream, founded on self-delusion, nerd hubris
and hysterically inflated market opportunities. (Cory Doctorow)
9:27 a.m.
New subject: Session management with NSM
On Wed, 2014-09-03 at 22:19 +0000, Fons Adriaensen wrote:
On Wed, Sep 03, 2014 at 11:15:25PM +0100, Rui Nuno
Capela wrote:
Qtractor has got two weak points, audio tracks and the mixer, regarding
to MIDI usability it IMO is the most satisfying Linux FLOSS sequencer.
The sequencer has it's weak points too, „Form follows function“, e.g. I
don't want to use mixer automation to mute and un-mute MIDI clips.
qtractor does try to adjust the so called logical
position or start
offset by Li as Fons explained; the Li (input latency) value is the
one given by jack_port_get_latency_range() at the time
capture/recording takes place; the actual offset is however
quantized/rounded to MIDI resolution (in ticks per quarter-note or
beat)--this fact alone might add to its "strangeness" i guess.
Why do that ? There's really no reason for it.
9:38 a.m.
New subject: Session management with NSM
Rui:
this fact alone might add to its
"strangeness" i guess
Yes, that is strange, I don't care about NSM, but I care about the vague
sync I get even if I stay with a jackd latency setting. Rounding is not
ok and btw. I want to be able to change the jackd latency without moving
clips. That the position of audio tracks is rounded to the MIDI
resolution, even if I move them manually is another issue.
4:37 p.m.
New subject: Session management with NSM
On 2014-09-04 08:38, Ralf Mardorf wrote:
Rui:
as said, automatic latency compensation in qtractors audio recording is
a one-time settlement--it gets settled at the time you take the
recording. nevermore it gets auto-adjusted later on, ie. the take offset
value, as read from jack_port_get_latency*(), won't ever change
thereafter. that means you're in charge to tweak it later if you please,
by summoning the clip properties dialog and changing the offset value as
you wish.
rest assured that, in qtractor sequencer model, ever since its
inception, all time locations do honor the midi/music metric scale
resolution. that has been kind of an argument why i always posed
qtractor as *not a DAW* but rather a *sequencer with (some) DAW
features* ;)
cheers
--
rncbc aka. Rui Nuno Capela
this fact alone might add to its
"strangeness" i guess
Yes, that is strange, I don't care about NSM, but I care about the
vague
sync I get even if I stay with a jackd latency setting. Rounding is not
ok and btw. I want to be able to change the jackd latency without
moving
clips. That the position of audio tracks is rounded to the MIDI
resolution, even if I move them manually is another issue.
4:49 p.m.
New subject: Session management with NSM
Hi Rui :)
On Thu, 2014-09-04 at 15:34 +0100, Rui Nuno Capela wrote:
as said, automatic latency compensation in qtractors
audio recording is
a one-time settlement--it gets settled at the time you take the
recording. nevermore it gets auto-adjusted later on, ie. the take offset
value, as read from jack_port_get_latency*(), won't ever change
thereafter. that means you're in charge to tweak it later if you please,
by summoning the clip properties dialog and changing the offset value as
you wish.
IIUC NSM doesn't care about the jackd settings. When Qtractor also
ignores the settings, expects that they are the same as when an audio
track was recorded, then Qtractor _does not_ support NSM session
management. I start my sessions by scripts and don't use a session
manager and it seems that my decision to do so is good.
rest assured that, in qtractor sequencer model, ever
since its
inception, all time locations do honor the midi/music metric scale
resolution. that has been kind of an argument why i always posed
qtractor as *not a DAW* but rather a *sequencer with (some) DAW
features* ;)
Fair enough, so next time I'll increase the MIDI resolution, to be able
to fix sync issues with audio tacks, while for MIDI I don't need a
higher resolution.
Regards,
Ralf
5:04 p.m.
New subject: Session management with NSM
Am 04.09.2014 16:49, schrieb Ralf Mardorf:
Hi Rui :)
On Thu, 2014-09-04 at 15:34 +0100, Rui Nuno Capela wrote:
Your conclusions here are wrong. NSM didn't forward any jackd settings
to the clients. So, how a client behave regarding the latency setting in
jackd, have nothing to do with, if it support NSM or not.
Also, your use of scripts didn't change that, so it isn't good or bad,
it's simply just the way YOU do it.
as said, automatic latency compensation in
qtractors audio recording is
a one-time settlement--it gets settled at the time you take the
recording. nevermore it gets auto-adjusted later on, ie. the take offset
value, as read from jack_port_get_latency*(), won't ever change
thereafter. that means you're in charge to tweak it later if you please,
by summoning the clip properties dialog and changing the offset value as
you wish.
IIUC NSM doesn't care about the jackd settings. When Qtractor also
ignores the settings, expects that they are the same as when an audio
track was recorded, then Qtractor _does not_ support NSM session
management. I start my sessions by scripts and don't use a session
manager and it seems that my decision to do so is good.
______________________________
7:23 p.m.
New subject: Session management with NSM
On Thu, 2014-09-04 at 17:03 +0200, hermann meyer wrote:
Am 04.09.2014 16:49, schrieb Ralf Mardorf:
The scripts start all apps, do all connections and at first jackd is
started always using the same latency, so the sync of audio and MIDI
tracks for Qtractor can't differ. NSM cares about this too?
Hi Rui :)
On Thu, 2014-09-04 at 15:34 +0100, Rui Nuno Capela wrote:
Your conclusions here are wrong. NSM didn't forward any jackd settings
to the clients. So, how a client behave regarding the latency setting in
jackd, have nothing to do with, if it support NSM or not.
Also, your use of scripts didn't change that, so it isn't good or bad,
it's simply just the way YOU do it. as said, automatic latency compensation in
qtractors audio recording is
a one-time settlement--it gets settled at the time you take the
recording. nevermore it gets auto-adjusted later on, ie. the take offset
value, as read from jack_port_get_latency*(), won't ever change
thereafter. that means you're in charge to tweak it later if you please,
by summoning the clip properties dialog and changing the offset value as
you wish.
IIUC NSM doesn't care about the jackd settings. When Qtractor also
ignores the settings, expects that they are the same as when an audio
track was recorded, then Qtractor _does not_ support NSM session
management. I start my sessions by scripts and don't use a session
manager and it seems that my decision to do so is good.
______________________________
5 Sep
5 Sep
5:28 a.m.
New subject: Session management with NSM
Am 04.09.2014 19:23, schrieb Ralf Mardorf:
On Thu, 2014-09-04 at 17:03 +0200, hermann meyer
wrote:
And your script is written by rassg? "Ralfs auto session script
generator", or did it depend on your human interaction with your keyboard?
And later on, when your session is grown to a state were you are forced
to use a higher latency, because you reach the limit of your hardware,
it do all the magic to sync the tracks inside qtractor to the desired
settings? And your script is also able to archive/restore a session over
the network, were more then one host is involved, even again with
syncing all the jack settings?
Wow, great. I remember the day's were I use scripts as well, but, I must
say I wasn't able to archive all that. Maybe you are so kind to release
your "rassg" tool?
regards
hermann
Am 04.09.2014 16:49, schrieb Ralf Mardorf:
The scripts start all apps, do all
connections and at first jackd is
started always using the same latency, so the sync of audio and MIDI
tracks for Qtractor can't differ. NSM cares about this too?
Hi Rui :)
On Thu, 2014-09-04 at 15:34 +0100, Rui Nuno Capela wrote:
Your conclusions here are wrong. NSM didn't
forward any jackd settings
to the clients. So, how a client behave regarding the latency setting in
jackd, have nothing to do with, if it support NSM or not.
Also, your use of scripts didn't change that, so it isn't good or bad,
it's simply just the way YOU do it. as said, automatic latency compensation in
qtractors audio recording is
a one-time settlement--it gets settled at the time you take the
recording. nevermore it gets auto-adjusted later on, ie. the take offset
value, as read from jack_port_get_latency*(), won't ever change
thereafter. that means you're in charge to tweak it later if you please,
by summoning the clip properties dialog and changing the offset value as
you wish.
IIUC NSM doesn't care about the jackd settings. When Qtractor also
ignores the settings, expects that they are the same as when an audio
track was recorded, then Qtractor _does not_ support NSM session
management. I start my sessions by scripts and don't use a session
manager and it seems that my decision to do so is good.
______________________________ 
4 Sep
4 Sep
7:25 p.m.
New subject: Session management with NSM
On 04/09/14 20:34, Ralf Mardorf wrote:
IIUC NSM doesn't care about the jackd settings.
When Qtractor also
ignores the settings, expects that they are the same as when an audio
track was recorded, then Qtractor _does not_ support NSM session
management. I start my sessions by scripts and don't use a session
manager and it seems that my decision to do so is good.
Do you honestly not see how much of a fallacy that statement is? If not
please mull it over for a moment, I'm sure it will come to you how two
programs, both not controlling/listening to a third programs settings
has absolutely nothing to do with their functioning together!
Dale.
7:34 p.m.
New subject: [Bulk] Re: Session management with NSM
On Thu, 2014-09-04 at 23:09 +0545, Kazakore wrote:
On 04/09/14 20:34, Ralf Mardorf wrote:
If jackd is started with settings that cause another latency, than the
latency that was used, when an audio recording was done with Qtractor,
then audio and MIDI tracks get out of sync. So jackd has to be started
with the same latency. If the session manager shouldn't start jackd, the
latency settings could be incorrect.
IIUC NSM doesn't care about the jackd
settings. When Qtractor also
ignores the settings, expects that they are the same as when an audio
track was recorded, then Qtractor _does not_ support NSM session
management. I start my sessions by scripts and don't use a session
manager and it seems that my decision to do so is good.
Do you honestly not see how much of a fallacy that statement is? If not
please mull it over for a moment, I'm sure it will come to you how two
programs, both not controlling/listening to a third programs settings
has absolutely nothing to do with their functioning together!
Dale.
7:40 p.m.
New subject: [Bulk] Re: Session management with NSM
On 04/09/14 23:18, Ralf Mardorf wrote:
On Thu, 2014-09-04 at 23:09 +0545, Kazakore wrote:
And that has WHAT to do with NSM support?
On 04/09/14 20:34, Ralf Mardorf wrote:
If jackd is started with settings that cause another latency, than the
latency that was used, when an audio recording was done with Qtractor,
then audio and MIDI tracks get out of sync. So jackd has to be started
with the same latency. If the session manager shouldn't start jackd, the
latency settings could be incorrect.
_______________________________________________
IIUC NSM doesn't care about the jackd
settings. When Qtractor also
ignores the settings, expects that they are the same as when an audio
track was recorded, then Qtractor _does not_ support NSM session
management. I start my sessions by scripts and don't use a session
manager and it seems that my decision to do so is good.
Do you honestly not see
how much of a fallacy that statement is? If not
please mull it over for a moment, I'm sure it will come to you how two
programs, both not controlling/listening to a third programs settings
has absolutely nothing to do with their functioning together!
Dale.
7:48 p.m.
New subject: [Bulk] Re: Session management with NSM
On Thu, 2014-09-04 at 23:24 +0545, Kazakore wrote:
On 04/09/14 23:18, Ralf Mardorf wrote:
I start a script and my session is started as it is needed.
$ ./start-script-song-foo
jackd is started with the latency that is needed to get Qtractor's audio
and MIDI tracks in sync.
Assumed a session manager, e.g. NSM shouldn't restore the jackd latency,
then the session isn't restored. If tracks aren't in sync, it's not a
restored session.
A simple question, is it possible to restore a Qtractor session using
NSM, IOW is it guaranteed that jackd doesn't run with a wrong latency?
On Thu, 2014-09-04 at 23:09 +0545, Kazakore
wrote:
And that has WHAT to do with NSM support? On 04/09/14 20:34, Ralf Mardorf wrote:
If jackd is started with settings that cause another latency, than the
latency that was used, when an audio recording was done with Qtractor,
then audio and MIDI tracks get out of sync. So jackd has to be started
with the same latency. If the session manager shouldn't start jackd, the
latency settings could be incorrect.
_______________________________________________
IIUC NSM doesn't care about the jackd
settings. When Qtractor also
ignores the settings, expects that they are the same as when an audio
track was recorded, then Qtractor _does not_ support NSM session
management. I start my sessions by scripts and don't use a session
manager and it seems that my decision to do so is good.
Do you honestly not see
how much of a fallacy that statement is? If not
please mull it over for a moment, I'm sure it will come to you how two
programs, both not controlling/listening to a third programs settings
has absolutely nothing to do with their functioning together!
Dale.
7:53 p.m.
New subject: [Bulk] Re: Session management with NSM
On Thu, Sep 04, 2014 at 07:48:30PM +0200, Ralf Mardorf wrote:
A simple question, is it possible to restore a
Qtractor session using
NSM, IOW is it guaranteed that jackd doesn't run with a wrong latency?
That is irrelevant.
If a recorder/player, sequencer, DAW, or whatever is doing its
latency compensation as it should be done (which is probably
simpler than whatever Qtractor is doing now), it DOES NOT MATTER
if the latency values are the same or not.
Please try to understand that, and stop whining.
Ciao,
--
FA
A world of exhaustive, reliable metadata would be an utopia.
It's also a pipe-dream, founded on self-delusion, nerd hubris
and hysterically inflated market opportunities. (Cory Doctorow)
8:05 p.m.
New subject: Session management with NSM
On Thu, 2014-09-04 at 17:53 +0000, Fons Adriaensen wrote:
On Thu, Sep 04, 2014 at 07:48:30PM +0200, Ralf Mardorf
wrote:
Again, this isn't my point. I don't care about it, I'm not whining. My
sessions are restored in another way. My intention is to point out, that
a user can not simply use every application that claims to support NSM
and expect to restore the session. At least users should add a note, in
Qtractor's > File > Properties ... > Description, that jackd has to be
started with x latency.
That's all!
A simple question, is it possible to restore a
Qtractor session using
NSM, IOW is it guaranteed that jackd doesn't run with a wrong latency?
That is irrelevant.
If a recorder/player, sequencer, DAW, or whatever is doing its
latency compensation as it should be done (which is probably
simpler than whatever Qtractor is doing now), it DOES NOT MATTER
if the latency values are the same or not.
Please try to understand that, and stop whining.
8:05 p.m.
New subject: [Bulk] Re: Session management with NSM
On 04/09/14 23:38, Fons Adriaensen wrote:
On Thu, Sep 04, 2014 at 07:48:30PM +0200, Ralf Mardorf
wrote:
From this brief discussion here it sounds possible that QTractor takes
account of LIn on recording but never the LOut on playback, like it
should do. This could quite accurately be described as a bug in QTractor
but never a reason to say it is not compatible/supported by NSM!
Especially when the setting you are complaining about NSM not
controlling isn't part of QTractor itself but another program entirely
(Jack) which isn't supported in that way.
Of course I could be wrong about the LOut, only going on what I've read
in this here thread...
A simple question, is it possible to restore a
Qtractor session using
NSM, IOW is it guaranteed that jackd doesn't run with a wrong latency?
That is
irrelevant.
If a recorder/player, sequencer, DAW, or whatever is doing its
latency compensation as it should be done (which is probably
simpler than whatever Qtractor is doing now), it DOES NOT MATTER
if the latency values are the same or not.
Please try to understand that, and stop whining.
Ciao,
7:42 p.m.
New subject: [Bulk] Re: Session management with NSM
On Thu, Sep 04, 2014 at 07:33:58PM +0200, Ralf Mardorf wrote:
If jackd is started with settings that cause another
latency, than the
latency that was used, when an audio recording was done with Qtractor,
then audio and MIDI tracks get out of sync. So jackd has to be started
with the same latency. If the session manager shouldn't start jackd, the
latency settings could be incorrect.
And that is a design error in Qtractor and has *nothing* to do with NSM.
If latency compensation is implemented correctly (which is easy) there
no need to remember any latency values in the session file. Which implies
that a change of latency doesn't matter, see also my previous post.
So please stop whining about this.
Ciao,
--
FA
A world of exhaustive, reliable metadata would be an utopia.
It's also a pipe-dream, founded on self-delusion, nerd hubris
and hysterically inflated market opportunities. (Cory Doctorow)
7:57 p.m.
New subject: Session management with NSM
On Thu, 2014-09-04 at 17:42 +0000, Fons Adriaensen wrote:
On Thu, Sep 04, 2014 at 07:33:58PM +0200, Ralf Mardorf
wrote:
You got me wrong! I only pointed out that "NSM (Non session management)
support." - http://qtractor.sourceforge.net/qtractor-index.html Could
cause issues, for those who understand it word by word. And who aren't
aware that "An Audio/MIDI multi-track sequencer" -
http://qtractor.sourceforge.net/qtractor-index.html has to be understand
word by word. Audio tracks are just a bonus that isn't part of the
complete concept.
I never claimed that NSM is bad, I just pointed out that Qtractor offers
features that aren't restored, by this session manager. Users should be
warned! I don't need a warning, I'm using scripts! I don't lamment! I
just want to help, that users once will be upset, because they
misunderstood Qtractors NSM support.
Ok?
Regards,
Ralf
If jackd is started with settings that cause
another latency, than the
latency that was used, when an audio recording was done with Qtractor,
then audio and MIDI tracks get out of sync. So jackd has to be started
with the same latency. If the session manager shouldn't start jackd, the
latency settings could be incorrect.
And that is a design error in Qtractor and has *nothing* to do with NSM.
If latency compensation is implemented correctly (which is easy) there
no need to remember any latency values in the session file. Which implies
that a change of latency doesn't matter, see also my previous post.
So please stop whining about this.
7:58 p.m.
New subject: Session management with NSM
On Thu, 2014-09-04 at 19:57 +0200, Ralf Mardorf wrote:
On Thu, 2014-09-04 at 17:42 +0000, Fons Adriaensen
wrote:
^ not ;)
On Thu, Sep 04, 2014 at 07:33:58PM +0200, Ralf
Mardorf wrote:
You got me wrong! I only pointed out that "NSM (Non session management)
support." - http://qtractor.sourceforge.net/qtractor-index.html Could
cause issues, for those who understand it word by word. And who aren't
aware that "An Audio/MIDI multi-track sequencer" -
http://qtractor.sourceforge.net/qtractor-index.html has to be understand
word by word. Audio tracks are just a bonus that isn't part of the
complete concept.
I never claimed that NSM is bad, I just pointed out that Qtractor offers
features that aren't restored, by this session manager. Users should be
warned! I don't need a warning, I'm using scripts! I don't lamment! I
just want to help, that users once will be upset, because they If jackd is started with settings that cause
another latency, than the
latency that was used, when an audio recording was done with Qtractor,
then audio and MIDI tracks get out of sync. So jackd has to be started
with the same latency. If the session manager shouldn't start jackd, the
latency settings could be incorrect.
And that is a design error in Qtractor and has *nothing* to do with NSM.
If latency compensation is implemented correctly (which is easy) there
no need to remember any latency values in the session file. Which implies
that a change of latency doesn't matter, see also my previous post.
So please stop whining about this. misunderstood Qtractors NSM support.
Ok?
Regards,
Ralf
8:07 p.m.
New subject: Session management with NSM
On Thu, Sep 04, 2014 at 07:57:11PM +0200, Ralf Mardorf wrote:
I never claimed that NSM is bad, I just pointed out
that Qtractor offers
features that aren't restored,
Since when is making invalid assumptions (that latency will be the
same each time) 'offering a feature' ??
Ciao,
--
FA
A world of exhaustive, reliable metadata would be an utopia.
It's also a pipe-dream, founded on self-delusion, nerd hubris
and hysterically inflated market opportunities. (Cory Doctorow)
8:13 p.m.
New subject: Session management with NSM
On Thu, 2014-09-04 at 18:07 +0000, Fons Adriaensen wrote:
On Thu, Sep 04, 2014 at 07:57:11PM +0200, Ralf Mardorf
wrote:
Let's stop it ;).
Qtactor is a sequencer, not a DAW, but the feature is, that it provides
audio tracks, that are handled in a "strange" way.
_We_ are aware about it, somebody new to Linux audio usually isn't aware
about it. _So_ Rui should add a note on the Qtractor page with a
warning.
I never claimed that NSM is bad, I just pointed
out that Qtractor offers
features that aren't restored,
Since when is making invalid assumptions (that latency will be the
same each time) 'offering a feature' ??
8:19 p.m.
New subject: Session management with NSM
On 04/09/14 23:58, Ralf Mardorf wrote:
On Thu, 2014-09-04 at 18:07 +0000, Fons Adriaensen
wrote:
I'm actually quite shocked
you've been fully aware of this (for how
long!?) and bring it up here as non-supported by NSM rather than file it
as a bug report with QTractor!
Although it sounds Rui is well aware of the limitations and happy to
tell people to live with it as it's not designed to be a fully fledged
DAW. Still a bug report, where people can comment and possibly even a
patch be filed, would be far better than lamenting on a mailing list!
Anyway I really must go to sleep now! I thought I was about to turn off
the light around 2-3 hours ago! ;-)
On Thu, Sep 04, 2014 at 07:57:11PM +0200, Ralf
Mardorf wrote:
Let's stop it ;).
Qtactor is a sequencer, not a DAW, but the feature is, that it provides
audio tracks, that are handled in a "strange" way.
_We_ are aware about it, somebody new to Linux audio usually isn't aware
about it. _So_ Rui should add a note on the Qtractor page with a
warning.
_______________________________________________ I never claimed that NSM is bad, I just pointed
out that Qtractor offers
features that aren't restored,
Since when is making invalid assumptions (that
latency will be the
same each time) 'offering a feature' ??
8:34 p.m.
New subject: Session management with NSM
On Fri, 2014-09-05 at 00:03 +0545, Kazakore wrote:
Anyway I really must go to sleep now! I thought I was
about to turn off
the light around 2-3 hours ago! ;-)
That does excuse your rough tone of voice ;).
I'm aware about the latency issue for a very long time and I reported
the issue a very long time ago. Not in dependency with NSM. Qtactor in
the beginning had no latency compensation, the "in so many ways strange"
latency compensation was a step in the right direction ;), but it's far
away from being satisfying. When Rui want's to focus options that are
more important for him it's ok. I noticed the NSM ./. Qtractor thingy
now and I pointed it out. Again, I don't use or test session mangers,
I'm using scripts, with total contentment.
I noticed the NSM thread, but again, I'm a session script guy, I wasn't
lamenting, I just tried to point out an issue.
Sleep tight :). (not ironical, I'm serious)
Ralf
9:23 p.m.
New subject: Session management with NSM
This thread has officially been Ralf'd.
In conclusion:
1. Harry has created an enhancement request to use .desktop files to
generate a list of available NSM capable applications. This is something
I've had on my personal list for a while anyway--still haven't decided how
it should look in the GUI (tab completion is no help to noobs and pros
already know the client names). Maybe stand-alone launcher would be prudent.
2. Anyone who wants to create a client to persist jack settings is welcome
to do so, and this doesn't require any changes to NSM. However, it is
unlikely to work with sample rate changes. Lots of programs support runtime
bufsize changes though, if that's what you're into.
3. Session switch is awesome and the more clients which support it the
better.
4. When Ralf has problems, we all have problems.
/thread
9:41 p.m.
New subject: Session management with NSM
On 9/4/2014 3:22 PM, J. Liles wrote:
This thread has officially been Ralf'd.
that is funny.
2. Anyone who wants to create a client to persist jack
settings is
welcome to do so, and this doesn't require any changes to NSM. However,
it is unlikely to work with sample rate changes. Lots of programs
support runtime bufsize changes though, if that's what you're into.
I would love to take a stab at this. Seems like something within my
reach but if there is no option "start-before-others" or some priority
client loading, this seems pointless.
David
9:46 p.m.
New subject: Session management with NSM
On Thu, Sep 4, 2014 at 12:41 PM, David Santamauro <david.santamauro
@gmail.com> wrote:
On 9/4/2014 3:22 PM, J. Liles wrote:
As long as no clients crash or otherwise freak out when you change the
buffer size at runtime, then there's no need to enforce an order. The
synchronization is only required in order to shutdown/restart JACK (which
isn't necessary to change the buffer size)
This thread has officially been Ralf'd.
that is funny.
2. Anyone who wants to create a client to persist jack settings is
welcome to do so, and this doesn't require
any changes to NSM. However,
it is unlikely to work with sample rate changes. Lots of programs
support runtime bufsize changes though, if that's what you're into.
I would love to take a stab at this. Seems like something within my reach
but if there is no option "start-before-others" or some priority client
loading, this seems pointless.
9:58 p.m.
New subject: Session management with NSM
On 9/4/2014 3:46 PM, J. Liles wrote:
On Thu, Sep 4, 2014 at 12:41 PM, David Santamauro
<david.santamauro(a)gmail.com <mailto:david.santamauro@gmail.com>> wrote:
2. Anyone who wants to create a client to persist jack settings is
welcome to do so, and this doesn't require any changes to NSM.
However,
it is unlikely to work with sample rate changes. Lots of programs
support runtime bufsize changes though, if that's what you're into.
I would love to take a stab at this. Seems like something within my
reach but if there is no option "start-before-others" or some
priority client loading, this seems pointless.
As long as no clients crash or otherwise freak out when you change the
buffer size at runtime, then there's no need to enforce an order. The
synchronization is only required in order to shutdown/restart JACK
(which isn't necessary to change the buffer size)
So then the assumption is that this "client" would only allow settings
manipulation and not deal with starting/stopping jack at all. If so,
then is there an exhaustive list of settings that can actually be
changed without having to restart?
I can't imagine one could change the device, e.g. without restarting.
10:36 p.m.
New subject: Session management with NSM
On Thu, Sep 4, 2014 at 12:58 PM, David Santamauro <
david.santamauro(a)gmail.com> wrote:
On 9/4/2014 3:46 PM, J. Liles wrote:
Well, now we're getting back into all the reasons why JACK settings should
not be part of a session in the first place. For example, suppose that you
could change the device at runtime: Now you change sessions to one that
uses a different device--and nothing works, because the client can't reach
out into the physical world and plug your other interface into everything.
The list you're looking for is here:
http://jackaudio.org/files/docs/html/group__ServerControl.html
As you can see, setting the buffer size and enabling/disabling freewheeling
mode is basically the extent of it.
On Thu, Sep 4, 2014 at 12:41 PM, David Santamauro
<david.santamauro(a)gmail.com <mailto:david.santamauro@gmail.com>> wrote:
2. Anyone who wants to create a client to persist jack settings is
welcome to do so, and this doesn't require any changes to NSM.
However,
it is unlikely to work with sample rate changes. Lots of programs
support runtime bufsize changes though, if that's what you're
into.
I would love to take a stab at this. Seems like something within my
reach but if there is no option "start-before-others" or some
priority client loading, this seems pointless.
As long as no clients crash or otherwise freak out when you change the
buffer size at runtime, then there's no need to enforce an order. The
synchronization is only required in order to shutdown/restart JACK
(which isn't necessary to change the buffer size)
So then the assumption is that this "client" would only allow settings
manipulation and not deal with starting/stopping jack at all. If so, then
is there an exhaustive list of settings that can actually be changed
without having to restart?
I can't imagine one could change the device, e.g. without restarting.
11:06 p.m.
New subject: Session management with NSM
On 9/4/2014 3:46 PM, J. Liles wrote:
Well, now we're getting back into all the reasons why JACK settings
should not be part of a session in the first place. For example,
suppose that you could change the device at runtime...
I think this might be not understood yet, but JACK 2 *does* allows this.
You can switch devices (or any jack settings) during runtime, without
having to stop JACK.
This is called "switch master".
Because of this the buffer-size *and sample-rate* can change while JACK2
is running.
In which case the respective callbacks are called.
See
https://github.com/jackaudio/jack2/blob/master/common/JackServer.cpp#L371
5 Sep
5 Sep
12:16 a.m.
New subject: Session management with NSM
On Thu, Sep 4, 2014 at 2:06 PM, Filipe Coelho <falktx(a)gmail.com> wrote:
On 9/4/2014 3:46 PM, J. Liles wrote:
Terrifying--I mean cool! :-)
Well, now we're getting back into all the reasons why JACK settings
should not be part of a session in the first place. For example, suppose
that you could change the device at runtime...
I think this might be not understood yet, but JACK 2 *does* allows this.
You can switch devices (or any jack settings) during runtime, without
having to stop JACK.
This is called "switch master".
Because of this the buffer-size *and sample-rate* can change while JACK2
is running.
In which case the respective callbacks are called.
See https://github.com/jackaudio/jack2/blob/master/common/
JackServer.cpp#L371
12:40 a.m.
New subject: Session management with NSM
On 9/4/2014 4:36 PM, J. Liles wrote:
On Thu, Sep 4, 2014 at 12:58 PM, David Santamauro
<david.santamauro(a)gmail.com <mailto:david.santamauro@gmail.com>> wrote:
On 9/4/2014 3:46 PM, J. Liles wrote:
On Thu, Sep 4, 2014 at 12:41 PM, David Santamauro
<david.santamauro(a)gmail.com <mailto:david.santamauro@gmail.com>
<mailto:david.santamauro@__gmail.com
<mailto:david.santamauro@gmail.com>>> wrote:
2. Anyone who wants to create a client to persist jack
settings is
welcome to do so, and this doesn't require any changes
to NSM.
However,
it is unlikely to work with sample rate changes. Lots
of programs
support runtime bufsize changes though, if that's what
you're into.
I would love to take a stab at this. Seems like something
within my
reach but if there is no option "start-before-others" or some
priority client loading, this seems pointless.
As long as no clients crash or otherwise freak out when you
change the
buffer size at runtime, then there's no need to enforce an
order. The
synchronization is only required in order to shutdown/restart JACK
(which isn't necessary to change the buffer size)
So then the assumption is that this "client" would only allow
settings manipulation and not deal with starting/stopping jack at
all. If so, then is there an exhaustive list of settings that can
actually be changed without having to restart?
I can't imagine one could change the device, e.g. without restarting.
Well, now we're getting back into all the reasons why JACK settings
should not be part of a session in the first place. For example, suppose
that you could change the device at runtime: Now you change sessions to
one that uses a different device--and nothing works, because the client
can't reach out into the physical world and plug your other interface
into everything.
Just 1 use case (one of a few I have):
- sound card {a} snaked to separate recording room
- sound card {b} wired to local mixer, outboard synths and keyboards
(for post recording/mixing enhancements effects etc.)
Everything is already plugged in. No software reaching out of the box to
reroute cables.
... but I really don't think beating this dead horse is worth it.
The list you're looking for is here:
http://jackaudio.org/files/docs/html/group__ServerControl.html
thanks ... mea culpa. Sources are always important to consult.
4 Sep
4 Sep
7:29 p.m.
New subject: Session management with NSM
On Thu, Sep 04, 2014 at 03:34:57PM +0100, Rui Nuno Capela wrote:
as said, automatic latency compensation in qtractors
audio recording
is a one-time settlement--it gets settled at the time you take the
recording. nevermore it gets auto-adjusted later on, ie. the take
offset value, as read from jack_port_get_latency*(), won't ever
change thereafter. that means you're in charge to tweak it later if
you please, by summoning the clip properties dialog and changing the
offset value as you wish.
You only get correct latency compensation if you compensate both
when recording (the samples are older than they appear), and when
playing back (the samples will be output later). In both cases you
need to apply the _current_ value (Li, resp. Lo).
OTOH, there is never any need to store the offset. When recording,
just apply it to the stored position and forget about it - the
samples are now at their correct position (the one that corresponds
to having no latency).
rest assured that, in qtractor sequencer model, ever
since its
inception, all time locations do honor the midi/music metric scale
resolution.
For audio tracks that makes no sense. Aligning the start of the
track doesn't mean the content will be aligned, and that is what
matters if you want to align everything to the MIDI timescale.
Ciao,
--
FA
A world of exhaustive, reliable metadata would be an utopia.
It's also a pipe-dream, founded on self-delusion, nerd hubris
and hysterically inflated market opportunities. (Cory Doctorow)
5 Sep
5 Sep
1:11 a.m.
New subject: Session management with NSM
On Tue, Sep 2, 2014 at 4:00 PM, Philipp Überbacher <murks(a)tuxfamily.org>
wrote:
On Tue, 2 Sep 2014 19:42:16 +0100
Harry van Haaren <harryhaaren(a)gmail.com> wrote:
this is what ardour does. just FYI.
It could be discussed to "highjack"
~/.jackdrc by copying an NSM
sessions .jackdrc to ~/ although a hack solution for a power-user,
I think its not a good way to go for beginners. We need something to
fix this... ideas?
For my taste this solution is far too hackish. I would not expect or
want any program to modify my ~/.jackdrc.
6:09 a.m.
New subject: Session management with NSM
Am 05.09.2014 01:11, schrieb Paul Davis:
On Tue, Sep 2, 2014 at 4:00 PM, Philipp Überbacher
<murks(a)tuxfamily.org <mailto:murks@tuxfamily.org>> wrote:
On Tue, 2 Sep 2014 19:42:16 +0100
Harry van Haaren <harryhaaren(a)gmail.com
<mailto:harryhaaren@gmail.com>> wrote:
and qjackctl does as well. As a rc file it should store the last used
settings, shouldn't it?
For the case that jack settings should be stored within a saved session,
something like QjackCtl.conf would make more sense, were you could store
a couple of different jack settings by name.
Such a .conf file could easy generated by jackpatch, and if a user start
a session, were jackpatch is involved, jackpatch could pop up a
"warning", when the jack settings in use didn't compare to the last
saved settings in this session. How a user interact with the warning,
may be his own decision.
It could be discussed to "highjack"
~/.jackdrc by copying an NSM
sessions .jackdrc to ~/ although a hack solution for a
power-user,
I think its not a good way to go for beginners.
We need something to
fix this... ideas?
For my taste this solution is far too hackish. I would not expect or
want any program to modify my ~/.jackdrc.
this is what ardour does. just FYI.
3733
days inactive
3740
days old
linux-audio-user@lists.linuxaudio.org
66 comments
15 participants
participants (15)
-
Bruno Ruviaro -
Chris Bannister -
David Santamauro -
Filipe Coelho -
Fons Adriaensen -
Harry van Haaren -
hermann meyer -
J. Liles -
Kazakore -
Len Ovens -
Nils -
Paul Davis -
Philipp Überbacher -
Ralf Mardorf -
Rui Nuno Capela