23 Feb
2013
23 Feb
'13
5:01 p.m.
A couple of days ago, I tried out non-session-manager, and thought,
this is really nice. It really works in a practical, easy way.
Unfortunately the number of apps supporting non-session is quite small
(as is the case for *all* session management systems, AFAIK). There may
be "a complete audio studio" supporting non-session, from one choice of
sequencer to one synth to one sampler, but people like to use their
favorite software. You can't just say, "if you want to use a sequencer,
use X because it supports non-session". So its usefulness is limited.
However, many apps support one session management framework or the
other. So the obvious thing to do if you want to give people more
choices would be to create some kind of interoperability layer between
session management systems.
What do you think about this? Is there an effort for something like
this already underway? I personally think a good first step might be to
create some compatibility between non-session (because I like it) and
jack-session (because most people are using jack).
23 Feb
23 Feb
8:05 p.m.
On Sat, 2013-02-23 at 17:01 +0100, Johannes Kroll wrote:
A couple of days ago, I tried out non-session-manager,
and thought,
this is really nice. It really works in a practical, easy way.
Unfortunately the number of apps supporting non-session is quite small
(as is the case for *all* session management systems, AFAIK). There may
be "a complete audio studio" supporting non-session, from one choice of
sequencer to one synth to one sampler, but people like to use their
favorite software. You can't just say, "if you want to use a sequencer,
use X because it supports non-session". So its usefulness is limited.
However, many apps support one session management framework or the
other. So the obvious thing to do if you want to give people more
choices would be to create some kind of interoperability layer between
session management systems.
What do you think about this? Is there an effort for something like
this already underway? I personally think a good first step might be to
create some compatibility between non-session (because I like it) and
jack-session (because most people are using jack).
I was tinkering with saving sessions in a format that is just a
directory with a shell script with a standard name (and perhaps some
standard arguments) which you call to restore or do other things.
Not sure if that's a really feasible solution in general, but it's
basically the only way to save sessions in a way that don't require a
specific session manager to load, and doesn't impose any file formats.
Actually being able to restore sessions decently from a script requires
a few more sophisticated jack command line utilities (like a
jack_connect that can wait for clients and so on), but those are useful
anyway.
I like the lowest common denominator, and UNIXeyness, and zero
imposition of syntax and so on, of this idea, but haven't really
investigated it or done much of an implementation.
Being based purely on classic UNIXisms (directory and a script that
calls some utilities is all that's going on) is probably the only way to
actually get everybody to agree on such a thing. Standardization of
such a spec would only involved command line utilities/arguments, paths,
and environment variables. Thanks to the shebang mechanism, it would be
language agnostic as well.
Personally I have no plans to prioritize this, but I think it's an
interesting area to explore.
Cheers,
-dr
11:24 p.m.
On Sat, 23 Feb 2013 14:05:07 -0500
David Robillard <d(a)drobilla.net> wrote:
I was tinkering with saving sessions in a format that
is just a
directory with a shell script with a standard name (and perhaps some
standard arguments) which you call to restore or do other things.
Not sure if that's a really feasible solution in general, but it's
basically the only way to save sessions in a way that don't require a
specific session manager to load, and doesn't impose any file formats.
Actually being able to restore sessions decently from a script requires
a few more sophisticated jack command line utilities (like a
jack_connect that can wait for clients and so on), but those are useful
anyway.
Just a quick thought: How do you get the programs to save their state/file?
Does this not require at least some incoming message handling by the individual programs?
Nils
11:44 p.m.
On 23 February 2013 23:22, Nils Gey <ich(a)nilsgey.de> wrote:
On Sat, 23 Feb 2013 14:05:07 -0500
David Robillard <d(a)drobilla.net> wrote:
As a user of NSM, and from that user perspective, it does what it says
on the tin. It's user friendly, and helps administer the process of
starting up my large sessions with no rocket science involved.
Given the strong wills, and previous scorch marks in the ML about
session management, i have no desire to light a match here, but for
the simple task of starting a succession of apps in a session, NSM
does its job well, imho.
How much code is required in apps to enable them for NSM use?
Is there an appetite for at least one session management app that does
the simple stuff well that users can become familiar with as a
"linuxaudio" basic default, as a "unified" community protocol
agreement, without descending into hades and a flame war, in the
interest of taking the community forward, and giving users a better
experience?
Alex
I was tinkering with saving sessions in a format
that is just a
directory with a shell script with a standard name (and perhaps some
standard arguments) which you call to restore or do other things.
Not sure if that's a really feasible solution in general, but it's
basically the only way to save sessions in a way that don't require a
specific session manager to load, and doesn't impose any file formats.
Actually being able to restore sessions decently from a script requires
a few more sophisticated jack command line utilities (like a
jack_connect that can wait for clients and so on), but those are useful
anyway.
Just a quick thought: How do you get the programs to save their state/file?
Does this not require at least some incoming message handling by the individual
programs?
Nils
_______________________________________________
Linux-audio-dev mailing list
Linux-audio-dev(a)lists.linuxaudio.org
http://lists.linuxaudio.org/listinfo/linux-audio-dev
24 Feb
24 Feb
12:45 a.m.
On Sat, 2013-02-23 at 23:44 +0100, Alex Stone wrote:
[...]
As a user of NSM, and from that user perspective, it
does what it says
on the tin. It's user friendly, and helps administer the process of
starting up my large sessions with no rocket science involved.
Given the strong wills, and previous scorch marks in the ML about
session management, i have no desire to light a match here, but for
the simple task of starting a succession of apps in a session, NSM
does its job well, imho.
How much code is required in apps to enable them for NSM use?
Is there an appetite for at least one session management app that does
the simple stuff well that users can become familiar with as a
"linuxaudio" basic default, as a "unified" community protocol
agreement, without descending into hades and a flame war, in the
interest of taking the community forward, and giving users a better
experience?
Oh boy, *this*, again.
In retrospect, replying to this thread at all is surely the dumbest
thing I will do today. Nevermind.
Have a nice day ;)
-dr (Who still thinks a universally restorable format is a nice idea)
1:32 a.m.
On Sat, 23 Feb 2013 18:45:15 -0500
David Robillard <d(a)drobilla.net> wrote:
On Sat, 2013-02-23 at 23:44 +0100, Alex Stone wrote:
[...]
Which means the person who started the thread must surely be the
dumbest person on earth, or something.
Could you elaborate please: why is compatibility between the existing
session management systems a dumb idea? Is it because if something
would work together in the Linux audio world in a reasonable way,
there would be danger of somebody actually using it? Please enlighten
me.
As a user of NSM, and from that user perspective,
it does what it says
on the tin. It's user friendly, and helps administer the process of
starting up my large sessions with no rocket science involved.
Given the strong wills, and previous scorch marks in the ML about
session management, i have no desire to light a match here, but for
the simple task of starting a succession of apps in a session, NSM
does its job well, imho.
How much code is required in apps to enable them for NSM use?
Is there an appetite for at least one session management app that does
the simple stuff well that users can become familiar with as a
"linuxaudio" basic default, as a "unified" community protocol
agreement, without descending into hades and a flame war, in the
interest of taking the community forward, and giving users a better
experience?
Oh boy, *this*, again.
In retrospect, replying to this thread at all is surely the dumbest
thing I will do today. Nevermind. 
1:47 a.m.
On Sat, Feb 23, 2013 at 7:32 PM, Johannes Kroll <jkroll(a)lavabit.com> wrote:
Could you elaborate please: why is compatibility between the existing
session management systems a dumb idea?
you don't compatibility between DECnet and BITNET. you don't get
compatibility between english and chinese. what you get is a *new*
system/protocol/language.
<ob-xkcd>
http://xkcd.com/927/
</ob-xkcd>
2:05 a.m.
On Sat, 23 Feb 2013 19:47:26 -0500
Paul Davis <paul(a)linuxaudiosystems.com> wrote:
On Sat, Feb 23, 2013 at 7:32 PM, Johannes Kroll
<jkroll(a)lavabit.com> wrote:
You and David do not understand what I'm proposing. My intention is not
to create a new protocol. Creating another system because there are
already too many would be indeed idiotic: that's what has been done
before with the other session managers. I imagine creating *something*
that makes the existing systems work together, *without* changing the
clients that use the existing systems.
I.e. one app may be thinking it's talking to non-session, one app
speaks ladish, another thinks it's talking to jack-session, but in
reality they all talk to one session manager which implements all 3
(4... 7... umpteen) protocols.
I have not looked at the implementations of the existing systems. Maybe
what I'm proposing is not easily possible. In any case, I want you to
understand that I'm not proposing to increase the number of systems in
order to decrease the number of systems. That would be, indeed, dumb in
a painfully obvious way.
Could you elaborate please: why is compatibility between the existing
session management systems a dumb idea?
you don't compatibility between DECnet and BITNET. you don't get
compatibility between english and chinese. what you get is a *new*
system/protocol/language.
<ob-xkcd>
http://xkcd.com/927/
</ob-xkcd> 
2:13 a.m.
On Sun, 2013-02-24 at 02:05 +0100, Johannes Kroll wrote:
I imagine creating *something*
that makes the existing systems work together, *without* changing the
clients that use the existing systems.
I.e. one app may be thinking it's talking to non-session, one app
speaks ladish, another thinks it's talking to jack-session, but in
reality they all talk to one session manager which implements all 3
(4... 7... umpteen) protocols.
I have not looked at the implementations of the existing systems. Maybe
what I'm proposing is not easily possible. In any case, I want you to
understand that I'm not proposing to increase the number of systems in
order to decrease the number of systems. That would be, indeed, dumb in
a painfully obvious way.
I don't know how all those session managers work, but theoretically it
asks for race conditions, assumed different management systems try to
archive the same thing, but in a different order or something like this.
--
http://sacom.hk/mission
2:28 a.m.
On Sat, Feb 23, 2013 at 5:05 PM, Johannes Kroll <jkroll(a)lavabit.com> wrote:
On Sat, 23 Feb 2013 19:47:26 -0500
Paul Davis <paul(a)linuxaudiosystems.com> wrote:
You and David do not understand what I'm proposing. My intention is not
to create a new protocol. Creating another system because there are
already too many would be indeed idiotic: that's what has been done
before with the other session managers. I imagine creating *something*
that makes the existing systems work together, *without* changing the
clients that use the existing systems.
I.e. one app may be thinking it's talking to non-session, one app
speaks ladish, another thinks it's talking to jack-session, but in
reality they all talk to one session manager which implements all 3
(4... 7... umpteen) protocols.
I have not looked at the implementations of the existing systems. Maybe
what I'm proposing is not easily possible. In any case, I want you to
understand that I'm not proposing to increase the number of systems in
order to decrease the number of systems. That would be, indeed, dumb in
a painfully obvious way.
All of the existing session management protocols have inherent limitations
which I was attempting to avoid by creating NSM. Nedko and I have discussed
including NSM protocol support in LADISH, which would be kind of like what
you're talking about, but the problem remains that the whole would be a
lowest-common-denominator of functionality. Now, if jack session and LASH
and LADISH level 1 applications eventually fade out and move to the NSM
protocol, then maybe that's OK. But in the meantime it's not going to be as
functional as using pure NSM.
On Sat, Feb 23, 2013 at 7:32 PM, Johannes Kroll
<jkroll(a)lavabit.com>
wrote:
Could you elaborate please: why is compatibility between the existing
session management systems a dumb idea?
you don't compatibility between DECnet and BITNET. you don't get
compatibility between english and chinese. what you get is a *new*
system/protocol/language.
<ob-xkcd>
http://xkcd.com/927/
</ob-xkcd>
3:34 a.m.
On Sat, 23 Feb 2013 17:28:49 -0800
"J. Liles" <malnourite(a)gmail.com> wrote:
All of the existing session management protocols have
inherent limitations
which I was attempting to avoid by creating NSM. Nedko and I have discussed
including NSM protocol support in LADISH, which would be kind of like what
you're talking about, but the problem remains that the whole would be a
lowest-common-denominator of functionality. Now, if jack session and LASH
and LADISH level 1 applications eventually fade out and move to the NSM
protocol, then maybe that's OK. But in the meantime it's not going to be as
functional as using pure NSM.
Please, don't turn this into a "which session manager is the best" war,
that's not what I intended. Surely each coder thinks *their* session
manager is the best one, why else would they have written it. In
reality every SM has their strengths and weaknesses I guess. (For
example I noticed that NSM, which I otherwise like, can't restore Jack
connections without an external tool like jack_patch - and with the
tool, it doesn't seem to restore MIDI connections).
About shell scripts (David): that sounds like the lowest common
denominator approach, and while it's neat and UNIXy and everything,
unless I misunderstood, writing shell scripts to start apps is what I
can do anyway, without any session manager. Also, I think the ability
to tell apps to save state while they are running is important, and
shell scripts can't do that.
I would hope that something more than the lowest common denominator
approach would be possible. As I understand it, all SM systems do the
following, in one way or the other:
1) start apps with a saved state (may be implemented using 2)
2) tell running apps to load their state from a given session
3) tell apps to save their state to a given session
4) possibly restore JACK and alsamidi connections
5) possibly implement parts of the session loading and saving (this
might be completely up to the apps)
If that's basically what SMs do, it should be possible to create an
interoperability layer (*NOT* a new protocol!) that talks the
existing protocols and does the necessary things. There might be
tradeoffs, when one SM system has less functionality as the other, but
that would hopefully only affect the apps using that SM system, not the
others. So it would not be "lowest common denominator".
If the differences between SMs are that great that doing this isn't
possible at all, that would be sad, because I don't really see any SM
becoming the defacto standard any time soon.
3:47 a.m.
On Sun, 2013-02-24 at 03:34 +0100, Johannes Kroll wrote:
(For example I noticed that NSM, which I otherwise
like, can't restore
Jack connections without an external tool like jack_patch - and with
the tool, it doesn't seem to restore MIDI connections).
aj-snapshot?
Also, I think the ability to tell apps to save state
while they are
running is important, and shell scripts can't do that.
app_name [perhaps some option] /path/filename?
At the moment I only remember that this doesn't work for JAMin.
--
ASCII Ribbon Campaign http://www.asciiribbon.org/index-de.html
3:49 a.m.
On Sun, 2013-02-24 at 03:46 +0100, Ralf Mardorf wrote:
On Sun, 2013-02-24 at 03:34 +0100, Johannes Kroll
wrote:
To restore:
(For example I noticed that NSM, which I
otherwise like, can't restore
Jack connections without an external tool like jack_patch - and with
the tool, it doesn't seem to restore MIDI connections).
aj-snapshot?
> Also, I think the ability to tell apps to save state while they are
> running is important, and shell scripts can't do that. app_name [perhaps some option] /path/filename?
You have to save it manually for each app, that's true.
At the moment I only remember that this doesn't
work for JAMin.
--
http://sacom.hk/mission
4:15 a.m.
On Sat, Feb 23, 2013 at 6:34 PM, Johannes Kroll <jkroll(a)lavabit.com> wrote:
On Sat, 23 Feb 2013 17:28:49 -0800
"J. Liles" <malnourite(a)gmail.com> wrote:
I'm not starting a war. Many of the other SM protocols were designed with
full knowledge of their limitations and compromises (that is to say, the
authors don't believe they are the best solution by any means, just a
workable one). In fact, the differences between the different SM protocols
are great, and in the case of NSM even greater. Drobilla, with mention of
shell scripts, was speaking only of a session disk format that could used
to port existing sessions from one SM to another. If we add NSM support to
LADISH, that will be exactly what you desire. One SM front end that
supports every extant protocol. However, I believe this will hardly make
the situation any easier on the *user* than it is now (and since when are
people happy with LASH etc?). LASH, jack-session and LADISH Level 1 are
extremely limited, and, IMHO inadequate protocols. Continuing support for
them does nothing to enhance the user experience. And it isn't as if we're
talking about 100s of client applications here, there are only a handful
that support any kind of SM protocol period. I may have the desire to patch
everything to support NSM, but what I do not have is the time (and the time
I might spend adding NSM support to LADISH might better be spent converting
jack-session and LASH clients over to NSM). In any case, patching will do
far more good than talking!
All of the existing session management protocols
have inherent
limitations
which I was attempting to avoid by creating NSM.
Nedko and I have
discussed
including NSM protocol support in LADISH, which
would be kind of like
what
you're talking about, but the problem remains
that the whole would be a
lowest-common-denominator of functionality. Now, if jack session and LASH
and LADISH level 1 applications eventually fade out and move to the NSM
protocol, then maybe that's OK. But in the meantime it's not going to be
as
functional as using pure NSM.
Please, don't turn this into a "which session manager is the best" war,
that's not what I intended. Surely each coder thinks *their* session
manager is the best one, why else would they have written it. In
reality every SM has their strengths and weaknesses I guess. (For
example I noticed that NSM, which I otherwise like, can't restore Jack
connections without an external tool like jack_patch - and with the
tool, it doesn't seem to restore MIDI connections).
About shell scripts (David): that sounds like the lowest common
denominator approach, and while it's neat and UNIXy and everything,
unless I misunderstood, writing shell scripts to start apps is what I
can do anyway, without any session manager. Also, I think the ability
to tell apps to save state while they are running is important, and
shell scripts can't do that.
I would hope that something more than the lowest common denominator
approach would be possible. As I understand it, all SM systems do the
following, in one way or the other:
1) start apps with a saved state (may be implemented using 2)
2) tell running apps to load their state from a given session
3) tell apps to save their state to a given session
4) possibly restore JACK and alsamidi connections
5) possibly implement parts of the session loading and saving (this
might be completely up to the apps)
If that's basically what SMs do, it should be possible to create an
interoperability layer (*NOT* a new protocol!) that talks the
existing protocols and does the necessary things. There might be
tradeoffs, when one SM system has less functionality as the other, but
that would hopefully only affect the apps using that SM system, not the
others. So it would not be "lowest common denominator".
If the differences between SMs are that great that doing this isn't
possible at all, that would be sad, because I don't really see any SM
becoming the defacto standard any time soon.
5:07 a.m.
On Sat, 23 Feb 2013 19:15:16 -0800
"J. Liles" <malnourite(a)gmail.com> wrote:
I'm not starting a war. Many of the other SM protocols were designed with
full knowledge of their limitations and compromises (that is to say, the
authors don't believe they are the best solution by any means, just a
workable one). In fact, the differences between the different SM protocols
are great, and in the case of NSM even greater. Drobilla, with mention of
shell scripts, was speaking only of a session disk format that could used
to port existing sessions from one SM to another.
OK, that makes sense. Porting existing sessions would be a good first
step, but still, it sounds cumbersome. I'm not sure if it would be much
easier than starting the apps by hand.
If we add NSM support to
LADISH, that will be exactly what you desire. One SM front end that
supports every extant protocol. However, I believe this will hardly make
the situation any easier on the *user* than it is now (and since when are
people happy with LASH etc?). LASH, jack-session and LADISH Level 1 are
extremely limited, and, IMHO inadequate protocols.
In what way? I don't know much about LASH and LADISH, but I'm looking
at the jack-session api docs [1] right now. From what I can see, it
does everything it needs to do. There is also a GUI available in
qjackctl which I use anyway. I think that I, as a user, would be happy
with jack-session, if only my favourite apps would support it!
Continuing support for
them does nothing to enhance the user experience. And it isn't as if we're
talking about 100s of client applications here, there are only a handful
that support any kind of SM protocol period. I may have the desire to patch
everything to support NSM, but what I do not have is the time (and the time
I might spend adding NSM support to LADISH might better be spent converting
jack-session and LASH clients over to NSM). In any case, patching will do
far more good than talking!
True, but patching to what? NSM? I like NSM but I'm not convinced that
it is "the best" possible SM. Others may think similar. Some people may
still want to support jack-session, simply because they think it is the
way to go, even if you think it is inadequate or obsolete.
You won't win everyone over to use NSM. Or *any* particular SM, for that
matter. It's cat herding. For this reason, I still think an
interoperability layer would be a good thing. If it is technically
feasible I'm not sure.
[1]
http://jackaudio.org/files/docs/html/group__SessionClientFunctions.html
5:09 a.m.
Am 24.02.2013 04:15, schrieb J. Liles:
On Sat, Feb 23, 2013 at 6:34 PM, Johannes Kroll <jkroll(a)lavabit.com
<mailto:jkroll@lavabit.com>> wrote:
On Sat, 23 Feb 2013 17:28:49 -0800
"J. Liles" <malnourite(a)gmail.com <mailto:malnourite@gmail.com>>
wrote:
I stated it out already in a other thread: without ever been released as
NSM (means available as tarball, or what ever, with ONLY NSM included),
I wouldn't support it.
All of the existing session management protocols
have inherent
limitations
which I was attempting to avoid by creating NSM.
Nedko and I
have discussed
including NSM protocol support in LADISH, which
would be kind of
like what
you're talking about, but the problem remains
that the whole
would be a
lowest-common-denominator of functionality. Now,
if jack session
and LASH
and LADISH level 1 applications eventually fade
out and move to
the NSM
protocol, then maybe that's OK. But in the
meantime it's not
going to be as
functional as using pure NSM.
Please, don't turn this into a "which session manager is the best"
war,
that's not what I intended. Surely each coder thinks *their* session
manager is the best one, why else would they have written it. In
reality every SM has their strengths and weaknesses I guess. (For
example I noticed that NSM, which I otherwise like, can't restore Jack
connections without an external tool like jack_patch - and with the
tool, it doesn't seem to restore MIDI connections).
About shell scripts (David): that sounds like the lowest common
denominator approach, and while it's neat and UNIXy and everything,
unless I misunderstood, writing shell scripts to start apps is what I
can do anyway, without any session manager. Also, I think the ability
to tell apps to save state while they are running is important, and
shell scripts can't do that.
I would hope that something more than the lowest common denominator
approach would be possible. As I understand it, all SM systems do the
following, in one way or the other:
1) start apps with a saved state (may be implemented using 2)
2) tell running apps to load their state from a given session
3) tell apps to save their state to a given session
4) possibly restore JACK and alsamidi connections
5) possibly implement parts of the session loading and saving (this
might be completely up to the apps)
If that's basically what SMs do, it should be possible to create an
interoperability layer (*NOT* a new protocol!) that talks the
existing protocols and does the necessary things. There might be
tradeoffs, when one SM system has less functionality as the other, but
that would hopefully only affect the apps using that SM system,
not the
others. So it would not be "lowest common denominator".
If the differences between SMs are that great that doing this isn't
possible at all, that would be sad, because I don't really see any SM
becoming the defacto standard any time soon.
I'm not starting a war. Many of the other SM protocols were designed
with full knowledge of their limitations and compromises (that is to
say, the authors don't believe they are the best solution by any
means, just a workable one). In fact, the differences between the
different SM protocols are great, and in the case of NSM even greater.
Drobilla, with mention of shell scripts, was speaking only of a
session disk format that could used to port existing sessions from one
SM to another. If we add NSM support to LADISH, that will be exactly
what you desire. One SM front end that supports every extant protocol.
However, I believe this will hardly make the situation any easier on
the *user* than it is now (and since when are people happy with LASH
etc?). LASH, jack-session and LADISH Level 1 are extremely limited,
and, IMHO inadequate protocols. Continuing support for them does
nothing to enhance the user experience. And it isn't as if we're
talking about 100s of client applications here, there are only a
handful that support any kind of SM protocol period. I may have the
desire to patch everything to support NSM, but what I do not have is
the time (and the time I might spend adding NSM support to LADISH
might better be spent converting jack-session and LASH clients over to
NSM). In any case, patching will do far more good than talking!
6:02 a.m.
On Sat, Feb 23, 2013 at 8:09 PM, hermann meyer <brummer-(a)web.de> wrote:
Am 24.02.2013 04:15, schrieb J. Liles:
On Sat, Feb 23, 2013 at 6:34 PM, Johannes Kroll <jkroll(a)lavabit.com>wrote;wrote:
This is stupid. What difference does it make what other programs are in the
source repository? Distributions can and should package the programs
individually. Also, NSM clients require from the NSM server implementation.
There is no libnsm to link to etc. This is the definition of a non-issue.
On Sat, 23 Feb 2013 17:28:49 -0800
"J. Liles" <malnourite(a)gmail.com> wrote:
I'm not starting a war. Many of the other SM protocols were designed with
full knowledge of their limitations and compromises (that is to say, the
authors don't believe they are the best solution by any means, just a
workable one). In fact, the differences between the different SM protocols
are great, and in the case of NSM even greater. Drobilla, with mention of
shell scripts, was speaking only of a session disk format that could used
to port existing sessions from one SM to another. If we add NSM support to
LADISH, that will be exactly what you desire. One SM front end that
supports every extant protocol. However, I believe this will hardly make
the situation any easier on the *user* than it is now (and since when are
people happy with LASH etc?). LASH, jack-session and LADISH Level 1 are
extremely limited, and, IMHO inadequate protocols. Continuing support for
them does nothing to enhance the user experience. And it isn't as if we're
talking about 100s of client applications here, there are only a handful
that support any kind of SM protocol period. I may have the desire to patch
everything to support NSM, but what I do not have is the time (and the time
I might spend adding NSM support to LADISH might better be spent converting
jack-session and LASH clients over to NSM). In any case, patching will do
far more good than talking!
I stated it out already in a other thread: without ever been released
as NSM (means available as tarball, or what ever, with ONLY NSM included),
I wouldn't support it.
All of the existing session management protocols
have inherent
limitations
which I was attempting to avoid by creating NSM.
Nedko and I have
discussed
including NSM protocol support in LADISH, which
would be kind of like
what
you're talking about, but the problem remains
that the whole would be a
lowest-common-denominator of functionality. Now, if jack session and
LASH
and LADISH level 1 applications eventually fade
out and move to the NSM
protocol, then maybe that's OK. But in the meantime it's not going to
be
as
functional as using pure NSM.
Please, don't turn this into a "which session manager is the best" war,
that's not what I intended. Surely each coder thinks *their* session
manager is the best one, why else would they have written it. In
reality every SM has their strengths and weaknesses I guess. (For
example I noticed that NSM, which I otherwise like, can't restore Jack
connections without an external tool like jack_patch - and with the
tool, it doesn't seem to restore MIDI connections).
About shell scripts (David): that sounds like the lowest common
denominator approach, and while it's neat and UNIXy and everything,
unless I misunderstood, writing shell scripts to start apps is what I
can do anyway, without any session manager. Also, I think the ability
to tell apps to save state while they are running is important, and
shell scripts can't do that.
I would hope that something more than the lowest common denominator
approach would be possible. As I understand it, all SM systems do the
following, in one way or the other:
1) start apps with a saved state (may be implemented using 2)
2) tell running apps to load their state from a given session
3) tell apps to save their state to a given session
4) possibly restore JACK and alsamidi connections
5) possibly implement parts of the session loading and saving (this
might be completely up to the apps)
If that's basically what SMs do, it should be possible to create an
interoperability layer (*NOT* a new protocol!) that talks the
existing protocols and does the necessary things. There might be
tradeoffs, when one SM system has less functionality as the other, but
that would hopefully only affect the apps using that SM system, not the
others. So it would not be "lowest common denominator".
If the differences between SMs are that great that doing this isn't
possible at all, that would be sad, because I don't really see any SM
becoming the defacto standard any time soon.
6:13 a.m.
Am 24.02.2013 06:02, schrieb J. Liles:
I stated it out already in a other thread: without ever been
released as NSM (means available as tarball, or what ever, with
ONLY NSM included), I wouldn't support it.
This is stupid. What difference does it make what other programs are
in the source repository? Distributions can and should package the
programs individually. Also, NSM clients require from the NSM server
implementation. There is no libnsm to link to etc. This is the
definition of a non-issue.
So be it for you.
For me, a session management which I will support in my projects, have
to be released as such. Otherwise I wouldn't waste my time with it. period.
10:42 a.m.
On Sat, Feb 23, 2013 at 9:13 PM, hermann meyer <brummer-(a)web.de> wrote:
Am 24.02.2013 06:02, schrieb J. Liles:
I stated it out already in a other thread: without ever been released as
You're not making any sense. Why would I waste my time trying to make
something which is already 100% modular and independent appear to be more
so? You clearly have some rather fundamental misunderstanding of what's
involved here. All Non-DAW etc have in common with NSM is that they share
the same author and happen to work together. If that's too much integration
for you, well then you must have some very strange motives.
NSM (means available as tarball, or what ever,
with ONLY NSM included), I
wouldn't support it.
This is stupid. What difference does it make what other programs are in
the source repository? Distributions can and should package the programs
individually. Also, NSM clients require from the NSM server implementation.
There is no libnsm to link to etc. This is the definition of a non-issue.
So be it for you.
For me, a session management which I will support in my projects, have to
be released as such. Otherwise I wouldn't waste my time with it. period.
11:59 a.m.
Do I realy need to explain to you for what a release is good for?
--
Diese Nachricht wurde von meinem Android Mobiltelefon mit WEB.DE Mail gesendet.
"J. Liles" <malnourite(a)gmail.com> schrieb:
On Sat, Feb 23, 2013 at 9:13 PM, hermann meyer <brummer-(a)web.de> wrote:
Am 24.02.2013 06:02, schrieb J. Liles:
I stated it out already in a other thread: without ever been released as NSM (means
available as tarball, or what ever, with ONLY NSM included), I wouldn't support it.
This is stupid. What difference does it make what other programs are in the source
repository? Distributions can and should package the programs individually. Also, NSM
clients require from the NSM server implementation. There is no libnsm to link to etc.
This is the definition of a non-issue.
So be it for you.
For me, a session management which I will support in my projects, have to be released as
such. Otherwise I wouldn't waste my time with it. period.
You're not making any sense. Why would I waste my time trying to make something which
is already 100% modular and independent appear to be more so? You clearly have some rather
fundamental misunderstanding of what's involved here. All Non-DAW etc have in common
with NSM is that they share the same author and happen to work together. If that's too
much integration for you, well then you must have some very strange motives.
4:21 p.m.
On Sun, 24 Feb 2013 01:41:58 -0800
"J. Liles" <malnourite(a)gmail.com> wrote:
On Sat, Feb 23, 2013 at 9:13 PM, hermann meyer
<brummer-(a)web.de> wrote:
I don't understand you two...
Hermann, why don't use the client parts of NSM as they are if you want
to support it...
J, why don't you package only the code needed to create an NSM client
separately if it's important to him... Giving out a tarball with only
the client code, an example client, and (a link to) the documentation
won't hurt adoption...
Am 24.02.2013 06:02, schrieb J. Liles:
I stated it out already in a other thread: without ever been released as
You're not making any sense. Why would I waste my time trying to make
something which is already 100% modular and independent appear to be more
so? You clearly have some rather fundamental misunderstanding of what's
involved here. All Non-DAW etc have in common with NSM is that they share
the same author and happen to work together. If that's too much integration
for you, well then you must have some very strange motives. NSM (means available as tarball, or what ever,
with ONLY NSM included), I
wouldn't support it.
This is stupid. What difference does it make what other programs are in
the source repository? Distributions can and should package the programs
individually. Also, NSM clients require from the NSM server implementation.
There is no libnsm to link to etc. This is the definition of a non-issue.
So be it for you.
For me, a session management which I will support in my projects, have to
be released as such. Otherwise I wouldn't waste my time with it. period.
11:58 a.m.
On Sun, Feb 24, 2013 at 4:15 AM, J. Liles <malnourite(a)gmail.com> wrote:
... I may have the desire to patch everything to
support NSM, but what I
do not have is the time (and the time I might spend adding NSM support to
LADISH might better be spent converting jack-session and LASH clients over
to NSM). In any case, patching will do far more good than talking!
I agree. I have added NSM support to some zita programs:
https://github.com/royvegard/zita-rev1
https://github.com/royvegard/zita-at1
--
Roy Vegard
4:24 p.m.
On Sun, 24 Feb 2013 11:57:56 +0100
Roy Vegard Ovesen <roy.vegard.ovesen(a)gmail.com> wrote:
On Sun, Feb 24, 2013 at 4:15 AM, J. Liles
<malnourite(a)gmail.com> wrote:
Cool. If this thread prompted you to do it, then at least some good came
out of it :D
... I may have the desire to patch everything to
support NSM, but what I
do not have is the time (and the time I might spend adding NSM support to
LADISH might better be spent converting jack-session and LASH clients over
to NSM). In any case, patching will do far more good than talking!
I agree. I have added NSM support to some zita programs:
https://github.com/royvegard/zita-rev1
https://github.com/royvegard/zita-at1
12:36 a.m.
On Sat, 2013-02-23 at 23:22 +0100, Nils Gey wrote:
On Sat, 23 Feb 2013 14:05:07 -0500
David Robillard <d(a)drobilla.net> wrote:
This idea obviously only applies as a portable way to store sessions.
The question you just asked is essentially "how do session managers
work?" Well, in various ways - we have several. Trying to make a
common protocol or whatever isn't "interoperability", it's making yet
another session management API/protocol.
-dr
I was tinkering with saving sessions in a format
that is just a
directory with a shell script with a standard name (and perhaps some
standard arguments) which you call to restore or do other things.
Not sure if that's a really feasible solution in general, but it's
basically the only way to save sessions in a way that don't require a
specific session manager to load, and doesn't impose any file formats.
Actually being able to restore sessions decently from a script requires
a few more sophisticated jack command line utilities (like a
jack_connect that can wait for clients and so on), but those are useful
anyway.
Just a quick thought: How do you get the programs to save their state/file?
Does this not require at least some incoming message handling by the individual programs?
1:30 a.m.
On Sat, Feb 23, 2013 at 8:05 PM, David Robillard wrote:
...
I was tinkering with saving sessions in a format that
is just a
directory with a shell script with a standard name (and perhaps some
standard arguments) which you call to restore or do other things.
Not sure if that's a really feasible solution in general, but it's
basically the only way to save sessions in a way that don't require a
specific session manager to load, and doesn't impose any file formats.
Actually being able to restore sessions decently from a script requires
a few more sophisticated jack command line utilities (like a
jack_connect that can wait for clients and so on), but those are useful
anyway.
I like the lowest common denominator, and UNIXeyness, and zero
imposition of syntax and so on, of this idea, but haven't really
investigated it or done much of an implementation.
Being based purely on classic UNIXisms (directory and a script that
calls some utilities is all that's going on) is probably the only way to
actually get everybody to agree on such a thing. Standardization of
such a spec would only involved command line utilities/arguments, paths,
and environment variables. Thanks to the shebang mechanism, it would be
language agnostic as well.
Personally I have no plans to prioritize this, but I think it's an
interesting area to explore.
Chino goes in that direction. Less session management, more
a framework for building meta-applications from applications.
A well-formed preset needs to be created for the user's use
cases, that preset then defines applications via a bash file
containing some functions and variables and via application-files
that get copied to child sessions.
It still needs some love, but just today I pushed a new release
getting rid of a few bugs and inconveniences. It's surely not
what many people call user-friendly, just my take on a UNIXish
manner of herding the cats (applications).
http://chino.tuxfamily.org
cheers
-da
10:04 p.m.
On Sun, February 24, 2013 6:05 am, David Robillard wrote:
On Sat, 2013-02-23 at 17:01 +0100, Johannes Kroll
wrote:
Why do applications need to support a specific session manager? The
session manager just calls the JACK API to notify a client app that an
update is required to the internal state.
What else is there to bother with on the application side?
--
Patrick Shirkey
Boost Hardware Ltd
A couple of days ago, I tried out
non-session-manager, and thought,
this is really nice. It really works in a practical, easy way.
Unfortunately the number of apps supporting non-session is quite small
(as is the case for *all* session management systems, AFAIK). There may
be "a complete audio studio" supporting non-session, from one choice of
sequencer to one synth to one sampler, but people like to use their
favorite software. You can't just say, "if you want to use a sequencer,
use X because it supports non-session". So its usefulness is limited.
However, many apps support one session management framework or the
other. So the obvious thing to do if you want to give people more
choices would be to create some kind of interoperability layer between
session management systems.
What do you think about this? Is there an effort for something like
this already underway? I personally think a good first step might be to
create some compatibility between non-session (because I like it) and
jack-session (because most people are using jack).
I was tinkering with saving sessions in a format that is just a
directory with a shell script with a standard name (and perhaps some
standard arguments) which you call to restore or do other things.
Not sure if that's a really feasible solution in general, but it's
basically the only way to save sessions in a way that don't require a
specific session manager to load, and doesn't impose any file formats.
Actually being able to restore sessions decently from a script requires
a few more sophisticated jack command line utilities (like a
jack_connect that can wait for clients and so on), but those are useful
anyway.
I like the lowest common denominator, and UNIXeyness, and zero
imposition of syntax and so on, of this idea, but haven't really
investigated it or done much of an implementation.
Being based purely on classic UNIXisms (directory and a script that
calls some utilities is all that's going on) is probably the only way to
actually get everybody to agree on such a thing. Standardization of
such a spec would only involved command line utilities/arguments, paths,
and environment variables. Thanks to the shebang mechanism, it would be
language agnostic as well.
Personally I have no plans to prioritize this, but I think it's an
interesting area to explore.
1:35 p.m.
Greetings,
Shameless self-promo for a recent superficial non-technical article on
Linux audio session managers:
http://lwn.net/Articles/533594/
With comments from Jonathan Brickman and Chino's developer.
Best,
dp
4286
days inactive
4287
days old
linux-audio-dev@lists.linuxaudio.org
26 comments
13 participants
participants (13)
-
Alex Stone -
brummer- -
Dave Phillips -
David Adler -
David Robillard -
hermann meyer
-
J. Liles -
Johannes Kroll -
Nils Gey -
Patrick Shirkey -
Paul Davis -
Ralf Mardorf -
Roy Vegard Ovesen