29 Mar
2012
29 Mar
'12
3:34 p.m.
The discussion started, with the question about large files.
Keep it simple - store either files or links in the session folder ?
Why not ?
Some more opinions please.
--
E.R.
29 Mar
29 Mar
3:44 p.m.
Am 29. März 2012 15:34 schrieb Emanuel Rumpf <xbran(a)web.de>de>:
Back to life - back to reality
1. We start qtractor as part of a session, create some midi-tracks,
include some external wav-files.
Should the SM "know" about these external files, as I suggested ?
(Allowing the user to find out basic info about it. )
Or leave it completely to qtractor ?
2. We record a new file in qtractor. Where would it be stored ?
Should the SM "know" about this file ?
3. A session is duplicated.
How does the SM handle the recorded and external files =
4. A session is exported.
Jonathan said, current practice is a simple directory copy.
Well ! Simple and not bad at all.
But what about the external files ?
Just make some symlinks for them ?
--
E.R.
11:22 p.m.
On 03/29/2012 02:44 PM, Emanuel Rumpf wrote:
Back to life - back to reality
1. We start qtractor as part of a session, create some midi-tracks,
include some external wav-files.
Should the SM "know" about these external files, as I suggested ?
(Allowing the user to find out basic info about it. )
Or leave it completely to qtractor ?
2. We record a new file in qtractor. Where would it be stored ?
Should the SM "know" about this file ?
3. A session is duplicated.
How does the SM handle the recorded and external files =
4. A session is exported.
Jonathan said, current practice is a simple directory copy.
Well ! Simple and not bad at all.
But what about the external files ?
Just make some symlinks for them ?
indeed. real life that is :)
as far as qtractor is, all media content files, be that either audio or
midi types, are ALL external files. it's true that some are created and
edited under qtractor direct control, but they are all external. no
exceptions.
otoh, a qtractor session file (xml) is a listing or a map of references
(links, paths, whatever) to those external files as they are in the
file-system. but no, never symlinks.
qtractor's "session directory" (aka. its own "session folder") is
just
an user preference, a location where all newly created media files
(again, audio or midi, recorded or scratch) are located first time they
get into existence--do not ever confuse this with any portable session
directory or folder in any way. in fact, you get serious trouble if you
do so. although there's this qtractor session archive/zip bundle file
format (.qtz) which serves that particular purpose but as an option and
convenience (just like an independent, moveable, self-contained zip-folder)
external or not, all-media content file "awareness" from a foreseeable
session management entity, being that big or small, central or not, is,
if you ask me, utopian.
sure, it would certainly be a really-good-thing(tm) to make a session
archive portable across file-systems, machine architectures or
platforms, users, networks, you name it... it really seems like an
all-in-one/knows-it-all "goddess" application if you ask me. yuck! a
pipe-dream if i reckon one :)
otoh. now in particular, those GUI (file menu) restrictions that NSM is
posing on applications is something i won't comply to any time soon, not
even later. so sorry. it's way too restrictive to me and my own
belongings. from what i read, applications must then be modified to run
in either of two or more awful different session modes eg. managed and
non-managed? for x-sake, as if we hadn't enough of that already... i am
so sorry again, but such a design won't fly much above the grass in my
lawn... it gives me the shivers o,O
but that maybe just a first glance pov. don't take it final
however ;) imho, the SM should only know about application instances
that are part of the so-called "session", their state of which only each
application knows about their own, or so i believe, _and_ the means to
recall that collected set of states later on. if that state is described
by a set of files, so be it. let's name it state-data-files, or just
call it _internal_ files perhaps?
more. a session manager (or its protocol spec) should not touch any, any
at all, of the external (media content?) files that each application are
possibly working on during their life span.
under the so called session's -folder (or -directory, if you prefer)
there should be _only_ stored the state-data-files that pertain to each
participant application. you guess it right, that's the state of each
participating application instance at the time of the eventual
"save-this-session-now!" command gets issued (a-la snapshot). and add to
that the inter-connection state file(s) as it will be certainly the job
of the SM to gather too. jack-session does this kind of stuff.
now back to square one. to make that whole session state, folder or
directory, as an archival portable one is, quite frankly and imho again,
utopian. nuff said :) but (oh no, not again), as a clever guy once said,
the impossible turns out to be possible when there's someone foolish
enough to do it ;)
my 2c
--
rncbc aka Rui Nuno Capela
rncbc(a)rncbc.org
11:45 p.m.
On Thu, Mar 29, 2012 at 10:23:30PM +0100, Rui Nuno Capela wrote:
otoh. now in particular, those GUI (file menu)
restrictions that NSM is
posing on applications is something i won't comply to any time soon, not
even later. so sorry. it's way too restrictive to me and my own
belongings. from what i read, applications must then be modified to run
in either of two or more awful different session modes eg. managed and
non-managed? for x-sake, as if we hadn't enough of that already... i am
so sorry again, but such a design won't fly much above the grass in my
lawn... it gives me the shivers o,O
You can't expect *any* session management system to work in
a reliable way without those rules. That's simple, basic, and
fairly easy to grok logic. The consequences of an app ignoring
this could be far more damaging than those of a user willingly
and knowingly keeping some data 'external'. And they will hit
the average user who doesn't even think about doing such things
and who expects his SM to just work.
Taking these rules into account is no big deal anyway. At least
not if your app has a clean control structure.
Again, the fact that the designer(s) of NSM have clearly stated
these rules is a sign that he/she/they know what is involved, and
has/have the courage to say this instead of going 'the easy way'.
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)
30 Mar
30 Mar
12:40 a.m.
On 03/29/2012 10:45 PM, Fons Adriaensen wrote:
On Thu, Mar 29, 2012 at 10:23:30PM +0100, Rui Nuno
Capela wrote:
well, you're probably right. i'm sure you are :)
only so like that he rules are telling me that i must code my
application to run in at least two different modes: one (NSM-)managed
and the other non-managed--often the original intended one
which one will it be? i ask: when will the user gets to run the
application in which mode? or is that telling us that all applications
should then be started under a "totalitarian" ruler as in NSM
auspices?... oops. just i read the interesting part cf.
http://non.tuxfamily.org/nsm/#n:1.1.1.7. Add Client, and yeah, really
scary now... f7u12!
i may say now that people will be always welcome to patch (my) software,
anytime ;)
cheers
--
rncbc aka Rui Nuno Capela
rncbc(a)rncbc.org
otoh. now in particular, those GUI (file menu)
restrictions that NSM is
posing on applications is something i won't comply to any time soon, not
even later. so sorry. it's way too restrictive to me and my own
belongings. from what i read, applications must then be modified to run
in either of two or more awful different session modes eg. managed and
non-managed? for x-sake, as if we hadn't enough of that already... i am
so sorry again, but such a design won't fly much above the grass in my
lawn... it gives me the shivers o,O
You can't expect *any* session management system to work in
a reliable way without those rules. That's simple, basic, and
fairly easy to grok logic. The consequences of an app ignoring
this could be far more damaging than those of a user willingly
and knowingly keeping some data 'external'. And they will hit
the average user who doesn't even think about doing such things
and who expects his SM to just work.
Taking these rules into account is no big deal anyway. At least
not if your app has a clean control structure.
Again, the fact that the designer(s) of NSM have clearly stated
these rules is a sign that he/she/they know what is involved, and
has/have the courage to say this instead of going 'the easy way'.
1:41 a.m.
On Thu, 2012-03-29 at 22:23 +0100, Rui Nuno Capela wrote:
now back to square one. to make that whole session
state, folder or
directory, as an archival portable one is, quite frankly and imho again,
utopian. nuff said :)
It's indeed utopian to think that some centralized special magic program
and protocol and file format and whatever else will actually get
universally adopted.
However, files and directories and links are anything but
unrealistically utopian. That's my point.
With all due respect, Emanuel, you can see here what happens when you
make a big complicated mess out of things and try to ram technology down
implementer's throats without justification: they simply reject it
outright as a utopian fantasy.
Achieving archival/etc is *trivial* without any fancy/annoying session
management crap whatsoever. If apps want to save in a way that prevents
it, they will always be able to, however if they do, there is *one*
simple rule that makes *all* the mentioned functionality possible that
has nothing to do with any specific session manager API/protocol/file
formats/etc whatsoever:
* All references to files outside the session directory must be a
symlink to that file
That's it. No APIS, no protocols, no session manager file stores, no
redundant data that may not match reality, no egregious rules. There's
not even a requirement for a session manager to be involved whatsoever,
if an app saves this way independently you can archive its sessions with
tar or whatever just the same. If you did want a fancy GUI archival
tool that reports what files are used and whatever else, you could write
one, and it wouldn't even depend on the session manager at all - and I
don't mean it would loosely depend on it by only using OSC or whatever,
I mean it would not depend on it *at all*, nor would it depend on any
file format[1]. All even vaguely common languages have everything
required in their standard library, right now. All of that Just
Works-eyness is because it's a simple idea, and doesn't use anything
that hasn't been baked in to the OS for literally decades. It doesn't
get much less unrealistically utopian than this.
Erecting some fantastic non-existent architecture to achieve, in one
special circumstance, what this simple rule does, is a folly doomed for
failure. To really distill it down, since we're on a "reality" trip:
you can either try to get people to adopt this convention, or you can
not have archivable/distributable sessions. There is no option C.
That said, if I'm overlooking something, do tell (i.e. why, exactly, is
this simple plan not sufficient?), because from where I'm standing it's
a real mystery why we are acting like this is so damned complicated.
It's not. At all.
-dr
[1] Try to sell any file format to this crowd and see how far you get...
3:29 a.m.
On Thu, Mar 29, 2012 at 4:40 PM, David Robillard <d(a)drobilla.net> wrote:
On Thu, 2012-03-29 at 22:23 +0100, Rui Nuno Capela
wrote:
I absolutely agree on this point. In fact, referring to external files
in this way is now on my TODO list for Non-DAW.
Currently, when you drag n' drop an external audio file into a Non-DAW
timeline (as opposed to recording it from within Non-DAW), the file
remains external with its path recorded
in the project's journal. Using a symlink for this would be better in
*at least* the following two ways:
1) Allows archiving scripts etc. to discover and import the external
source *without having to understand the Non-DAW journal format*
2) It would allow Non-DAW to import external sources *without having
to update (or break) any existing references*
I cannot imagine any argument that could propose that these are bad things.
If all Linux Audio software dealt with external references in this
way, archiving/export would be much less problematic.
However, I would also like to offer an interesting little statistic...
I, personally, have hundreds of projects representing terabytes of
data, and in all that I don't have a single project which refers to
anything external to its project directory. This is something that
only effects certain users who make extensive use of sound-clip or
sample libraries. Not people who just do plain old
recording/synthesis/mixing. So let's try not to make a mountain out of
a mole hill. What is the actual percentage of users who have
references to external files *and* a strong need to export their
sessions? I suspect that it is in fact a very low number.
Furthermore, in addition to the plain old symlinks, a truly robust
solution might also store e.g. SHA1 hashes of external files, so that
any mismatch is detectable.
now back to square one. to make that whole
session state, folder or
directory, as an archival portable one is, quite frankly and imho again,
utopian. nuff said :)
It's indeed utopian to think that some centralized special magic program
and protocol and file format and whatever else will actually get
universally adopted.
However, files and directories and links are anything but
unrealistically utopian. That's my point.
With all due respect, Emanuel, you can see here what happens when you
make a big complicated mess out of things and try to ram technology down
implementer's throats without justification: they simply reject it
outright as a utopian fantasy.
Achieving archival/etc is *trivial* without any fancy/annoying session
management crap whatsoever. If apps want to save in a way that prevents
it, they will always be able to, however if they do, there is *one*
simple rule that makes *all* the mentioned functionality possible that
has nothing to do with any specific session manager API/protocol/file
formats/etc whatsoever:
* All references to files outside the session directory must be a
symlink to that file
That's it. No APIS, no protocols, no session manager file stores, no
redundant data that may not match reality, no egregious rules. There's
not even a requirement for a session manager to be involved whatsoever,
if an app saves this way independently you can archive its sessions with
tar or whatever just the same. If you did want a fancy GUI archival
tool that reports what files are used and whatever else, you could write
one, and it wouldn't even depend on the session manager at all - and I
don't mean it would loosely depend on it by only using OSC or whatever,
I mean it would not depend on it *at all*, nor would it depend on any
file format[1]. All even vaguely common languages have everything
required in their standard library, right now. All of that Just
Works-eyness is because it's a simple idea, and doesn't use anything
that hasn't been baked in to the OS for literally decades. It doesn't
get much less unrealistically utopian than this.
Erecting some fantastic non-existent architecture to achieve, in one
special circumstance, what this simple rule does, is a folly doomed for
failure. To really distill it down, since we're on a "reality" trip:
you can either try to get people to adopt this convention, or you can
not have archivable/distributable sessions. There is no option C.
That said, if I'm overlooking something, do tell (i.e. why, exactly, is
this simple plan not sufficient?), because from where I'm standing it's
a real mystery why we are acting like this is so damned complicated.
It's not. At all.
-dr
[1] Try to sell any file format to this crowd and see how far you get...
4:05 a.m.
On Thu, 2012-03-29 at 18:29 -0700, J. Liles wrote:
[...]
Currently, when you drag n' drop an external audio
file into a Non-DAW
timeline (as opposed to recording it from within Non-DAW), the file
remains external with its path recorded
in the project's journal. Using a symlink for this would be better in
*at least* the following two ways:
1) Allows archiving scripts etc. to discover and import the external
source *without having to understand the Non-DAW journal format*
2) It would allow Non-DAW to import external sources *without having
to update (or break) any existing references*
I cannot imagine any argument that could propose that these are bad things.
Me neither. Well, not a good one, anyway :)
If all Linux Audio software dealt with external
references in this
way, archiving/export would be much less problematic.
Yep. I arrived at this via the experience of actually doing it - a
special magic solution seems feasible when you've got blinders on and
are just thinking about an SM program, but when you realize this can
cross-cut all the way from inside a generic library for loading standard
file(s) formats, through a plugin, through the host, through the session
manager, it's clear links are the only way. It can be hard enough to
get saving right *without* making the load all weird.
It's not a "YOU MUST DO THIS FOR NON SESSION MANAGER", it's a "you
should do this because it makes external file references manageable"
However, I would also like to offer an interesting
little statistic...
I, personally, have hundreds of projects representing terabytes of
data, and in all that I don't have a single project which refers to
anything external to its project directory. This is something that
only effects certain users who make extensive use of sound-clip or
sample libraries. Not people who just do plain old
recording/synthesis/mixing. So let's try not to make a mountain out of
a mole hill. What is the actual percentage of users who have
references to external files *and* a strong need to export their
sessions? I suspect that it is in fact a very low number.
Certainly true for recorded audio files, sharing those between programs
is pretty esoteric (and if you're doing it, as Fons says, you "know what
you're doing" anyway). In the greater scheme of things, though, using
sample banks and such is certainly not nichey.
When you do work with such things, it really sucks to not have a
reliable way to roll up a finished piece so it will actually work in the
future.
Plus, being able to easily share full sessions and collaborate and stuff
is cool and open sourcey :)
Furthermore, in addition to the plain old symlinks, a
truly robust
solution might also store e.g. SHA1 hashes of external files, so that
any mismatch is detectable.
Good idea. Certainly can't hurt to know, though computing a hash of
some files might be extremely expensive...
-dr
8:20 a.m.
From my user perspective - I use samples extensively,
however I care very
little about exporting projects.
I do care about preserving them, but I have a special folder called
Sessions where I save projects from all audio apps. Add my sample library
to that and I can preserve everything.
--
Louigi Verona
http://www.louigiverona.ru/
5:32 p.m.
Am 30. März 2012 03:29 schrieb J. Liles <malnourite(a)gmail.com>om>:
If all Linux Audio software dealt with external references in this
way, archiving/export would be much less problematic.
Finding a solution for externals, was the whole point of this discussion.
After all the many arguments, I'm now feeling too,
that symlinks are the right thing for NSM.
Thank you everyone, for participating.
Furthermore, in addition to the plain old symlinks, a
truly robust
solution might also store e.g. SHA1 hashes of external files, so that
any mismatch is detectable.
Interesting point.
--
E.R.
9:09 p.m.
On Fri, Mar 30, 2012 at 05:31:57PM +0200, Emanuel Rumpf wrote:
Am 30. März 2012 03:29 schrieb J. Liles
<malnourite(a)gmail.com>om>:
Would there be anything against using hard links?
Isn't it nice that you can delete the original files,
knowing that that are save when used in a session.
Portability would be a problem of course,
and deleting files might become more difficult
then you would like.
But if you would be able to control this with the
session manager, it might be a desirable feature.
lieven
If all Linux Audio software dealt with external references in this
way, archiving/export would be much less problematic.
Finding a solution for externals, was the whole point of this discussion.
After all the many arguments, I'm now feeling too,
that symlinks are the right thing for NSM.
Thank you everyone, for participating.
Furthermore, in addition to the plain old
symlinks, a truly robust
solution might also store e.g. SHA1 hashes of external files, so that
any mismatch is detectable.
Interesting point.
10:53 p.m.
On Fri, Mar 30, 2012 at 09:07:07PM +0200, Lieven Moors wrote:
Would there be anything against using hard links?
A hard link makes the file pointed to part of the session
directory, just as moving or copying the file would. There
is no difference between a hard link and the original - both
are hard links. So such a file is no longer recognisable as
'external' and the choice of including it or not in an archive
or a copy no longer exists. That defeats the original purpose
which is to have this choice.
Apart from that, hard links are possible only within the
same file system. There are good reasons to keep big audio
files etc. on a separate one. That in itself is a motivation
for 'external' data in first place. I don't want hundreds of
Gigabytes of audio files on my /home partition, let alone in
my home directory.
Ardour makes this mistake of creating hard links if by chance
it happens to be possible, and even if the user explicitly
expressed his/her choice to keep a file out of the session
directory. It's inconsistent and unreliable behaviour and
only creates problems.
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)
11:14 p.m.
Personally I prefer Ardour's behavior myself. I do keep my samples on an
external drive, but in the end the ability to maintain a self-contained
session for portability purposes is important to me. But to each their own.
Seablade
On Fri, Mar 30, 2012 at 4:53 PM, Fons Adriaensen <fons(a)linuxaudio.org>wrote;wrote:
On Fri, Mar 30, 2012 at 09:07:07PM +0200, Lieven Moors
wrote:
Would there be anything against using hard links?
A hard link makes the file pointed to part of the session
directory, just as moving or copying the file would. There
is no difference between a hard link and the original - both
are hard links. So such a file is no longer recognisable as
'external' and the choice of including it or not in an archive
or a copy no longer exists. That defeats the original purpose
which is to have this choice.
Apart from that, hard links are possible only within the
same file system. There are good reasons to keep big audio
files etc. on a separate one. That in itself is a motivation
for 'external' data in first place. I don't want hundreds of
Gigabytes of audio files on my /home partition, let alone in
my home directory.
Ardour makes this mistake of creating hard links if by chance
it happens to be possible, and even if the user explicitly
expressed his/her choice to keep a file out of the session
directory. It's inconsistent and unreliable behaviour and
only creates problems.
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)
_______________________________________________
Linux-audio-dev mailing list
Linux-audio-dev(a)lists.linuxaudio.org
http://lists.linuxaudio.org/listinfo/linux-audio-dev
11:27 p.m.
On Fri, Mar 30, 2012 at 05:14:50PM -0400, Thomas Vecchione wrote:
Personally I prefer Ardour's behavior myself. I
do keep my samples on an
external drive, but in the end the ability to maintain a self-contained
session for portability purposes is important to me.
You always have that ability, even if you allow others not
to use it. And if you don't allow that, as Ardour does when
by chance it can, it's no longer an 'ability' but something
forced onto you.
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)
11:42 p.m.
Not awake enough to debate here, but my memory and your's of Ardour's
behavior doesn't seem to be matching up I don't believe. But I ened more
sleep before I really dig into that.
Seablade
On Fri, Mar 30, 2012 at 5:27 PM, Fons Adriaensen <fons(a)linuxaudio.org>wrote;wrote:
On Fri, Mar 30, 2012 at 05:14:50PM -0400, Thomas
Vecchione wrote:
Personally I prefer Ardour's behavior myself.
I do keep my samples on an
external drive, but in the end the ability to maintain a self-contained
session for portability purposes is important to me.
You always have that ability, even if you allow others not
to use it. And if you don't allow that, as Ardour does when
by chance it can, it's no longer an 'ability' but something
forced onto you.
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)
31 Mar
31 Mar
12:19 a.m.
On 03/30/2012 10:27 PM, Fons Adriaensen wrote:
On Fri, Mar 30, 2012 at 05:14:50PM -0400, Thomas
Vecchione wrote:
On 03/30/2012 10:14 PM, Thomas Vecchione wrote:
Personally I prefer Ardour's behavior myself.
I do keep my samples on an
external drive, but in the end the ability to maintain a self-contained
session for portability purposes is important to me.
You always have that ability, even if you allow others not
to use it. And if you don't allow that, as Ardour does when
by chance it can, it's no longer an 'ability' but something
forced onto you.
Personally I prefer Ardour's behavior myself. I
do keep my samples on
an external drive, but in the end the ability to maintain a
self-contained session for portability purposes is important to me. But
to each their own.
aha. this discussion may still be in flux and i believe it's all about
session management and not whether each application native behavior is
wrong or right. aham ;)
but ntl. let me see,
ardour stores a world under its own session directory on a per session
basis. you may call it that way or project, song, collection, whatever
is more appropriate. check.
otoh, qtractor doesn't do that but you (the human being) are in control,
remenber? it's your choice anyway. and there's an exit option: you may
chose anytime to save the whole (qtractor) session in a zip file
container. in case you don't know, this is a pretty regular zip file
(besides having an esquisite .qtz file suffix), just like
(open|libre)office and .jar files are and, as far as my knowledge goes,
are pretty portable stuff ;)
again, the subject at hand is about session management and whether huge
or small "external" files are to get reported to the SM from
applications in its way to collect, map(*) and possibly massage--my
nomenclature here--a managed-session-"repertoire".
(*) map: hashes, symlinks, hardlinks or whatever--it's a SM
implementation detail anyhow
otherwise, i may be way off base (which is not that rare:^))
cheers
--
rncbc aka Rui Nuno Capela
rncbc(a)rncbc.org
30 Mar
30 Mar
11:57 p.m.
On Fri, 2012-03-30 at 20:53 +0000, Fons Adriaensen wrote:
On Fri, Mar 30, 2012 at 09:07:07PM +0200, Lieven Moors
wrote:
> Would there be anything against using hard links?
Nedko mentioned this idea on IRC as well...
Apart from that, hard links are possible only within
the
same file system.
... but that's definitely a show-stopper
-dr
31 Mar
31 Mar
12:13 a.m.
On Fri, Mar 30, 2012 at 08:53:26PM +0000, Fons Adriaensen wrote:
On Fri, Mar 30, 2012 at 09:07:07PM +0200, Lieven Moors
wrote:
But if the hardlinks would be in an 'external files' directory
managed by the session manager only, you would still have
that choice when you make the archive.
Though I agree this is only based on convention...
Would there be anything against using hard links?
A hard link makes the file pointed to part of the session
directory, just as moving or copying the file would. There
is no difference between a hard link and the original - both
are hard links. So such a file is no longer recognisable as
'external' and the choice of including it or not in an archive
or a copy no longer exists. That defeats the original purpose
which is to have this choice.
Apart from that, hard links are possible only within the
same file system. There are good reasons to keep big audio
files etc. on a separate one. That in itself is a motivation
for 'external' data in first place. I don't want hundreds of
Gigabytes of audio files on my /home partition, let alone in
my home directory.
You could make a symbolic link to a directory with hardlinks
managed by the SM. Then the SM would spread like a giant octopus ;-)
Well, only kidding...
I agree that the arguments against them are very strong.
But I must say, there is something seductive about them.
If you want to delete the originals without the fear of destroying
your sessions, go ahead. If you want to cleanup a session, tell
the session manager to delete the hardlinks for that session,
and delete the originals yourself.
If you want an archive, tell the SM to copy all the 'external files'
directories. Session management can exist in parallel with normal
filesystem activity.
And most importantly, never worry about those dreadful broken links...
But still I agree, on a more fundametal level, that hardlinks
are a bad idea.
lieven
30 Mar
30 Mar
3:48 a.m.
On Thu, Mar 29, 2012 at 2:23 PM, Rui Nuno Capela <rncbc(a)rncbc.org> wrote:
indeed. real life that is :)
as far as qtractor is, all media content files, be that either audio or midi
types, are ALL external files. it's true that some are created and edited
under qtractor direct control, but they are all external. no exceptions.
otoh, a qtractor session file (xml) is a listing or a map of references
(links, paths, whatever) to those external files as they are in the
file-system. but no, never symlinks.
qtractor's "session directory" (aka. its own "session folder") is
just an
user preference, a location where all newly created media files (again,
audio or midi, recorded or scratch) are located first time they get into
existence--do not ever confuse this with any portable session directory or
folder in any way. in fact, you get serious trouble if you do so. although
there's this qtractor session archive/zip bundle file format (.qtz) which
serves that particular purpose but as an option and convenience (just like
an independent, moveable, self-contained zip-folder)
Are you saying that qtractor stores all audio and MIDI files that it
creates in one central folder? That seems quite bizarre. What is the
justification for doing that? How does it benefit the user?
external or not, all-media content file
"awareness" from a foreseeable
session management entity, being that big or small, central or not, is, if
you ask me, utopian.
It isn't utopian if one follows David's scheme. A file is a file is a
file (is a symlink). Instead of storing a path to the external file,
create an internal symlink to it and store the path to the symlink
instead. Simple and it allows *any* tool to find *all* of the external
data referred to by a session.
sure, it would certainly be a really-good-thing(tm) to
make a session
archive portable across file-systems, machine architectures or platforms,
users, networks, you name it... it really seems like an
all-in-one/knows-it-all "goddess" application if you ask me. yuck! a
pipe-dream if i reckon one :)
Well, I certainly agree that the actual need for this kind of
functionality is probably being overestimated.
otoh. now in particular, those GUI (file menu)
restrictions that NSM is
posing on applications is something i won't comply to any time soon, not
even later. so sorry. it's way too restrictive to me and my own belongings.
from what i read, applications must then be modified to run in either of two
or more awful different session modes eg. managed and non-managed? for
x-sake, as if we hadn't enough of that already... i am so sorry again, but
such a design won't fly much above the grass in my lawn... it gives me the
shivers o,O
but that maybe just a first glance pov. don't take it final
The point of those guidelines is to allow users to know *exactly* what
behavior they can expect.
The chief difficulty I had with implementing LASH support in programs
was that there was no answer as to what 'Save', 'Open', 'New',
etc.
should do when running under LASH. Left, as is, the effect of these
operations would vary depending on how individual applications store
their state (whether fully in RAM, in a fixed location on disk, etc.).
This scenario is an absolute nightmare for both implementers and
users. If following a few simple rules to disable certain menu options
is enough to remove this ambiguity entirely, then why is that so hard
for you to accept? Do you *want* to make things ambiguous and
impossible to predict? I know I don't. The rules are not there to be
draconian and imposing--They are there to allow people to have
confidence in what running under session management means regarding
where their data is stored.
however ;) imho, the SM should only know about
application instances that
are part of the so-called "session", their state of which only each
application knows about their own, or so i believe, _and_ the means to
recall that collected set of states later on. if that state is described by
a set of files, so be it. let's name it state-data-files, or just call it
_internal_ files perhaps?
I'm not sure what you mean, but to me it is obvious that only programs
which are connected to the session manager are subject to its control.
more. a session manager (or its protocol spec) should
not touch any, any at
all, of the external (media content?) files that each application are
possibly working on during their life span.
Of course it shouldn't.
under the so called session's -folder (or
-directory, if you prefer) there
should be _only_ stored the state-data-files that pertain to each
participant application. you guess it right, that's the state of each
participating application instance at the time of the eventual
"save-this-session-now!" command gets issued (a-la snapshot). and add to
that the inter-connection state file(s) as it will be certainly the job of
the SM to gather too. jack-session does this kind of stuff.
That's the idea... Except that in NSM, an application can store data
in its per-application area of the session *before* the first 'save'
command is ever delivered. This was a vital requirement of Non-DAW,
and, I believe, of any DAW like program.
now back to square one. to make that whole session
state, folder or
directory, as an archival portable one is, quite frankly and imho again,
utopian. nuff said :) but (oh no, not again), as a clever guy once said, the
impossible turns out to be possible when there's someone foolish enough to
do it ;)
I think that David has given a very convincing argument that it is not
only possible, but in fact a lot easier than people think.
10:03 a.m.
On 03/30/2012 03:48 AM, J. Liles wrote:
The point of those guidelines is to allow users to
know*exactly* what
behavior they can expect.
The chief difficulty I had with implementing LASH support in programs
was that there was no answer as to what 'Save', 'Open', 'New',
etc.
should do when running under LASH. Left, as is, the effect of these
operations would vary depending on how individual applications store
their state (whether fully in RAM, in a fixed location on disk, etc.).
This scenario is an absolute nightmare for both implementers and
users. If following a few simple rules to disable certain menu options
is enough to remove this ambiguity entirely, then why is that so hard
for you to accept? Do you*want* to make things ambiguous and
impossible to predict? I know I don't. The rules are not there to be
draconian and imposing--They are there to allow people to have
confidence in what running under session management means regarding
where their data is stored.
Makes me wonder about JackSession. Does it have the same problem here
compared to LASH?
\r
11 a.m.
On 03/30/2012 02:48 AM, J. Liles wrote:
given the "bizarre" behavior re. qtractor's session directory semantics,
this will work iif the SM creates its own session directory, on a per
client basis for instance, and then yes, clients are then asked to store
in there all their state data files and possibly the symlinks to all
their external data, under a managed session context.
the point here is that the client normal working directory (ie. its own
session directory) may not be the same as the SM's session directory.
nb. in the "bizarre" case of qtractor it's a must ;)
fair enough.
--
rncbc aka Rui Nuno Capela
rncbc(a)rncbc.org
On Thu, Mar 29, 2012 at 2:23 PM, Rui Nuno
Capela<rncbc(a)rncbc.org> wrote:
not quite. the qtractor session directory is a loose
session/project/song property than may be changed anytime by the user
and, most bizarre yet, it's not unique so it can be shared by more than
one qtractor session, project or song. it's more like a common place
than a central one, although, if the user so desires, it can remain the
same for many or all times.
what i am saying is that qtractor's session directory MAY NOT be the
same where its state data file gets eventually stored, be that from the
gui file menu or under SM control
indeed. real life that is :)
as far as qtractor is, all media content files, be that either audio or midi
types, are ALL external files. it's true that some are created and edited
under qtractor direct control, but they are all external. no exceptions.
otoh, a qtractor session file (xml) is a listing or a map of references
(links, paths, whatever) to those external files as they are in the
file-system. but no, never symlinks.
qtractor's "session directory" (aka. its own "session folder") is
just an
user preference, a location where all newly created media files (again,
audio or midi, recorded or scratch) are located first time they get into
existence--do not ever confuse this with any portable session directory or
folder in any way. in fact, you get serious trouble if you do so. although
there's this qtractor session archive/zip bundle file format (.qtz) which
serves that particular purpose but as an option and convenience (just like
an independent, moveable, self-contained zip-folder)
Are you saying that qtractor stores all audio and MIDI files that it
creates in one central folder? That seems quite bizarre. What is the
justification for doing that? How does it benefit the user?
external or
not, all-media content file "awareness" from a foreseeable
session management entity, being that big or small, central or not, is, if
you ask me, utopian.
It isn't utopian if one follows David's scheme. A file is a file is a
file (is a symlink). Instead of storing a path to the external file,
create an internal symlink to it and store the path to the symlink
instead. Simple and it allows *any* tool to find *all* of the external
data referred to by a session.
sure, it would
certainly be a really-good-thing(tm) to make a session
archive portable across file-systems, machine architectures or platforms,
users, networks, you name it... it really seems like an
all-in-one/knows-it-all "goddess" application if you ask me. yuck! a
pipe-dream if i reckon one :)
Well, I certainly agree that the actual need for this kind of
functionality is probably being overestimated.
otoh. now in particular, those GUI (file menu)
restrictions that NSM is
posing on applications is something i won't comply to any time soon, not
even later. so sorry. it's way too restrictive to me and my own belongings.
from what i read, applications must then be modified to run in either of two
or more awful different session modes eg. managed and non-managed? for
x-sake, as if we hadn't enough of that already... i am so sorry again, but
such a design won't fly much above the grass in my lawn... it gives me the
shivers o,O
but that maybe just a first glance pov. don't take it final
The point of those guidelines is to allow users to know *exactly* what
behavior they can expect.
The chief difficulty I had with implementing LASH support in programs
was that there was no answer as to what 'Save', 'Open', 'New',
etc.
should do when running under LASH. Left, as is, the effect of these
operations would vary depending on how individual applications store
their state (whether fully in RAM, in a fixed location on disk, etc.).
This scenario is an absolute nightmare for both implementers and
users. If following a few simple rules to disable certain menu options
is enough to remove this ambiguity entirely, then why is that so hard
for you to accept? Do you *want* to make things ambiguous and
impossible to predict? I know I don't. The rules are not there to be
draconian and imposing--They are there to allow people to have
confidence in what running under session management means regarding
where their data is stored.
however ;) imho, the SM should only know about
application instances that
are part of the so-called "session", their state of which only each
application knows about their own, or so i believe, _and_ the means to
recall that collected set of states later on. if that state is described by
a set of files, so be it. let's name it state-data-files, or just call it
_internal_ files perhaps?
I'm not sure what you mean, but to me it is obvious that only programs
which are connected to the session manager are subject to its control.
more. a session manager (or its protocol spec)
should not touch any, any at
all, of the external (media content?) files that each application are
possibly working on during their life span.
Of course it shouldn't.
under the so called session's -folder (or
-directory, if you prefer) there
should be _only_ stored the state-data-files that pertain to each
participant application. you guess it right, that's the state of each
participating application instance at the time of the eventual
"save-this-session-now!" command gets issued (a-la snapshot). and add to
that the inter-connection state file(s) as it will be certainly the job of
the SM to gather too. jack-session does this kind of stuff.
That's the idea... Except that in NSM, an application can store data
in its per-application area of the session *before* the first 'save'
command is ever delivered. This was a vital requirement of Non-DAW,
and, I believe, of any DAW like program.
now back to square one. to make that whole
session state, folder or
directory, as an archival portable one is, quite frankly and imho again,
utopian. nuff said :) but (oh no, not again), as a clever guy once said, the
impossible turns out to be possible when there's someone foolish enough to
do it ;)
I think that David has given a very convincing argument that it is not
only possible, but in fact a lot easier than people think. 
12:27 p.m.
re: the "central" media location - in rui's defense i'd like to point
out that it took cubase more than 10 years to move away from something
fairly close to his model.
2 Apr
2 Apr
6:12 p.m.
On 03/30/2012 12:27 PM, Paul Davis wrote:
re: the "central" media location - in
rui's defense i'd like to point
out that it took cubase more than 10 years to move away from something
fairly close to his model.
Ok, that will be 5 yrs for Rui then ;)
Serious though. What does this mean for Qtractor and NSM in theory?
Qtractor can't apply to the strict session saving rules of NSM atm and
not in the near future? If so, is there a solution for this from the
perspective of Qtractor and NSM?
Are there other applications with this same 'problem'?
Best regards,
\r
7:17 p.m.
On Mon, Apr 2, 2012 at 9:11 AM, rosea.grammostola
<rosea.grammostola(a)gmail.com> wrote:
On 03/30/2012 12:27 PM, Paul Davis wrote:
It wouldn't be a problem if qtractor either kept all new media in its
per-application area of the session directory when running under NSM
or at least symlinked to the external files. There is precedent for
applications using completely different project formats when under SM
(for example, Yoshimi's ".state" files [although that functionality
appears to be broken in the stable release of yoshimi]). A session is
something that applications /participate/ in, and participation means
having to do some things differently in order to cooperate with the
session manager for the user's benefit, so IMHO none of this is asking
too much.
And, anyway, it's not /really/ a problem in practice until you want to
trasnport a session, and in that case you'd just have to follow
whatever qtractor's procedure is for doing that.
It's an interesting point and one that I'll need to state explicitly
in the next version of the API.
re: the "central" media location - in rui's defense i'd like to point
out that it took cubase more than 10 years to move away from something
fairly close to his model.
Ok, that will be 5 yrs for Rui then ;)
Serious though. What does this mean for Qtractor and NSM in theory? Qtractor can't apply to the strict session saving
rules of NSM atm and not
in the near future? If so, is there a solution for this from the perspective
of Qtractor and NSM?
Are there other applications with this same 'problem'?
There are probably a few. I think Freewheeling also tries to store all
recorded loops in a central place in the users home directory. It's a
pretty unusual thing to do though and the truth is that the vast
majority of applications don't have heavy state and keep all project
information in memory and save/restore it from a single file. Anyway,
from my perspective, correcting the problem is as simple as adding a
rule to the NSM API that states:
* When connected to a session, the client *MUST* store all new media
(recorded audio, etc.) related to the open project in the project path
provided by the `open` message.
I can't imagine why Rui or anyone else would have a problem with this,
as it is exactly equivalent to the user saying "Please store my
precious data somewhere predictable that I have predefined instead of
in whatever random place the application developer thought would be
good."
8:29 p.m.
Am 2. April 2012 19:17 schrieb J. Liles <malnourite(a)gmail.com>om>:
Anyway,
from my perspective, correcting the problem is as simple as adding a
rule to the NSM API that states:
* When connected to a session, the client *MUST* store all new media
(recorded audio, etc.) related to the open project in the project path
provided by the `open` message.
I thought - that's what we would not want: store large files in the
session dir !?
....because duplicating a session should stay a "light" and fast process.
That is, why I had been proposing an "nsm-large-files" directory
(outside of the session-folder), for those,
but actually, it doesn't matter, _where_ NSM-clients store their
"large-files",
as long as they create symlinks for them in the session folder.
(maybe the sub-directory for symlinks should be defined as part of the
API. proposition: "external-file-links").
-- -- -- --
Remember my definitions:
What is a large-file ?
- every (larger) file, that is not required to immediately be
copied if, a session is cloned.
- every file, where a reference is enough in the first place
What is NO-large-file ?
- data that is required to access large-files (references, symlinks)
- that is lightweight (~ below 1MB) (some config-values)
- has to be read by the SM to initialize the client
-- -- -- --
I can't imagine why Rui or anyone else would have
a problem with this,
as it is exactly equivalent to the user saying
"Please store my
precious data somewhere predictable that I have predefined instead of
in whatever random place the application developer thought would be
good."
My exact intention.
Regards, Emanuel
--
E.R.
9:23 p.m.
On Mon, Apr 2, 2012 at 11:29 AM, Emanuel Rumpf <xbran(a)web.de> wrote:
I thought - that's what we would not want: store
large files in the
session dir !?
....because duplicating a session should stay a "light" and fast process.
Personally, I'm fine with having large files in my session
directories. In fact, that's exactly where I want them. Why would one
one to duplicate a session with a lot of pre-recorded audio? And,
anyway, this could be made to work by just storing that common audio
wherever you want and making 'external' references to it in the
session (and hopefully the application involved uses the symlink
technique we've discussed for referring to external files)--all
without the SM having to know anything about it.
That is, why I had been proposing an
"nsm-large-files" directory
(outside of the session-folder), for those,
but actually, it doesn't matter, _where_ NSM-clients store their
"large-files",
as long as they create symlinks for them in the session folder.
Right. As long as there are symlinks it's fine, except that I think it
should be the user deciding where things are stored rather than
individual applications.
Remember, you can always write a simple shell script that moves WAVE
files etc. into a central location outside of the session directories
and replaces them with symlinks. Again, this would be the user
deciding what to do and the SM or the application doesn't have to know
anything about it.
I think this is very much a corner case anyway. Normally, one wants
all the project data and media to be stored on the same filesystem, as
close together as possible, and doesn't care about being able to
duplicate a session with gigabytes of audio data (because... why are
you doing that anyway and why are you doing it so frequently that just
creating the symlinks yourself is too much trouble). Unless the use
case is very compelling, it's hard to justify adding any complexity or
requirements to either the SM or the client applications. Remember,
this is Unix--we don't have to stuff all the functionality into one
tool.
10:05 p.m.
Am 2. April 2012 21:22 schrieb J. Liles <malnourite(a)gmail.com>om>:
Personally, I'm fine with having large files in my session
directories. In fact, that's exactly where I want them.
Why would one
want to duplicate a session with a lot of pre-recorded audio?
Maybe with recorded
audio, you wouldn't
- although maybe you would (see below).
If you work with samples, OTHO, why would you
want the (same!) samples to be stored in the sessions folder
and even in duplications ?
To waste some space ?
And,
anyway, this could be made to work by just storing that common audio
wherever you want and making 'external' references to it in the
session
That was our conclusion for using symlinks.
The clients would be advised, to create them
in "../nsm-session/external-file-links/"
(and hopefully the application involved uses the
symlink
technique we've discussed for referring to external files)--all
without the SM having to know anything about it.
right
..., except that I think it
should be the user deciding where things are stored rather than
individual applications.
Most applications allow that anyway, and if not - it would not hurt much
to change this.
Remember, you can always write a simple shell script
We can always create shell scripts for anything,
but aren't we talking about some kind of "management" !?
NSM has some nice rules already, to make things behave smooth.
Now add a few sensible rules, to make sure that
audio-file management works equally well.
These are really very simple points, I say.
example:
- clients MUST create symlinks for all external files used - in the
directory "../session/external-file-links/"
- clients are ADVISED to store large-files in "/nsm/large-files/" (and
create symlinks for them as in previous point)
I think this is very much a corner case anyway.
I think no, but very much depends on personal work-flow.
I use to do different Versions of _the same_ project,
with some minor or major differences.
So my workflow would be:
- create a session
- if happy with a state, duplicate
- continue work with the duplicate.
since many/most files stay the same, there is no reason
to copy the files over different session directories.
--
E.R.
3 Apr
3 Apr
8:59 a.m.
Am 2. April 2012 20:05 schrieb Emanuel Rumpf <xbran(a)web.de>de>:
NSM has some nice rules already, to make things behave smooth.
Now add a few sensible rules, to make sure that
audio-file management works equally well.
These are really very simple points, I say.
Proposing a few simple non-intrusive rules:
- clients MUST create symlinks for all external files used - in the
directory "nsm/ sessions/ mysession/ myapp/ external-file-links/"
- clients are ADVISED to store large-files in "/nsm/ large-files/"
(and create symlinks for them as in previous point)
- all NSM-clients treat all files, as if they were inside their
session-directory
(means: they access all external files over the symlinks)
- if a file must be external, apps create a symlink in
their external-file-links/ folder and access the file through that link
Without obtruding much on the application, nor on the SM
(clients just create the symlinks and use them),
this would - for the first version :
- offer accaptable integrity.
- ensure all files are either referenced-from or contained-in the session dir
- ensure, if a file or link in the session-dir is modified or replaced,
the new version is used by the nsm-client
--
E.R.
11:21 a.m.
On Tue, 3 Apr 2012 07:04:55 +0000
Emanuel Rumpf <xbran(a)web.de> wrote many things.
Emanuel,
why don't you write your own Session Manager (Protocol)?
You seem to be very knowledgable.
Nils
3:44 p.m.
Am 3. April 2012 09:21 schrieb Nils <list(a)nilsgey.de>de>:
why don't you write your own Session Manager (Protocol)?
You seem to be very knowledgable.
I did not write a whole sequencer app yet, that's why I don't call
that utopian ;)
But Riu did.
- I'm not able to do it better than NSM
- we do not need 20 SMs, just one, that does it
- NSM is here already, and is usable and is great
There are many reasons to NOT write a SM, such
as endless discussions on LAD about f..ng details ....
I'm glad, some very brave devs nevertheless did.
--
E.R.
4:18 p.m.
Guys, is there any info on JACK Session state? What apps are supported? How
to use?
--
Louigi Verona
http://www.louigiverona.ru/
4:22 p.m.
On 04/03/2012 04:18 PM, Louigi Verona wrote:
Guys, is there any info on JACK Session state? What
apps are supported?
How to use?
http://tangostudio.tuxfamily.org/en/documentations/jacksession
2 Apr
2 Apr
8:29 p.m.
On 04/02/2012 05:11 PM, rosea.grammostola wrote:
On 03/30/2012 12:27 PM, Paul Davis wrote:
it's just unlikely, not that it won't apply to the rules :)
for instance, qtractor doesn't apply to the jack-session and ladish
rules on 100% but it works on both as long as you don't EVER mix
qtractor sessions directories with SM's session directories. that is, it
is always possible to use qtractor's gui file menu save/save as... to
replace any SM session directory but not recommended though, ever.
depending on "unpredictable circumstances", one will sooner or later
break either or both session states (qtractor session and/or the SM's
one) when you try to load any later on
point is, in qtractor terms at least, saving a managed-session takes a
different and specific code path. read that like a managed-session save
operation is kind of a instant snapshot, which doesn't even change the
current qtractor session title, path or dirty flag at all, if any
nb. all this applies whether the "external files symlinking" are
implemented or not (will that be an option or shall be mandatory by SM
protocol design?); it's about session state integrity and not session
directory "centrality" or "portability"
in conclusion. qtractor may be always made to work as a NSM client.
that's orthogonal to the "session directory dilemma", which i think this
is what Paul's referring to
alas, all is just not *my* top priority atm. meanwhile, any patch would
be welcome, of course ;)
byee
--
rncbc aka Rui Nuno Capela
rncbc(a)rncbc.org
re: the "central" media location - in
rui's defense i'd like to point
out that it took cubase more than 10 years to move away from something
fairly close to his model.
Ok, that will be 5 yrs for Rui then ;)
Serious though. What does this mean for Qtractor and NSM in theory?
Qtractor can't apply to the strict session saving rules of NSM atm and
not in the near future? If so, is there a solution for this from the
perspective of Qtractor and NSM? 
9:07 p.m.
Do all target
filesystems support symbolic links?
yeah ? what would happen to the links, if one copied the session
folder to his/her fat32 usb-stick ?
simply don't !! ?
or de-reference...
9:11 p.m.
On Mon, Apr 2, 2012 at 12:07 PM, Paul Giblock <pgiblox(a)gmail.com> wrote:
I didn't necessarily mean for transport or
archival. I imagine "just
dereference it" is one of the motivations for links in the first place. I
was more concerned about windows users, or people with large external
(fat32) drives who wish to use this filesystem for their live session
storage. I just checked and NTFS at least supports symlinks.
Anyone attempting to store their production audio sessions on a fat32
filesystem is certifiably insane anyway...
9:34 p.m.
On Mon, Apr 2, 2012 at 3:11 PM, J. Liles <malnourite(a)gmail.com> wrote:
On Mon, Apr 2, 2012 at 12:07 PM, Paul Giblock
<pgiblox(a)gmail.com> wrote:
Can't agree with that. USB Thumb Drives for instance are still one of the
most common ways to transport sessions and other data and are often
formatted FAT32 for interoperability purposes.
Seablade
I didn't necessarily mean for transport or
archival. I imagine "just
dereference it" is one of the motivations for links in the first place.
I
was more concerned about windows users, or people
with large external
(fat32) drives who wish to use this filesystem for their live session
storage. I just checked and NTFS at least supports symlinks.
Anyone attempting to store their production audio sessions on a fat32
filesystem is certifiably insane anyway...
9:48 p.m.
Can't agree with that. USB Thumb Drives for
instance are still one of the
most common ways to transport sessions and other data and are often
formatted FAT32 for interoperability purposes.
Seablade
Luckily tar files do support symlinks. Some folks even create a ext2
fs formatted loopback file on the fat32 partition.
Of course it's a problem if you try to extract that tar file onto a fat32.
Cheers,
Tim
10:22 p.m.
A new thought:
Lets say we did store the session as tar.gz,
and we de-referenced the symlinks.
Means: We have all files related to the session th the tar.gz.
So far, so good.
Now we re-import the session to NSM:
We extract that tar.gz in the NSM sessions-folder.
Note: instead of symlinks we have now real files in the symlinks
directory (because we de-referenced before creating the tar.gz).
Real files should not go to the symlinks directory.
But we could have a simple script, to move these files
to the "nsm-large-files/" folder and re-create the symlinks.
Now we should have a state very similar to where we began.
(exception: we did not restore the file-paths we've had originally,
but symlinked to the nsm-large-files folder instead)
I think this is acceptable
- the session stayed valid at least.
--
E.R.
3 Apr
3 Apr
7:49 a.m.
On Thu, Mar 29, 2012 at 03:44:17PM +0200, Emanuel Rumpf wrote:
Back to life - back to reality
1. We start qtractor as part of a session, create some midi-tracks,
include some external wav-files.
Should the SM "know" about these external files, as I suggested ?
(Allowing the user to find out basic info about it. )
Or leave it completely to qtractor ?
As a developer of limited abilities, I would like the bar
of integrating Nama with other programs to be as low
as possible. :-)
As I understand it, the primary motivation for a session
manager is to be able to save and restore the state of an
audio project[1] that consists of multiple interconnected
programs running on a multiprocessing Linux system.
In other words, the minimum capability sufficient to be
useful would be some sort of checkpointing mechanism.
A secondary goal, discussed extensively here, is that it
would be nice to be able to copy a session or export a
session. This is where all the contentious issues with
handling filesystem objects comes up.
The latter goal should be optional, IMO, rather than required.
Managing files, seems relatively simple in the case of
of Nama, which is a purely non-destructive editor,
Once recorded, Nama *never* modifies or deletes audio files,
so these files don't need to be involved in checkpointing.
(If a user wants to delete WAV files associated with a bad
take, that is her responsibility.)
All the mutable state information for a project is
serialized and stored as JSON. State files for a project
can be named. In future they will be placed under
VCS to add branching (and possibly
merging) abilities.
If Nama (or Qtractor, Ardour, etc.) is to clone a project,
that concern is internal to the app: I wouldn't expect a
session manager to know it should link the files in the .wav
directory and copy the other files. (Straight copying of
files might not even be appropriate if those files are
under a VCS.)
2. We record a new file in qtractor. Where would it be
stored ?
Should the SM "know" about this file ?
There could be advantages to knowing, however if the aim is
to integrate multiple apps, it will be simpler if the SM and
app only need to communicate the project name and checkpoint
ID. (It gets more complicated than that since the SM
will need to know that Nama should be responsible for
configuring Ecasound and for either connecting Ecasound to
JACK clients or reporting when Ecasound is ready to be
connected.)
3. A session is duplicated.
How does the SM handle the recorded and external files?
Branching a project (assuming VCS, which I believe is the
future :-) would be cheaper than duplicating a project.
If the SM wants an app to duplicate a project, I would
expect the SM to ask the app to create a new project as a
copy of an existing project. Whether the app chooses to use
symlinking, hardlinking, copying files or branching under a
VCS seems to be the app's internal concern.
4. A session is exported.
Jonathan said, current practice is a simple directory copy.
Well ! Simple and not bad at all.
But what about the external files ?
Just make some symlinks for them ?
The state files and audio files for a Nama project
are in a single directory, easy to copy.
However the .namarc config file specifying the ALSA devices
to be used, the audio recording format, the mixdown format
and many other program behaviors currently exists only
in $HOME.
Even if this file were linked or copied into the project
directory, it may not be seamlessly portable to the
audio hardware and configuration of another system.
If the process of exporting cannot be defined unambiguously,
or involves vast complexity, we might be more successful by
initially restricting our *first* steps to checkpointing
functionality.
Minimizing complexity seems important, as
the Linux audio world has already gone through
several session management APIs, with none yet
widely adopted.
Regards,
Joel
1. I use the terms "project" and "session" interchangeably.
--
E.R.
--
Joel Roth
11:05 a.m.
On 03.04.2012 06:49, Joel Roth wrote:
On Thu, Mar 29, 2012 at 03:44:17PM +0200, Emanuel
Rumpf wrote:
<snip>
Back to life - back to reality
1. We start qtractor as part of a session, create some midi-tracks,
include some external wav-files.
Should the SM "know" about these external files, as I suggested ?
(Allowing the user to find out basic info about it. )
Or leave it completely to qtractor ?
As I understand it, the primary motivation for a session
manager is to be able to save and restore the state of an
audio project[1] that consists of multiple interconnected
programs running on a multiprocessing Linux system.
In other words, the minimum capability sufficient to be
useful would be some sort of checkpointing mechanism.
A secondary goal, discussed extensively here, is that it
would be nice to be able to copy a session or export a
session. This is where all the contentious issues with
handling filesystem objects comes up.
The latter goal should be optional, IMO, rather than required.
</snip>
this is exactly what i've been trying to tell (only that my english
wording leaves a lot to be desired)
thanks Joel :)
the primary goal is already achieved by qtractor on jack-session and
ladish; the second goal is the one i called "utopian".
speaking from a developer's pov. i find it very unlikely that NSM will
ever get broader acceptance than jack-session and/or ladish, given the
"utopian" restrictions it poses on client application design.
i wonder for a while: modifying an application to participate in
jack-session, for instance, is dead simple and costs only a small amount
of developer time and effort, provided he/she has the proper motivation
;)
otoh. i have this creepy feeling that, to comply to NSM, one has to
compromise a lot of the application design and behavior--gui
restrictions, file location restrictions, osc managing interface, to
name a few--not that they are bad ideas at all, quite the contrary, but
they impose a kind of non-negligible (pun intended;) change into
application workings, unless coded to comply to the NSM-client-logo from
day zero.
i keep wondering: if that ever flies above its toes then i'll certainly
call it "The linux-audio revolution" (or miracle, scnr:)
cheers
--
rncbc aka Rui Nuno Capela
11:39 a.m.
On 04/03/2012 10:05 AM, rncbc wrote:
On 03.04.2012 06:49, Joel Roth wrote:
As far as I understood, to have everything saved in the session folder
was designed to make the behavior of the session manager more
predictable and more simple to avoid errors and misbehavior.
To be able to export the session was *not* the primary choice for this
(correct me if I am wrong).
On Thu, Mar 29, 2012 at 03:44:17PM +0200, Emanuel
Rumpf wrote:
<snip>
Back to life - back to reality
1. We start qtractor as part of a session, create some midi-tracks,
include some external wav-files.
Should the SM "know" about these external files, as I suggested ?
(Allowing the user to find out basic info about it. )
Or leave it completely to qtractor ?
As I understand it, the primary motivation for a session
manager is to be able to save and restore the state of an
audio project[1] that consists of multiple interconnected
programs running on a multiprocessing Linux system.
In other words, the minimum capability sufficient to be
useful would be some sort of checkpointing mechanism.
A secondary goal, discussed extensively here, is that it
would be nice to be able to copy a session or export a
session. This is where all the contentious issues with
handling filesystem objects comes up.
The latter goal should be optional, IMO, rather than required.
</snip>
this is exactly what i've been trying to tell (only that my english
wording leaves a lot to be desired)
thanks Joel :)
the primary goal is already achieved by qtractor on jack-session and
ladish; the second goal is the one i called "utopian".
speaking from a developer's pov. i find it very unlikely that NSM will
ever get broader acceptance than jack-session and/or ladish, given the
"utopian" restrictions it poses on client application design.
i wonder for a while: modifying an application to participate in
jack-session, for instance, is dead simple and costs only a small amount
of developer time and effort, provided he/she has the proper motivation ;)
otoh. i have this creepy feeling that, to comply to NSM, one has to
compromise a lot of the application design and behavior--gui
restrictions, file location restrictions, osc managing interface, to
name a few--not that they are bad ideas at all, quite the contrary, but
they impose a kind of non-negligible (pun intended;) change into
application workings, unless coded to comply to the NSM-client-logo from
day zero.
Feelings are important, especially when dealing with something like
session management which success depends more or less by the adoption by
others. But I think we need to know the *facts* here. Is it really that
way as you think it is, or is it just your initial resistance (which one
can understand) to comply to the strict rules of NSM and isn't it that
bad when having a closer look at it?
It's a reasonable point to discuss though...
i keep wondering: if that ever flies above its toes then i'll certainly
call it "The linux-audio revolution" (or miracle, scnr:)
cheers
--
rncbc aka Rui Nuno Capela
_______________________________________________
Linux-audio-dev mailing list
Linux-audio-dev(a)lists.linuxaudio.org
http://lists.linuxaudio.org/listinfo/linux-audio-dev
11:42 a.m.
On 04/03/2012 11:38 AM, rosea.grammostola wrote:
On 04/03/2012 10:05 AM, rncbc wrote:
* not the primary reason for this choice
On 03.04.2012 06:49, Joel Roth wrote:
As far as I understood, to have everything saved in the session folder
was designed to make the behavior of the session manager more
predictable and more simple to avoid errors and misbehavior.
To be able to export the session was *not* the primary choice for this
(correct me if I am wrong). On Thu, Mar 29, 2012 at 03:44:17PM +0200, Emanuel
Rumpf wrote:
<snip>
Back to life - back to reality
1. We start qtractor as part of a session, create some midi-tracks,
include some external wav-files.
Should the SM "know" about these external files, as I suggested ?
(Allowing the user to find out basic info about it. )
Or leave it completely to qtractor ?
As I understand it, the primary motivation for a session
manager is to be able to save and restore the state of an
audio project[1] that consists of multiple interconnected
programs running on a multiprocessing Linux system.
In other words, the minimum capability sufficient to be
useful would be some sort of checkpointing mechanism.
A secondary goal, discussed extensively here, is that it
would be nice to be able to copy a session or export a
session. This is where all the contentious issues with
handling filesystem objects comes up.
The latter goal should be optional, IMO, rather than required.
</snip>
this is exactly what i've been trying to tell (only that my english
wording leaves a lot to be desired)
thanks Joel :)
the primary goal is already achieved by qtractor on jack-session and
ladish; the second goal is the one i called "utopian".
speaking from a developer's pov. i find it very unlikely that NSM will
ever get broader acceptance than jack-session and/or ladish, given the
"utopian" restrictions it poses on client application design.
i wonder for a while: modifying an application to participate in
jack-session, for instance, is dead simple and costs only a small amount
of developer time and effort, provided he/she has the proper
motivation ;)
otoh. i have this creepy feeling that, to comply to NSM, one has to
compromise a lot of the application design and behavior--gui
restrictions, file location restrictions, osc managing interface, to
name a few--not that they are bad ideas at all, quite the contrary, but
they impose a kind of non-negligible (pun intended;) change into
application workings, unless coded to comply to the NSM-client-logo from
day zero.
Feelings are important, especially when dealing with something like
session management which success depends more or less by the adoption by
others. But I think we need to know the *facts* here. Is it really that
way as you think it is, or is it just your initial resistance (which one
can understand) to comply to the strict rules of NSM and isn't it that
bad when having a closer look at it?
It's a reasonable point to discuss though...
i keep wondering: if that ever flies above its toes then i'll certainly
call it "The linux-audio revolution" (or miracle, scnr:)
cheers
--
rncbc aka Rui Nuno Capela
_______________________________________________
Linux-audio-dev mailing list
Linux-audio-dev(a)lists.linuxaudio.org
http://lists.linuxaudio.org/listinfo/linux-audio-dev
12:55 p.m.
On 03.04.2012 10:38, rosea.grammostola wrote:
On 04/03/2012 10:05 AM, rncbc wrote:
but is this one i complain about. nb. getting the full application
state saved under one SM session directory is a lot different than
saving everything an application state refers to under the same SM
session directory.
i'll gently recall you can actually have sort of both with qtractor
under jack-session management: you just choose which of qtractor's
default session file format you want: either the regular xml state file
(.qtr) or the complete bundle, self-contained archive/zip file (.qtz).
note that if your files are huge, saving in this latter format might
just take more time :)
however, please note, that's just a qtractor's user
preference/convenience option, not mandated by any permanent rule of the
SM API.
byee
--
rncbc aka Rui Nuno Capela
On 03.04.2012 06:49, Joel Roth wrote:
As far as I understood, to have everything saved in the session
folder was designed to make the behavior of the session manager more
predictable and more simple to avoid errors and misbehavior.
To be able to export the session was *not* the primary choice for
this (correct me if I am wrong).
On Thu, Mar 29, 2012 at 03:44:17PM +0200, Emanuel
Rumpf wrote:
<snip>
Back to life - back to reality
1. We start qtractor as part of a session, create some
midi-tracks,
include some external wav-files.
Should the SM "know" about these external files, as I suggested ?
(Allowing the user to find out basic info about it. )
Or leave it completely to qtractor ?
As I understand it, the primary motivation for a session
manager is to be able to save and restore the state of an
audio project[1] that consists of multiple interconnected
programs running on a multiprocessing Linux system.
In other words, the minimum capability sufficient to be
useful would be some sort of checkpointing mechanism.
A secondary goal, discussed extensively here, is that it
would be nice to be able to copy a session or export a
session. This is where all the contentious issues with
handling filesystem objects comes up.
The latter goal should be optional, IMO, rather than required.
</snip>
this is exactly what i've been trying to tell (only that my english
wording leaves a lot to be desired)
thanks Joel :)
the primary goal is already achieved by qtractor on jack-session and
ladish; the second goal is the one i called "utopian".
2:56 p.m.
On 04/03/2012 11:51 AM, rncbc wrote:
On 03.04.2012 10:38, rosea.grammostola wrote:
But Qtractor seems to be special case here. Jonathan said in this thread
that there are not many apps with the same behavior when it comes to
saving and using files/ sessions.
So saying that this isn't ideal for Qtractor-like-applications, doesn't
say that other developers have problems with the strict saving rules of
NSM.
(I have the *feeling* that these rules are in general harder to accept
for developers of big applications like Qtractor, Ardour, Muse etc, then
it is for small applications. The first have the unconscious urge of
being in charge I can imagine, but I could be wrong).
However, it might be fair to take a look at how JackSession does this
and answer the question why it is or why it is not a problem to not have
these saving restrictions.
Regards,
\r
On 04/03/2012 10:05 AM, rncbc wrote:
but is this one i complain about. nb. getting the full application state
saved under one SM session directory is a lot different than saving
everything an application state refers to under the same SM session
directory.
i'll gently recall you can actually have sort of both with qtractor
under jack-session management: you just choose which of qtractor's
default session file format you want: either the regular xml state file
(.qtr) or the complete bundle, self-contained archive/zip file (.qtz).
note that if your files are huge, saving in this latter format might
just take more time :)
however, please note, that's just a qtractor's user
preference/convenience option, not mandated by any permanent rule of the
SM API. On 03.04.2012 06:49, Joel Roth wrote:
As far as I understood, to have everything saved in the session
folder was designed to make the behavior of the session manager more
predictable and more simple to avoid errors and misbehavior.
To be able to export the session was *not* the primary choice for
this (correct me if I am wrong).
On Thu, Mar 29, 2012 at 03:44:17PM +0200, Emanuel
Rumpf wrote:
> Back to life - back to reality
>
> 1. We start qtractor as part of a session, create some midi-tracks,
> include some external wav-files.
>
> Should the SM "know" about these external files, as I suggested ?
> (Allowing the user to find out basic info about it. )
> Or leave it completely to qtractor ?
<snip>
As I understand it, the primary motivation for a session
manager is to be able to save and restore the state of an
audio project[1] that consists of multiple interconnected
programs running on a multiprocessing Linux system.
In other words, the minimum capability sufficient to be
useful would be some sort of checkpointing mechanism.
A secondary goal, discussed extensively here, is that it
would be nice to be able to copy a session or export a
session. This is where all the contentious issues with
handling filesystem objects comes up.
The latter goal should be optional, IMO, rather than required.
</snip>
this is exactly what i've been trying to tell (only that my english
wording leaves a lot to be desired)
thanks Joel :)
the primary goal is already achieved by qtractor on jack-session and
ladish; the second goal is the one i called "utopian".
3:35 p.m.
On 04/03/2012 02:55 PM, rosea.grammostola wrote:
On 04/03/2012 11:51 AM, rncbc wrote:
When searching for an answer, you find at least two quotes which tell
you that it is important:
[Quote=Fons]
3. Clearly defining the way an app should behave w.r.t. its
File menu entries (when managed). This is quite intrusive
to existing clients, but it is IMHO absolutley essential.
Kudos to the designer(s) for the having the courage to do
this instead of allowing application developers to take
the 'least effort' way (which would of course be better
marketing, but invite later misery).
[/Quote=Fons]
*Why* this is essential isn't elaborated by Fons though.
[quote=Liles]
Currently one of the strong points of NSM is that applications with
heavy state (e.g. large audio files) know *exactly* where to put the
state at the time they join the session. This eliminates the need for
undesirable hacks with just storing a link to the heavy state (as was
generally required with LASH). I felt like this was one of the primary
requirements of Non-DAW which was not addressed by other session managers.
[/quote=Liles]
(Assuming that this ^ is because of the strict opening and saving rules
of NSM).
Liles compares here with LASH, undesirable hacks are not needed anymore.
Why is this a primary requirement?
Moreover LASH isn't seen as a serious candidate anyway these days. I
would rather see a comparison with JackSession in this area. In other words:
How JackSession does this and why is it, or why it is not, a problem to
not have these strict rules for applications which are in a session.
Regards,
\r
On 03.04.2012 10:38, rosea.grammostola wrote:
But Qtractor seems to be special case here. Jonathan said in this thread
that there are not many apps with the same behavior when it comes to
saving and using files/ sessions.
So saying that this isn't ideal for Qtractor-like-applications, doesn't
say that other developers have problems with the strict saving rules of
NSM.
(I have the *feeling* that these rules are in general harder to accept
for developers of big applications like Qtractor, Ardour, Muse etc, then
it is for small applications. The first have the unconscious urge of
being in charge I can imagine, but I could be wrong).
However, it might be fair to take a look at how JackSession does this
and answer the question why it is or why it is not a problem to not have
these saving restrictions. On 04/03/2012 10:05 AM, rncbc wrote:
but is this one i complain about. nb. getting the full application state
saved under one SM session directory is a lot different than saving
everything an application state refers to under the same SM session
directory.
i'll gently recall you can actually have sort of both with qtractor
under jack-session management: you just choose which of qtractor's
default session file format you want: either the regular xml state file
(.qtr) or the complete bundle, self-contained archive/zip file (.qtz).
note that if your files are huge, saving in this latter format might
just take more time :)
however, please note, that's just a qtractor's user
preference/convenience option, not mandated by any permanent rule of the
SM API. On 03.04.2012 06:49, Joel Roth wrote:
> On Thu, Mar 29, 2012 at 03:44:17PM +0200, Emanuel Rumpf wrote:
>
>> Back to life - back to reality
>>
>> 1. We start qtractor as part of a session, create some midi-tracks,
>> include some external wav-files.
>>
>> Should the SM "know" about these external files, as I suggested ?
>> (Allowing the user to find out basic info about it. )
>> Or leave it completely to qtractor ?
>
<snip>
>
> As I understand it, the primary motivation for a session
> manager is to be able to save and restore the state of an
> audio project[1] that consists of multiple interconnected
> programs running on a multiprocessing Linux system.
>
> In other words, the minimum capability sufficient to be
> useful would be some sort of checkpointing mechanism.
>
> A secondary goal, discussed extensively here, is that it
> would be nice to be able to copy a session or export a
> session. This is where all the contentious issues with
> handling filesystem objects comes up.
>
> The latter goal should be optional, IMO, rather than required.
>
</snip>
this is exactly what i've been trying to tell (only that my english
wording leaves a lot to be desired)
thanks Joel :)
the primary goal is already achieved by qtractor on jack-session and
ladish; the second goal is the one i called "utopian".
As far as I understood, to have everything saved in the session
folder was designed to make the behavior of the session manager more
predictable and more simple to avoid errors and misbehavior.
To be able to export the session was *not* the primary choice for
this (correct me if I am wrong).
7:17 p.m.
On Tue, Apr 3, 2012 at 6:35 AM, rosea.grammostola
<rosea.grammostola(a)gmail.com> wrote:
[quote=Liles]
Currently one of the strong points of NSM is that applications with heavy
state (e.g. large audio files) know *exactly* where to put the state at the
time they join the session. This eliminates the need for undesirable hacks
with just storing a link to the heavy state (as was generally required with
LASH). I felt like this was one of the primary requirements of Non-DAW which
was not addressed by other session managers.
[/quote=Liles]
(Assuming that this ^ is because of the strict opening and saving rules of
NSM).
Liles compares here with LASH, undesirable hacks are not needed anymore.
Why is this a primary requirement?
Because LASH was designed with the assumption that all client
applications would either:
1) Store all their state in memory and be fine with just dumping it to
disk when the save yourself message came.
2) Naturally store their heavy state in some random place (like QTractor?)
Programs with heavy state closely associated to the individual
projects (like Non-DAW and Ardour) had to work around this by just
storing the project data in some random place and only storing a
reference to it in LASH, which was terrible from a consistency
perspective because the user really had no idea where their data was.
I want to have my sessions laid out on disk in a very specific way,
with none of them named after GUIDs, and no applications/data being
(mis)directed to a session just because it happened to be the last one
active.
With NSM (this is part of the server implementation and not the
protocol) the user can lay things out on disk however they like,
organizing their sessions in any way they want (including doing fancy
things with subdirectories and symlinks) *and* have an expectation
that e.g. the audio they record in Non-DAW after adding it as a client
to a session *actually goes into the session directory they defined
when they created the session*. If I want to back up my audio
partition, I should not have to track down gigabytes of data from
some hidden directory in $HOME that is only referred to inside
incomprehensible XML files as well.
The matter is complicated by applications which have been attempting
to do their own crude form of session management. But here's the key
point: It is only reasonable to expect an application to adhere to
*one* system of session management at a time. So, if the application
is connected to NSM, it should behave in a way consistent with other
NSM capable applications, and if it is connected to XSM, JackSession
or LASH, or what have you it can do whatever those systems allow
(which is totally undefined anyway).
Moreover LASH isn't seen as a serious candidate
anyway these days. I would
rather see a comparison with JackSession in this area. In other words:
How JackSession does this and why is it, or why it is not, a problem to not
have these strict rules for applications which are in a session.
I believe JackSession was intended to be the bare minimum required to
transmit a 'save' message to JACK applications... Just a very basic
protocol. Doing anything more to ensure a smooth and consistent user
experience is outside of its scope. A lot of this behavior depends on
the implementation of the Session Manager server itself, but
JackSession by its nature has some basic limitations that exclude the
possibility of the kind of features NSM has, so a server
implementation for it can only do so much...
7:03 p.m.
On 04/03/2012 01:55 PM, rosea.grammostola wrote:
On 04/03/2012 11:51 AM, rncbc wrote:
speaking of which
ardour gets all its stuff under one own session directory, on a per
session/project basis, iirc just like NSM mandates,
bbbuuuuuut...:) making that one and the same directory as from an
outsider/independent session manager like NSM is asking for a lot of
file and symlink juggling, if you ask me
i'm not an expert in ardour internals, someone else could chime in and
help me here.
my feeling again is that the effort to comply with NSM isn't, won't be
so easy for any lass-than-simple-textbook-like client examples
once again, i call for some ardour expertise. i'm even afraid to ask
this btw, but does ardour work with jack-session already? o.O
aham
On 03.04.2012 10:38, rosea.grammostola wrote:
But Qtractor seems to be special case here. Jonathan said in this thread
that there are not many apps with the same behavior when it comes to
saving and using files/ sessions.
So saying that this isn't ideal for Qtractor-like-applications, doesn't
say that other developers have problems with the strict saving rules of
NSM.
(I have the *feeling* that these rules are in general harder to accept
for developers of big applications like Qtractor, Ardour, Muse etc, then
it is for small applications. The first have the unconscious urge of
being in charge I can imagine, but I could be wrong).
On 04/03/2012 10:05 AM, rncbc wrote:
but is this one i complain about. nb. getting the full application state
saved under one SM session directory is a lot different than saving
everything an application state refers to under the same SM session
directory.
i'll gently recall you can actually have sort of both with qtractor
under jack-session management: you just choose which of qtractor's
default session file format you want: either the regular xml state file
(.qtr) or the complete bundle, self-contained archive/zip file (.qtz).
note that if your files are huge, saving in this latter format might
just take more time :)
however, please note, that's just a qtractor's user
preference/convenience option, not mandated by any permanent rule of the
SM API. On 03.04.2012 06:49, Joel Roth wrote:
> On Thu, Mar 29, 2012 at 03:44:17PM +0200, Emanuel Rumpf wrote:
>
>> Back to life - back to reality
>>
>> 1. We start qtractor as part of a session, create some midi-tracks,
>> include some external wav-files.
>>
>> Should the SM "know" about these external files, as I suggested ?
>> (Allowing the user to find out basic info about it. )
>> Or leave it completely to qtractor ?
>
<snip>
>
> As I understand it, the primary motivation for a session
> manager is to be able to save and restore the state of an
> audio project[1] that consists of multiple interconnected
> programs running on a multiprocessing Linux system.
>
> In other words, the minimum capability sufficient to be
> useful would be some sort of checkpointing mechanism.
>
> A secondary goal, discussed extensively here, is that it
> would be nice to be able to copy a session or export a
> session. This is where all the contentious issues with
> handling filesystem objects comes up.
>
> The latter goal should be optional, IMO, rather than required.
>
</snip>
this is exactly what i've been trying to tell (only that my english
wording leaves a lot to be desired)
thanks Joel :)
the primary goal is already achieved by qtractor on jack-session and
ladish; the second goal is the one i called "utopian".
As far as I understood, to have everything saved in the session
folder was designed to make the behavior of the session manager more
predictable and more simple to avoid errors and misbehavior.
To be able to export the session was *not* the primary choice for
this (correct me if I am wrong).
However, it might be fair to take a look at how
JackSession does this
and answer the question why it is or why it is not a problem to not have
these saving restrictions.
jack-session has some fsck-up restrictions of its own
one that i had historical complaints is about this non-reusable session
directory restriction (here, the "non" particle, is not a pun;) which
meant that you can't save into the same session directory twice
a "really-smart/intelligent" SM could copy and re(sym)link all the
references under each client participant's session sub-directory, yes, a
chimeric kind of effort comes to mind :o)
alas. this jack-session restriction has been somewhat circumvented by
the "versioning" feature on qjackctl-as-jack-session-manager, by yours
truly. yes it's true, but it shows you how cumbersome is like when one
has to go around and break the red tape of those draconian SM's ;)
and now NSM is about asking for even more and thicker red tape...
cough
now, i could suggest NSM API to be split in levels of compliance and
restrictiveness, so to speak:
- level 0 :- clients just store/retrieve their own private state from a
supplied and independent session sub-directory; no GUI File menu
restrictions; no file location restrictions, no symlinks, no juggling,
no dupes, no sh*t.
- level 1+ :- anything that (may progressively?) imposes each one the
mentioned non-restrictions of level 0.
starting with level 0, there's a fair chance for NSM to revolve, and
even co-exist peacefully with jack-session and ladish. call me a dreamer :)
cheers
--
rncbc aka Rui Nuno Capela
rncbc(a)rncbc.org
7:34 p.m.
On Tue, Apr 3, 2012 at 10:04 AM, Rui Nuno Capela <rncbc(a)rncbc.org> wrote:
jack-session has some fsck-up restrictions of its own
one that i had historical complaints is about this non-reusable session
directory restriction (here, the "non" particle, is not a pun;) which meant
that you can't save into the same session directory twice
a "really-smart/intelligent" SM could copy and re(sym)link all the
references under each client participant's session sub-directory, yes, a
chimeric kind of effort comes to mind :o)
alas. this jack-session restriction has been somewhat circumvented by the
"versioning" feature on qjackctl-as-jack-session-**manager, by yours
truly. yes it's true, but it shows you how cumbersome is like when one has
to go around and break the red tape of those draconian SM's ;)
and now NSM is about asking for even more and thicker red tape...
cough
now, i could suggest NSM API to be split in levels of compliance and
restrictiveness, so to speak:
- level 0 :- clients just store/retrieve their own private state from a
supplied and independent session sub-directory; no GUI File menu
restrictions; no file location restrictions, no symlinks, no juggling, no
dupes, no sh*t.
- level 1+ :- anything that (may progressively?) imposes each one the
mentioned non-restrictions of level 0.
starting with level 0, there's a fair chance for NSM to revolve, and even
co-exist peacefully with jack-session and ladish. call me a dreamer :)
Peacefully co-existing at the lowest common denominator of functionality
completely defeats the purpose of trying to improve the integration
experience for *users*. Remember, you only have to change the code once...
People use this stuff every day. If there is a compliance level of 0, then
developers will just pick that (you know it's true) and stop there.
As far as the restrictions imposed by NSM... NSM requires very little of
the application developer. The hardest part is if you want to support the
session 'switch' functionality, and even that is not very difficult (hey,
all the Non-* does it, so that means I had to implement it 4 times... so
why are you complaining when you haven't even tried?) The requirement that
you *not* do something is a hell of a lot easier to comply with than
requiring that you do something complicated, which is exactly why NSM
*doesn't* require applications to do anything complicated...
4 Apr
4 Apr
10:11 a.m.
Guys, I read about JACK Session, tried it out. It does seem very capable.
And if more apps add support (which, as people say in this discussion, is
not that difficult), wouldn't JACK Session be a good, stable way to restore
sessions? After all, JACK is a basic thing for Linux Audio and adding
support for all its features, including Session, would just become part of
the default routine. Am I missing something here?
--
Louigi Verona
http://www.louigiverona.ru/
11:06 a.m.
Am 4. April 2012 08:11 schrieb Louigi Verona <louigi.verona(a)gmail.com>om>:
Am I missing something here?
Yes,
search the archives.
or visit
http://wiki.linuxaudio.org/wiki/user/emrum/jack_session_2_draft
to see,
what NSM tries to improve, by imposing some meaningful rules.
1:18 p.m.
On 04/03/2012 07:04 PM, Rui Nuno Capela wrote:
now, i could suggest NSM API to be split in levels of
compliance and
restrictiveness, so to speak:
- level 0 :- clients just store/retrieve their own private state from a
supplied and independent session sub-directory; no GUI File menu
restrictions; no file location restrictions, no symlinks, no juggling,
no dupes, no sh*t.
- level 1+ :- anything that (may progressively?) imposes each one the
mentioned non-restrictions of level 0.
How much more effort will it be in terms of coding, to implement
'level-1' versus 'level-0'?
\r
2:22 p.m.
On 04/04/2012 12:18 PM, rosea.grammostola wrote:
On 04/03/2012 07:04 PM, Rui Nuno Capela wrote:
speaking from qtractor pov.:
- level 0: minimal effort as it would be a probable and simple
rephrasing and/or adaptation of the code already in place for
jack-session; also, there's this osc branch somewhat lurking in svn to
get readily merged and apply for the NSM/OSC interface.
- level 1+: pervasive change and effort; almost brand new application
overhaul (iow. won't happen any time soon:) sorry.
cheers
--
rncbc aka Rui Nuno Capela
rncbc(a)rncbc.org
now, i could suggest NSM API to be split in
levels of compliance and
restrictiveness, so to speak:
- level 0 :- clients just store/retrieve their own private state from a
supplied and independent session sub-directory; no GUI File menu
restrictions; no file location restrictions, no symlinks, no juggling,
no dupes, no sh*t.
- level 1+ :- anything that (may progressively?) imposes each one the
mentioned non-restrictions of level 0.
How much more effort will it be in terms of coding, to implement
'level-1' versus 'level-0'?
2:36 p.m.
On 04/04/2012 02:22 PM, Rui Nuno Capela wrote:
On 04/04/2012 12:18 PM, rosea.grammostola wrote:
Another question. If you compare NSM level 0 (!) with JackSession. Which
session manager do you prefer and why?
Regards,
\r
On 04/03/2012 07:04 PM, Rui Nuno Capela wrote:
speaking from qtractor pov.:
- level 0: minimal effort as it would be a probable and simple
rephrasing and/or adaptation of the code already in place for
jack-session; also, there's this osc branch somewhat lurking in svn to
get readily merged and apply for the NSM/OSC interface.
- level 1+: pervasive change and effort; almost brand new application
overhaul (iow. won't happen any time soon:) sorry. now, i could suggest NSM API to be split in
levels of compliance and
restrictiveness, so to speak:
- level 0 :- clients just store/retrieve their own private state from a
supplied and independent session sub-directory; no GUI File menu
restrictions; no file location restrictions, no symlinks, no juggling,
no dupes, no sh*t.
- level 1+ :- anything that (may progressively?) imposes each one the
mentioned non-restrictions of level 0.
How much more effort will it be in terms of coding, to implement
'level-1' versus 'level-0'?
4:38 p.m.
On 04/04/2012 01:35 PM, rosea.grammostola wrote:
On 04/04/2012 02:22 PM, Rui Nuno Capela wrote:
well, NSM level 0 adds nothing to what JSM already delivers. sorry for
the noise :)
the once self-called "uber-procrastinator" says: prefer what is already
there and "de-facto" working.
of course it's a biased opinion
nuff said :)
--
rncbc aka Rui Nuno Capela
rncbc(a)rncbc.org
On 04/04/2012 12:18 PM, rosea.grammostola wrote:
Another question. If you compare NSM level 0 (!) with JackSession. Which
session manager do you prefer and why?
On 04/03/2012 07:04 PM, Rui Nuno Capela wrote:
speaking from qtractor pov.:
- level 0: minimal effort as it would be a probable and simple
rephrasing and/or adaptation of the code already in place for
jack-session; also, there's this osc branch somewhat lurking in svn to
get readily merged and apply for the NSM/OSC interface.
- level 1+: pervasive change and effort; almost brand new application
overhaul (iow. won't happen any time soon:) sorry. now, i could suggest NSM API to be split in
levels of compliance and
restrictiveness, so to speak:
- level 0 :- clients just store/retrieve their own private state from a
supplied and independent session sub-directory; no GUI File menu
restrictions; no file location restrictions, no symlinks, no juggling,
no dupes, no sh*t.
- level 1+ :- anything that (may progressively?) imposes each one the
mentioned non-restrictions of level 0.
How much more effort will it be in terms of coding, to implement
'level-1' versus 'level-0'?
4:56 p.m.
On 04/04/2012 04:39 PM, Rui Nuno Capela wrote:
Your opinion is clear, but your arguments are not strictly correct I think.
You say that a hypothetical NSM level 0, adds nothing to what JS
delivers, but that's not true.
When I want to save a session in JS, I have to make a new folder. If I
want to save a slightly changed session, I have to make a new folder or
choose a existent folder. If I do the latter, the gui ask me if I really
want to overwrite it. I choose 'yes'. (This is what you could call
pretty cumbersome). In one case, someone did choose the /home/user
folder... and lost all his data. Ok, you've versioning now in
qjackctl... There is no way in Qjackctl to add apps without JS support
to the session. It is not possible to quit a session without saving it,
so I have to close every application manually.
In NSM on the other hand. I make a new session, add and remove apps on
the fly from a nice centralized and quick GUI interface. It's even easy
to add apps without NSM support (or scripts) via the GUI. If I change a
session, I'm just able to save it without making a new folder or
overwrite it. I am able to close a whole session and to abort a whole
session (without saving). As a user can expect, all apps in the session
close. Moreover it's possible to duplicate a session as a manner of
using templates. It's very easy and fast to change between sessions. I
am able to use session over the network very easily. I have never the
risk of overwriting my precious data. I' m able to add applications
without JACK support to NSM (Frescobaldi notation-editor, Emacs with
SuperCollder etc.).
If you say that NSM adds nothing then a) you didn't try it and don't
really know where you're talking about or b) don't think that the NSM
stuff mentioned above are valuable of any kind for a user.
Regards,
\r
If
Another question. If you compare NSM level 0 (!) with JackSession. Which
session manager do you prefer and why?
well, NSM level 0 adds nothing to what JSM already delivers. sorry for
the noise :)
the once self-called "uber-procrastinator" says: prefer what is already
there and "de-facto" working.
5:20 p.m.
On 04/04/2012 04:55 PM, rosea.grammostola wrote:
On 04/04/2012 04:39 PM, Rui Nuno Capela wrote:
Your opinion is clear, but your arguments are not strictly correct I think.
You say that a hypothetical NSM level 0, adds nothing to what JS
delivers, but that's not true.
When I want to save a session in JS, I have to make a new folder. If I
want to save a slightly changed session, I have to make a new folder or
choose a existent folder. If I do the latter, the gui ask me if I really
want to overwrite it. I choose 'yes'. (This is what you could call
pretty cumbersome).
I'm not sure if this is cumbersomeness of Qjackctl as a GUI for
JackSession or JackSession itself. I'm not sure how this works in
Pyjacksm (which is a pretty limited GUI and not in active development).
In one case, someone did choose the /home/user
Another question. If you compare NSM level 0 (!) with JackSession. Which
session manager do you prefer and why?
well, NSM level 0 adds nothing to what JSM already delivers. sorry for
the noise :)
the once self-called "uber-procrastinator" says: prefer what is already
there and "de-facto" working. folder... and lost all his data. Ok, you've
versioning now in
qjackctl... There is no way in Qjackctl to add apps without JS support
to the session. It is not possible to quit a session without saving it,
so I have to close every application manually.
In NSM on the other hand. I make a new session, add and remove apps on
the fly from a nice centralized and quick GUI interface. It's even easy
to add apps without NSM support (or scripts) via the GUI.
Btw this should in theory also be possible with JS I think. Someone
could write a GUI possibly that is also capable of starting applications
from it. Moreover JS can make use of "infra clients", (an alpha version
of) pyjacksm supports this via a configuration file, .pyjacksmrc
Which looks like this, for example:
[DEFAULT]
sessiondir = ~/linuxaudio/JacksmpySession
[infra]
a2j = a2jmidid -e
jkmeter = jkmeter
Then it should be possible to add applications without JS support or
without a 'state to save' to the JackSession.
BUT, this is *not* implemented in Qjackctl.
Pyjacksm sessions are *not* exchangeable with qjackctl
http://tangostudio.tuxfamily.org/en/documentations/jacksession
If I change a
session, I'm just able to save it without making a
new folder or
overwrite it. I am able to close a whole session and to abort a whole
session (without saving). As a user can expect, all apps in the session
close. Moreover it's possible to duplicate a session as a manner of
using templates. It's very easy and fast to change between sessions. I
am able to use session over the network very easily. I have never the
risk of overwriting my precious data. I' m able to add applications
without JACK support to NSM (Frescobaldi notation-editor, Emacs with
SuperCollder etc.).
If you say that NSM adds nothing then a) you didn't try it and don't
really know where you're talking about or b) don't think that the NSM
stuff mentioned above are valuable of any kind for a user.
Regards,
\r
If
5:46 p.m.
On 04/04/2012 03:55 PM, rosea.grammostola wrote:
On 04/04/2012 04:39 PM, Rui Nuno Capela wrote:
Your opinion is clear, but your arguments are not strictly correct I think.
You say that a hypothetical NSM level 0, adds nothing to what JS
delivers, but that's not true.
When I want to save a session in JS, I have to make a new folder. If I
want to save a slightly changed session, I have to make a new folder or
choose a existent folder. If I do the latter, the gui ask me if I really
want to overwrite it. I choose 'yes'. (This is what you could call
pretty cumbersome). In one case, someone did choose the /home/user
folder... and lost all his data. Ok, you've versioning now in
qjackctl... There is no way in Qjackctl to add apps without JS support
to the session. It is not possible to quit a session without saving it,
so I have to close every application manually.
In NSM on the other hand. I make a new session, add and remove apps on
the fly from a nice centralized and quick GUI interface. It's even easy
to add apps without NSM support (or scripts) via the GUI. If I change a
session, I'm just able to save it without making a new folder or
overwrite it. I am able to close a whole session and to abort a whole
session (without saving). As a user can expect, all apps in the session
close. Moreover it's possible to duplicate a session as a manner of
using templates. It's very easy and fast to change between sessions. I
am able to use session over the network very easily. I have never the
risk of overwriting my precious data. I' m able to add applications
without JACK support to NSM (Frescobaldi notation-editor, Emacs with
SuperCollder etc.).
If you say that NSM adds nothing then a) you didn't try it and don't
really know where you're talking about or b) don't think that the NSM
stuff mentioned above are valuable of any kind for a user.
i may have missed it, but those application clients which are NOT coded
as compliant to a session protocol are not the point--that's just a SM
implementation convenience outside of the bounds of the "ideal-SM"
discussion
i'll refresh your memory that pyjacksm (a JSM reference implementation)
does that too (something called exo-clients or wtf:). ladish have been
doing that also and way, way before, for ages now o.O
unfortunately, i reckon, qjackctl doesn't. on my own call it has been
pure&strict to the JS business (aka. protocol) and nothing more.
however, re. exo-/infra-clients (or w/e they've been called, i don't
quite remember exactly but those are about clients which are
non-jack-session-aware) are in the drawer ntl.
actually, i was minding about the *intrinsic* cost/benefits of the
session protocol and *not* about *any* particular *session management*
(SM) implementation
got that?
--
rncbc aka Rui Nuno Capela
rncbc(a)rncbc.org
Another question. If you compare NSM level 0 (!) with JackSession. Which
session manager do you prefer and why?
well, NSM level 0 adds nothing to what JSM already delivers. sorry for
the noise :)
the once self-called "uber-procrastinator" says: prefer what is already
there and "de-facto" working.
6:20 p.m.
On 04/04/2012 05:46 PM, Rui Nuno Capela wrote:
On 04/04/2012 03:55 PM, rosea.grammostola wrote:
That's
probably the most essential part on LAD to discuss indeed, the
session protocol. But that doesn't take away that for a user these are
essential components. The user is looking at how an (SM) application is
presented on his Desktop, the *end-product*. And because of the fact
that also the LAU'er knows that it is 'utopian' to think that all the
apps on apps.linuxaudio.org will get session support, it *is* a
important matter a SM has to deal with. If Qjackctl doesn't offer this
functionality by purpose, it is a obvious disadvantage for the user at
the end.
On 04/04/2012 04:39 PM, Rui Nuno Capela wrote:
Your opinion is clear, but your arguments are not strictly correct I
think.
You say that a hypothetical NSM level 0, adds nothing to what JS
delivers, but that's not true.
When I want to save a session in JS, I have to make a new folder. If I
want to save a slightly changed session, I have to make a new folder or
choose a existent folder. If I do the latter, the gui ask me if I really
want to overwrite it. I choose 'yes'. (This is what you could call
pretty cumbersome). In one case, someone did choose the /home/user
folder... and lost all his data. Ok, you've versioning now in
qjackctl... There is no way in Qjackctl to add apps without JS support
to the session. It is not possible to quit a session without saving it,
so I have to close every application manually.
In NSM on the other hand. I make a new session, add and remove apps on
the fly from a nice centralized and quick GUI interface. It's even easy
to add apps without NSM support (or scripts) via the GUI. If I change a
session, I'm just able to save it without making a new folder or
overwrite it. I am able to close a whole session and to abort a whole
session (without saving). As a user can expect, all apps in the session
close. Moreover it's possible to duplicate a session as a manner of
using templates. It's very easy and fast to change between sessions. I
am able to use session over the network very easily. I have never the
risk of overwriting my precious data. I' m able to add applications
without JACK support to NSM (Frescobaldi notation-editor, Emacs with
SuperCollder etc.).
If you say that NSM adds nothing then a) you didn't try it and don't
really know where you're talking about or b) don't think that the NSM
stuff mentioned above are valuable of any kind for a user.
i may have missed it, but those application clients which are NOT coded
as compliant to a session protocol are not the point--that's just a SM
implementation convenience outside of the bounds of the "ideal-SM"
discussion
i'll refresh your memory that pyjacksm (a JSM reference implementation)
does that too (something called exo-clients or wtf:). ladish have been
doing that also and way, way before, for ages now o.O
unfortunately, i reckon, qjackctl doesn't. on my own call it has been
pure&strict to the JS business (aka. protocol) and nothing more.
Another question. If you compare NSM level 0 (!) with JackSession.
Which
session manager do you prefer and why?
well, NSM level 0 adds nothing to what JSM already delivers. sorry for
the noise :)
the once self-called "uber-procrastinator" says: prefer what is already
there and "de-facto" working.
however, re. exo-/infra-clients (or w/e they've been called, i don't
quite remember exactly but those are about clients which are
non-jack-session-aware) are in the drawer ntl.
actually, i was minding about the *intrinsic* cost/benefits of the
session protocol and *not* about *any* particular *session management*
(SM) implementation
True, we've to make clear what the technical possibilities of a SM are.
You're saying that a hypothetical NSM level-0 offers nothing more
compared to JackSession in this scope. I do also doubt this, you might
be able to tell me what JackSession can do from the things I described
as advantages of NSM. I can think of these at least, which still stand:
- JackSession is not able to quit the applications in the session
without saving.
- It is not possible to add applications without JACK support to a
JackSession (Frescobalid, Emacs with SuperCollider)
- Changing between NSM sessions is more easy and faster
- with NSM you can use the duplicate function and so use templates
- with NSM you can open multiple session on one host
- NSM has a clear way how to use a session on multiple computers via the
network
- NSM sessions are not machine dependent (level 1)
This is just a quick brainstorm. As mentioned, this doesn't talk about
the end implementation benefits of NSM for the user, which are of equal
importance for the end-user. On that topic I conclude that Qjackctl
doesn't support infra clients by purpose and that I don't see it happen
that there will be another GUI who does support in the near future.
Regards,
\r
8:50 p.m.
On 04/04/2012 05:19 PM, rosea.grammostola wrote:
... On that topic I conclude that Qjackctl doesn't support infra
clients by purpose and that I don't see it happen that there will be
another GUI who does support in the near future.
wait, it's not "by purpose" but just "overlooked" ok?
infra-clients (ie. jack clients unaware of jack-session) and exo-clients
(non-jack applications) are here subjects of a "covenant": the SM in
charge, by its particular implementation, follows some god-knows-what
convention which is NOT bounded by the session protocol (or API) at
all--of course, the suspects are not session-aware to begin with, so any
SM can raise its own "convention" and make up its own party--it's a free
world isn't it? :)
as said, infra/exo-clients support on qjackctl (as a JSM) is "in the
drawer", meaning it's coming out any day soon. so, is there yet another
convention party in the making, you ask?
yep:)
cheers
--
rncbc aka Rui Nuno Capela
rncbc(a)rncbc.org
9:59 p.m.
On 04/04/2012 08:51 PM, Rui Nuno Capela wrote:
On 04/04/2012 05:19 PM, rosea.grammostola wrote:
That would take away one, for me important, advantage of NSM compared to
JackSession atm (for the user). All though the implementation in
Pyjacksm, is more cumbersome (using configuration file where you have to
set each application you use) compared to NSM (no thinking, just adding
clients).
One might ask why this isn't already in Qjackctl and how long it will
take though. Which brings me to another possible advantage of NSM. The
fact that the developer is clearly dedicated to the ask in time and
motivation. And also important, he uses NSM himself and believes in
session management. (I little reasons to believe that JS devs use
JackSession themselves. Also if I read your words well Rui, I don't
think you use Qjackctls session option yourself). With JackSession you
lack those things atm (no blaming here). It's probably no accident that
in NSM it's all there, whereas for JackSession some features still have
to be implemented (in the GUI). Personally I asked for the infra client
feature way back, but it's still not there. A new project like NSM seems
to be needed to get some new progress, this is not the kind of
dedication such a project needs (no blaming).
But of course, this are not the only reason to prefer one SM above the
other. As mentioned in my previous mails, there are arguments for me atm
to say that NSM gives a user more then JackSession (even with the
hypothetical level-0). NSM seems to be a SM which has a very good and
simple solution, more functionality then JackSession, without the need
of things like Jackdbus (ladish).
Also I've the opinion that the community should go with the best
implementation. Why go for an implementation which lacks useful
functionality when implementation into the apps are more or less the
same effort?
I think it's essential to the discussion to get the cards on the
table, so everybody can make up his own mind and decides which SM is the
best solution for the Linuxaudio session puzzle. It would be nice if we
could reach agreement on this, but it's a free world indeed. :)
Regards,
\r
... On that topic I conclude that Qjackctl doesn't support infra
clients by purpose and that I don't see it happen that there will be
another GUI who does support in the near future.
wait, it's not "by purpose" but just "overlooked" ok?
infra-clients (ie. jack clients unaware of jack-session) and exo-clients
(non-jack applications) are here subjects of a "covenant": the SM in
charge, by its particular implementation, follows some god-knows-what
convention which is NOT bounded by the session protocol (or API) at
all--of course, the suspects are not session-aware to begin with, so any
SM can raise its own "convention" and make up its own party--it's a free
world isn't it? :)
as said, infra/exo-clients support on qjackctl (as a JSM) is "in the
drawer", meaning it's coming out any day soon. so, is there yet another
convention party in the making, you ask?
10:13 p.m.
On 04/04/2012 09:59 PM, rosea.grammostola wrote:
But of course, this are not the only reason to prefer
one SM above the
other. As mentioned in my previous mails, there are arguments for me atm
to say that NSM gives a user more then JackSession (even with the
hypothetical level-0). NSM seems to be a SM which has a very good and
simple solution, more functionality then JackSession, without the need
of things like Jackdbus (ladish).
Also I've the opinion that the community should go with the best
implementation. Why go for an implementation which lacks useful
functionality when implementation into the apps are more or less the
same effort?
Afaik, NSM gives us all we users need when it comes to LAU session
management. You've to help me to give something it doesn't do in this
scope. If you can't help me with this, you can more or less take the
conclusion that NSM is a final solution to the Linuxaudio session
puzzle. Final as in, does all what it should do, has intrinsic all the
stuff it should be able to do in the coming >10 yrs, it doesn't lack
essential features in terms of functionality and workflow, if a better
SM bumps up in the coming yrs there will likely be no essential reasons
to switch to that one (which makes the effort for adding NSM support to
an app, a valuable and longstanding contribution).
Correct me if I'm wrong.
Regards,
\r
6 Apr
6 Apr
9:06 p.m.
On Wed, Apr 04, 2012 at 10:12:53PM +0200, rosea.grammostola wrote:
Afaik, NSM gives us all we users need when it comes to
LAU session
management.... Correct me if I'm wrong.
It would be great if the core functionality of NSM
could be separated out from the GUI to support
console users and environments where X may not
be available.
Regards,
Joel
--
Joel Roth
10:07 p.m.
On Fri, Apr 6, 2012 at 12:06 PM, Joel Roth <joelz(a)pobox.com> wrote:
On Wed, Apr 04, 2012 at 10:12:53PM +0200,
rosea.grammostola wrote:
FYI. This is already a matter of fact... the GUI communicates with nsmd via
OSC. nsmd can be run without the GUI and controlled via osc (there's a
program included in the distribution called send_osc to allow this kind of
thing to be done via shell scripts).
Afaik, NSM gives us all we users need when it
comes to LAU session
management.... Correct me if I'm wrong.
It would be great if the core functionality of NSM
could be separated out from the GUI to support
console users and environments where X may not
be available.
8 Apr
8 Apr
7:38 p.m.
On Fri, Apr 06, 2012 at 01:07:57PM -0700, J. Liles wrote:
On Fri, Apr 6, 2012 at 12:06 PM, Joel Roth
<joelz(a)pobox.com> wrote:
That's great to know. I also see that CPAN has a couple of
modules for handling OSC.
--
Joel Roth
On Wed, Apr 04, 2012 at 10:12:53PM +0200,
rosea.grammostola wrote:
FYI. This is already a matter of fact... the GUI communicates with nsmd via
OSC. nsmd can be run without the GUI and controlled via osc (there's a
program included in the distribution called send_osc to allow this kind of
thing to be done via shell scripts). Afaik, NSM gives us all we users need when it
comes to LAU session
management.... Correct me if I'm wrong.
It would be great if the core functionality of NSM
could be separated out from the GUI to support
console users and environments where X may not
be available.
9 Apr
9 Apr
5:28 p.m.
On 04/06/2012 09:06 PM, Joel Roth wrote:
On Wed, Apr 04, 2012 at 10:12:53PM +0200,
rosea.grammostola wrote:
So that's already the case. Anyway thanks for trying :) Only developers
are able to convince me on fundamental flaws of the NSM design atm. In
this regard, it might be good if JackSession developers speak out about
the current situation, now we have NSM and JackSession. They probably
see those fundamental flaws or disadvantages in NSM. Or they maybe see
particular advantages of JackSession or even NSM.
Let me summarize my personal findings as a JackSession and NSM user:
Personally I saw it as an advantage of JackSession, that it has JACK
involved and that it only needs the JACK dependency. After the comments
by Fons and by trying NSM myself, I think that it is an advantage of NSM
instead, that it is independent of JACK. It's more easy to add apps
without JACK support to the session and to keep apps with JACK support
outside the session (by purpose). It gives you as a user more freedom
and flexibility overall and so I think it's a better design choice.
These advantages out weights the disadvantage of having one extra
dependency to support NSM (liblo).
In terms of workflow, I prefer NSM above JackSession. Not only the fact
that it is possible to easily launch apps without session support
(without conf files), but also that it does what you expect from a
session manager, OOTB. Close applications, fast, easy and safe saving.
Quick and easy changing from one session to another etc.
The fact that NSM asks supported clients to act coherently and
predictable is another advantage. I think it gives you as a user a
simple and clear workflow. An disadvantage of this might be that a
little more is expected from the devs of the clients, but as far as I
understood that's isn't much extra effort to support it and also there
are no fundamental objections yet, apart from the fact apps which
doesn't have a centralized save location (qtractor), have more problems
with this. I think this is a problem in that app as others pointed out.
Moreover there are not many apps with this behavior.
In summary and to conclude: After using Ladish and especially
JackSession, I think NSM is the best solution for the session puzzle so
far and likely for the coming years. This is a personal user
perspective, devs could think otherwise, but I didn't see a good reason
for this so far.
Thanks. The list is yours again ;)
\r
Afaik, NSM gives us all we users need when it
comes to LAU session
management.... Correct me if I'm wrong.
It would be great if the core functionality of NSM
could be separated out from the GUI to support
console users and environments where X may not
be available.
6:03 p.m.
On Mon, Apr 09, 2012 at 05:27:54PM +0200, rosea.grammostola wrote:
Personally I saw it as an advantage of JackSession,
that it has JACK
involved and that it only needs the JACK dependency. After the comments
by Fons and by trying NSM myself, I think that it is an advantage of NSM
instead, that it is independent of JACK. It's more easy to add apps
without JACK support to the session and to keep apps with JACK support
outside the session (by purpose). It gives you as a user more freedom
and flexibility overall and so I think it's a better design choice.
These advantages out weights the disadvantage of having one extra
dependency to support NSM (liblo).
Liblo is *not* a dependency of any app using NSM. Since the NSM protocol
specifies the actual messages, an app can send an receive them whatever
code or library the developer prefers. In fact NSM does not add any
dependencies at all.
To ensure things stay like that, I'd like to see the following
added to the NSM specs:
* All communication is done using simple OSC messages,
* i.e. without using bundles or wildcards.
That way even the most basic OSC support would be enough to
use NSM. And with the protocol as it stands, nothing is lost.
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)
6:35 p.m.
On Mon, Apr 9, 2012 at 9:03 AM, Fons Adriaensen <fons(a)linuxaudio.org> wrote:
On Mon, Apr 09, 2012 at 05:27:54PM +0200,
rosea.grammostola wrote:
This is true. Liblo is not a hard dependency. Anything that can
send/receive OSC messages should work. It definitely doesn't use wildcards
and I haven't actually found a use for OSC wildcards yet period, so I don't
have a problem with officially avoiding them. Bundles are useful for some
things (especially when delivering a list like response, because OSC has no
more obvious way to indicate 'end of list'), and aren't very complicated at
the stream level (just ordinary messages preceded by something that says,
'hey, this is a bundle of such and such length'), but, yeah, I don't have
any idea how many of the OSC implementations out there support them. With
liblo, it's only *generating* the bundle that is complicated. Receiving it
is easy.The lowest common denominator here (that people are likely to
actually use) is probably the Python OSC implementation. And, anyway, the
current implementation doesn't use them for anything (if it did, it would
probably use them for the session list response [not something most clients
will even use] and the announce response/open pair [all clients use this
one]).
Personally I saw it as an advantage of
JackSession, that it has JACK
involved and that it only needs the JACK dependency. After the comments
by Fons and by trying NSM myself, I think that it is an advantage of NSM
instead, that it is independent of JACK. It's more easy to add apps
without JACK support to the session and to keep apps with JACK support
outside the session (by purpose). It gives you as a user more freedom
and flexibility overall and so I think it's a better design choice.
These advantages out weights the disadvantage of having one extra
dependency to support NSM (liblo).
Liblo is *not* a dependency of any app using NSM. Since the NSM protocol
specifies the actual messages, an app can send an receive them whatever
code or library the developer prefers. In fact NSM does not add any
dependencies at all.
To ensure things stay like that, I'd like to see the following
added to the NSM specs:
* All communication is done using simple OSC messages,
* i.e. without using bundles or wildcards.
That way even the most basic OSC support would be enough to
use NSM. And with the protocol as it stands, nothing is lost.
7:10 p.m.
On Mon, Apr 09, 2012 at 09:35:27AM -0700, J. Liles wrote:
This is true. Liblo is not a hard dependency. Anything
that can
send/receive OSC messages should work. It definitely doesn't use wildcards
and I haven't actually found a use for OSC wildcards yet period,
Same here... In all cases where I've wanted to say 'all' objects
of some sort (e.g. set all faders to 'off'), those objects are
indexed by integers anyway and not as part of the destination. So
all it takes is some 'escape' value such as -1.
so I don't
have a problem with officially avoiding them. Bundles are useful for some
things (especially when delivering a list like response, because OSC has no
more obvious way to indicate 'end of list'),
'[' and ']' in the format are used to start and end arrays, lists, etc..
and aren't very complicated at the stream level
True, but note that the ability to receive bundles implies honouring
timestamps. A library that does accept bundles but ignores timestamps
would be considered buggy. It's this that turns what could otherwise
be something very simple and minimal into a more complex affair,
requiring a different API and in theory also unbounded storage.
I never understood why the OSC designers combined bundling and
timestamping, as either of them is useful without the other.
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)
11 Apr
11 Apr
2:43 p.m.
It might be a good idea to discuss NSM (and it's implementation) and
compare it with other Session Managers, at LAC2012. Such a conference
could be a nice opportunity to share ideas to improve Linuxaudio session
management in general. Unfortunately I'm not able to attend this year.
For those who go, have fun! :)
Regards,
\r
3:18 p.m.
On 04/11/2012 08:42 AM, rosea.grammostola wrote:
It might be a good idea to discuss NSM (and it's
implementation) and
compare it with other Session Managers, at LAC2012. Such a conference
could be a nice opportunity to share ideas to improve Linuxaudio
session management in general. Unfortunately I'm not able to attend
this year.
For those who go, have fun! :)
Hey Dirk,
We'll miss you ! I still tell people about the fellow who approached me
on a train platform in Dublin and asked if I was Dave Phillips. :)
Well, I hope we'll see you next year, and I'll be sure to hoist a few
for you during the symposia.
Best,
dp
3:37 p.m.
On 04/11/2012 03:18 PM, Dave Phillips wrote:
Hey Dirk,
We'll miss you ! I still tell people about the fellow who approached me
on a train platform in Dublin and asked if I was Dave Phillips.
Hehe, I did the same when I saw Bono standing at Dublin central. He
still tells his friends about it to. Must feel good apparently, when
you're famous and people you have no clue about, recognize you in the
middle of a crowd :)
Have a good time!
4:31 p.m.
On Wed, 11 Apr 2012 15:36:30 +0200
"rosea.grammostola" <rosea.grammostola(a)gmail.com> wrote:
On 04/11/2012 03:18 PM, Dave Phillips wrote:
rosea.grammostola AKA Dublin's station stalker ;)
renato
Hey Dirk,
We'll miss you ! I still tell people about the fellow who
approached me on a train platform in Dublin and asked if I was Dave
Phillips.
Hehe, I did the same when I saw Bono standing at Dublin central.
6:32 p.m.
On Wed, Apr 11, 2012 at 5:42 AM, rosea.grammostola <
rosea.grammostola(a)gmail.com> wrote:
It might be a good idea to discuss NSM (and it's
implementation) and
compare it with other Session Managers, at LAC2012. Such a conference could
be a nice opportunity to share ideas to improve Linuxaudio session
management in general. Unfortunately I'm not able to attend this year.
For those who go, have fun! :)
Regards,
\r
Since I will not attending, those who do are recommended to print this out
and display it where it will be visible to the presenters in my absence:
http://www.quickmeme.com/meme/3oqu2r/
(/me was torn between this and "Not sure if stupid/or works for Microsoft")
Have fun y'all!
4 Apr
4 Apr
11:22 p.m.
On Wed, 2012-04-04 at 21:59 +0200, rosea.grammostola wrote:
[...]
I think it's essential to the discussion to get
the cards on the
table, so everybody can make up his own mind and decides which SM is the
best solution for the Linuxaudio session puzzle. It would be nice if we
could reach agreement on this, but it's a free world indeed. :)
With apologies in advance, here are my cards:
It would be nice if this list could stick to actual
developer/development problems. I just spent quite some time catching
up on this thread, and almost nothing at all of value (i.e. something
towards solving the/a problem) has been contributed since last I
checked. Mostly just a bunch of wannabe bureaucracy political noise,
which only obscures any actual technical points that might need fleshing
out (i.e. it's actively hurting, not helping). I doubt I'm the only one
interested in the problem who's just given up on this thread because the
signal:noise ratio is ridiculous.
Take the politics to LAU or something. The official resolution of the
User Committee on The Agreed-Upon Solution for LAD Session Management
will have zero impact on what developers actually implement, but
dragging the signal:noise ratio into the gutter might - though probably
not the impact you were hoping for.
-dr
5 Apr
5 Apr
12:45 a.m.
On 04/04/2012 11:22 PM, David Robillard wrote:
On Wed, 2012-04-04 at 21:59 +0200, rosea.grammostola
wrote: [...]
Thanks, with my apologies in advance for my reply. :)
I think it's essential to the discussion to
get the cards on the
table, so everybody can make up his own mind and decides which SM
is the best solution for the Linuxaudio session puzzle. It would be
nice if we could reach agreement on this, but it's a free world
indeed. :)
With apologies in advance, here are my cards:
It would be nice if this list could stick to actual
developer/development problems.
Of course this is the LAD list, so I don't post often on this list,
except for this topic, started by me and of importance for me.
I think this topic is a special case on LAD, because it's by far more
interesting for users to have a good SM implementation then for
developers. For musicians/ user it is a real problem when something
doesn't work or when a session API is implemented badly (technically
and/ or socially). Developers care much less.
But if you make such a strict border between devs and users, also in
such a topic, as you seem to suggest, I'm afraid we'll have to deal with
the same 'great-technical-design' but
'sorry-not-yet-usable-if-you-really-want-to-make-music' software issues
in the coming years on Linux.
Or in the case of session management,'great-minimal-design' but
'useless-because-you-can-only-use-a-few-apps-and-we-dont-have-a-problem-with-that-because-we-dont-use-it-ourselves'.
I'll tell you why this topic is important to me. I did a talk about
Linuxaudio. I can't tell you how much of a pain it was to get my stuff
together. It did cost me more then a *fulltime week, 10h a day* to be
able to show a more or less workable Linuxaudio workflow. Truly
ridiculous and it made me realize that JackSession is utopian (and
probably making music on Linux too) in this state.
It's nice to talk about software design side of Linuxaudio, but actually
working with it is a whole different story, I tell you...especially the
combination 'making music' and 'the modular approach'... (NSM seems to
change this quite a bit though)
But if you're only interested in technical stuff and academic discussion
about APIs, this might be not very interesting to read for you, my
apologies.
up on this thread, and almost nothing at all of value
(i.e.
something towards solving the/a problem) has been contributed since
last I checked. Mostly just a bunch of wannabe bureaucracy political
noise, which only obscures any actual technical points that might
need fleshing out (i.e. it's actively hurting, not helping). >
Take the politics to LAU or something.
Call it politics, or call it just an obvious part of the process of
implementing something like a session manager API, where a large part of
the community has to deal with. For me it's not politics in the sense
that I like to see API X supported, rather then API Y, don't get me
wrong. I just think it's important to get the real true (technical/ LAD
related) arguments on table, it helps already to get the picture clear
and to kill argumentation flaws, wrong suggestions and myths. That's in
the benefit for devs and users.
Regards,
\r
4 Apr
4 Apr
6:19 p.m.
On Wed, Apr 4, 2012 at 5:22 AM, Rui Nuno Capela <rncbc(a)rncbc.org> wrote:
On 04/04/2012 12:18 PM, rosea.grammostola wrote:
Are you seriously saying that the equivalent of doing:
if ( nsm_is_active )
save_here( file );
else
save_there( file );
Would require a complete rewrite and overhaul of your application? Say you
don't want to do it... That's fine. Say you don't like the NSM
design--that's fine too. But don't just make up wild hyperbole out of
laziness...
On 04/03/2012 07:04 PM, Rui Nuno Capela wrote:
speaking from qtractor pov.:
- level 0: minimal effort as it would be a probable and simple rephrasing
and/or adaptation of the code already in place for jack-session; also,
there's this osc branch somewhat lurking in svn to get readily merged and
apply for the NSM/OSC interface.
- level 1+: pervasive change and effort; almost brand new application
overhaul (iow. won't happen any time soon:) sorry.
now, i could suggest NSM API to be split in
levels of compliance and
restrictiveness, so to speak:
- level 0 :- clients just store/retrieve their own private state from a
supplied and independent session sub-directory; no GUI File menu
restrictions; no file location restrictions, no symlinks, no juggling,
no dupes, no sh*t.
- level 1+ :- anything that (may progressively?) imposes each one the
mentioned non-restrictions of level 0.
How much more effort will it be in terms of coding, to implement
'level-1' versus 'level-0'?
8:13 p.m.
On 04/04/2012 05:19 PM, J. Liles wrote:
On Wed, Apr 4, 2012 at 5:22 AM, Rui Nuno Capela <rncbc(a)rncbc.org
<mailto:rncbc@rncbc.org>> wrote:
On 04/04/2012 12:18 PM, rosea.grammostola wrote:
On 04/03/2012 07:04 PM, Rui Nuno Capela wrote:
now, i could suggest NSM API to be split in levels of
compliance and
restrictiveness, so to speak:
- level 0 :- clients just store/retrieve their own private
state from a
supplied and independent session sub-directory; no GUI File menu
restrictions; no file location restrictions, no symlinks, no
juggling,
no dupes, no sh*t.
- level 1+ :- anything that (may progressively?) imposes
each one the
mentioned non-restrictions of level 0.
How much more effort will it be in terms of coding, to implement
'level-1' versus 'level-0'?
speaking from qtractor pov.:
- level 0: minimal effort as it would be a probable and simple
rephrasing and/or adaptation of the code already in place for
jack-session; also, there's this osc branch somewhat lurking in svn
to get readily merged and apply for the NSM/OSC interface.
- level 1+: pervasive change and effort; almost brand new
application overhaul (iow. won't happen any time soon:) sorry.
Are you seriously saying that the equivalent of doing:
if ( nsm_is_active )
save_here( file );
else
save_there( file );
this is level 0, assuming "file" is the application private state file
Would require a complete rewrite and overhaul of your
application? Say
you don't want to do it... That's fine. Say you don't like the NSM
design--that's fine too. But don't just make up wild hyperbole out of
laziness...
the rewrite is about level 1+ (my nomenclature, i know:)
cheers
--
rncbc aka Rui Nuno Capela
rncbc(a)rncbc.org
10:48 p.m.
On Wed, Apr 04, 2012 at 09:19:57AM -0700, J. Liles wrote:
Are you seriously saying that the equivalent of
doing:
if ( nsm_is_active )
save_here( file );
else
save_there( file );
Would require a complete rewrite and overhaul of your application? Say you
don't want to do it... That's fine. Say you don't like the NSM
design--that's fine too. But don't just make up wild hyperbole out of
laziness...
:-)
A question: according to the docs, a client should consider itself
'managed' after receiving the reply to the 'announce' message. But
at that time it has no path to save anything 'New' or 'Load'ed.
If I understand the docs correctly, the 'open' message specifying
this path will follow immediately. But still this is a possible race
condition. So shouldn't a client consider itself managed only after
having received the first 'open' message ?
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 Apr
5 Apr
12:23 a.m.
On Wed, Apr 4, 2012 at 1:48 PM, Fons Adriaensen <fons(a)linuxaudio.org> wrote:
On Wed, Apr 04, 2012 at 09:19:57AM -0700, J. Liles
wrote:
Yes. Well, there's a bit of a fine distinction between being managed and
being part of the session. The application could conceivably receive a
'quit' message before the 'open' message, but that would never actually
happen in the current implementation and doesn't make a lot of sense
anyway. I think you're probably right in that for all practical purposes
'open' is the time to consider the application managed.
Are you seriously saying that the equivalent of
doing:
if ( nsm_is_active )
save_here( file );
else
save_there( file );
Would require a complete rewrite and overhaul of your application? Say
you
don't want to do it... That's fine. Say
you don't like the NSM
design--that's fine too. But don't just make up wild hyperbole out of
laziness...
:-)
A question: according to the docs, a client should consider itself
'managed' after receiving the reply to the 'announce' message. But
at that time it has no path to save anything 'New' or 'Load'ed.
If I understand the docs correctly, the 'open' message specifying
this path will follow immediately. But still this is a possible race
condition. So shouldn't a client consider itself managed only after
having received the first 'open' message ?
12:28 a.m.
On Wed, Apr 4, 2012 at 3:22 PM, J. Liles <malnourite(a)gmail.com> wrote:
On Wed, Apr 4, 2012 at 1:48 PM, Fons Adriaensen <fons(a)linuxaudio.org>wrote;wrote:
Also, to clairify, by 'quit' I mean SIGTERM and furthermore, there's
no
reason that the announce reply and the first open message can't be in an
OSC 'bundle' to guarantee they are processed at the same time (although the
current implementation doesn't use bundles).
On Wed, Apr 04, 2012 at 09:19:57AM -0700, J.
Liles wrote:
Yes. Well, there's a bit of a fine distinction between being managed and
being part of the session. The application could conceivably receive a
'quit' message before the 'open' message, but that would never actually
happen in the current implementation and doesn't make a lot of sense
anyway. I think you're probably right in that for all practical purposes
'open' is the time to consider the application managed.
Are you seriously saying that the equivalent of
doing:
if ( nsm_is_active )
save_here( file );
else
save_there( file );
Would require a complete rewrite and overhaul of your application? Say
you
don't want to do it... That's fine. Say
you don't like the NSM
design--that's fine too. But don't just make up wild hyperbole out of
laziness...
:-)
A question: according to the docs, a client should consider itself
'managed' after receiving the reply to the 'announce' message. But
at that time it has no path to save anything 'New' or 'Load'ed.
If I understand the docs correctly, the 'open' message specifying
this path will follow immediately. But still this is a possible race
condition. So shouldn't a client consider itself managed only after
having received the first 'open' message ?
4 Apr
4 Apr
3:25 p.m.
Am 4. April 2012 11:18 schrieb rosea.grammostola <rosea.grammostola(a)gmail.com>om>:
How much more effort will it be in terms of coding, to implement 'level-1'
versus 'level-0'?
For anyone who prefers to work with "apps-do-whatever-they-want" appraoch
or "we-have-zero-to-X-support-levels-so-you-dont-know-what-to-expect" ,
there are alternatives: JackSession, Lash, Ladish.
I would prefere at least *one* SM to have a clean and handy solution
and hope that is NSM.
I have to dig deeper into the NSM-API myself,
but currently it's not obvious to me,
why disabling a few menu-items and using
symlinks in the session-dir. is recognized as
impregnable obstacle.
--
E.R.
3:51 p.m.
On Wed, Apr 04, 2012 at 01:25:02PM +0000, Emanuel Rumpf wrote:
For anyone who prefers to work with
"apps-do-whatever-they-want" appraoch
or "we-have-zero-to-X-support-levels-so-you-dont-know-what-to-expect" ,
there are alternatives: JackSession, Lash, Ladish.
I would prefere at least *one* SM to have a clean and handy solution
votes++
and hope that is NSM.
I have to dig deeper into the NSM-API myself,
but currently it's not obvious to me,
why disabling a few menu-items and using
symlinks in the session-dir. is recognized as
impregnable obstacle.
I fail to see that as well. And I may be an unrecoverable
individualist, but if ever I add session management to any
app then that app will obey the NSM rules or very similar
ones if the session manager is not NSM - it is the obvious
thing to do if you want something that works.
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)
4:38 p.m.
On 04/04/2012 03:51 PM, Fons Adriaensen wrote:
if ever I add session management to any
app then that app will obey the NSM rules or very similar
ones if the session manager is not NSM - it is the obvious
thing to do if you want something that works.
Could you elaborate your reasons for this, for those who don't see this
as obvious?
Regards,
\r
6:31 p.m.
On Wed, Apr 04, 2012 at 04:37:59PM +0200, rosea.grammostola wrote:
Could you elaborate your reasons for this, for those
who don't see this
as obvious?
I could. But it wouldn't help anyone.
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 Apr
5 Apr
1:25 a.m.
On Tue, 2012-04-03 at 18:04 +0100, Rui Nuno Capela wrote:
[...]
ardour gets all its stuff under one own session
directory, on a per
session/project basis, iirc just like NSM mandates,
bbbuuuuuut...:) making that one and the same directory as from an
outsider/independent session manager like NSM is asking for a lot of
file and symlink juggling, if you ask me
i'm not an expert in ardour internals, someone else could chime in and
help me here.
I don't know what you are trying to say. "One and the same directory as
from an outsider/independent session manager"? Huh?
A directory of files is a directory of files. The format Ardour would
save to inside of a session is precisely the same format it already
saves in, perhaps with some things being links.
I can guarantee you that much, because if it had to be different,
Ardour, like presumably most apps, simply would never implement it...
> my feeling again is that the effort to comply
with NSM isn't, won't be
> so easy for any lass-than-simple-textbook-like client examples
Not really. Qtractor is just a weirdo edge case. You seem to be trying
to paint the "mandates" of NSM as deeply imposing requirements, but
they're not. Quite the opposite, really, anything else would certainly
be *far* more imposing and complicated. That's kind of the point.
It's not really worth it to care about this case from an SM perspective
since it's rare, easily fixable, inherently un-archivable, and there's
no palatable solution for dealing with apps like this anyway. The
obvious one would be to have a special 'deep save', but then... if the
app implements that, it can just save that way when running in an SM
every time. Therefore it's a non-issue (heh) for SM.
-dr
1:16 p.m.
On 04/05/2012 12:25 AM, David Robillard wrote:
On Tue, 2012-04-03 at 18:04 +0100, Rui Nuno Capela
wrote:
[...]
ok then.
but again, i was implying about the NSM session directory location
restriction, not ardour's session/project directory/file format.
let me thrown in some more ;)
from what I read on the NSM User & API specs. you can only create new,
open and save NSM-managed sessions as in each participating client
project's sub-directories. existing individual projects are out of the
picture. unless you "cheat" the NSM o.O
iow. what if, assuming Ardour were about a fully-compliant NSM client
and you want to open an existing Ardour session, one you've been working
hard previously but stand-lone ie. outside the NSM umbrella? i read that
you'll have to copy or move all ardour's session files _manually_ first,
or symlink at best, into the NSM's central/root directory and guess what
and where. that's the kind of "cheat" or "juggling" i was telling
you
about :)
otoh, if its native(gui file menu)-open is available, it would be dead
simple to get an existing qtractor project into a NSM session and
behold: later, the NSM would just save (a new stanza) of the qtractor
session/state file under the SM's designated central directory location
and that's perfect for qtractor, see? because all qtractor media content
files are external and independent of the state file. and if you (the
user) selects the archive/zip bundle format (.qtz suffix) as default,
then we'll get *all* qtractor project stuff under the nominated NSM
session directory tree (already compressed into one single archive/zip
file, though)
perhaps, automatic symlinking of all the external files could be also
doable at the NSM-Save instant, 'coz qtractor state is, among other
important things, an inventory map of all those files anyway--some
invasive coding required, though ;)
looks like, after all, that qtractor could stand compliant to both NSM
levels 0 and 1+, in one fine blow, only if those file menu restrictions
get subverted or just plainly ignored:o) and all the code to comply with
the basic NSM API announce, open, save, close... gets eventually coded
in, of course
aha. this seems the case for "edgy" applications like qtractor, when
their own file new, open, save, and save as... menu operations are made
completely orthogonal and independent of any general SM open/save ones.
try that with the not-so-edgy (mainstream?) applications ;)
cheers
--
rncbc aka Rui Nuno Capela
rncbc(a)rncbc.org
ardour gets all its stuff under one own session
directory, on a per
session/project basis, iirc just like NSM mandates,
bbbuuuuuut...:) making that one and the same directory as from an
outsider/independent session manager like NSM is asking for a lot of
file and symlink juggling, if you ask me
i'm not an expert in ardour internals, someone else could chime in and
help me here.
I don't know what you are trying to say. "One and the same directory as
from an outsider/independent session manager"? Huh?
A directory of files is a directory of files. The format Ardour would
save to inside of a session is precisely the same format it already
saves in, perhaps with some things being links.
I can guarantee you that much, because if it had to be different,
Ardour, like presumably most apps, simply would never implement it...
2:16 p.m.
On Thu, Apr 05, 2012 at 12:14:03PM +0100, Rui Nuno Capela wrote:
from what I read on the NSM User & API specs. you
can only create new,
open and save NSM-managed sessions as in each participating client
project's sub-directories. existing individual projects are out of the
picture. unless you "cheat" the NSM o.O
iow. what if, assuming Ardour were about a fully-compliant NSM client
and you want to open an existing Ardour session, one you've been working
hard previously but stand-lone ie. outside the NSM umbrella? i read that
you'll have to copy or move all ardour's session files _manually_ first,
or symlink at best, into the NSM's central/root directory and guess what
and where. that's the kind of "cheat" or "juggling" i was telling
you
about :)
You have a project of application A, created without NSM, and the project
is saved in P (a single file, or a directory).
You want to use P as part of an NSM session. Note that this scenario means
that A has some button to select if it runs under NSM or not. Let's assume
that the default is to run stand-alone.
There are two ways to do this:
1. ('Load' and 'New' are disabled when running NSM)
* Start A.
* Load P.
* Connect A to NSM. Application A will receive a path indicating
where to save its current project. The actual message is 'open',
but since there is nothing to open at the given path the only
sensible thing to do is to put the current project there.
App. A can do so immediately, and then continue as normal.
The whole thing amounts to a 'Save as' [*] with the name given
by NSM instead of the user. So it's really nothing new.
2. ('Load' and 'New' are not disabled but the application knows
how to handle then when running under NSM)
* Start A.
* Connect A to NSM. App. A will receive a path indicating where to
save the its project. Since A is now running under NSM, it remembers
this path as the 'current project' even when it loads another one,
or creates a complete new one (under these condition A is allowed
to have 'Load' and 'New' menu entries).
* Load P. App A knows that it should not save to P, but to the path
given by NSM. To keep things simple, it could copy P to that path
immediately and then continue as normal. Again this is essentially
a 'Save as'.
The only difference between the two is that in (2) the second and
third steps are swapped.
No 'manual' user action is required in either case.
Ciao,
[*] 'Save as' interpreted as most apps would, not as Ardour does it.
In Ardour, 'Save as' does not create a new project but a snapshot,
while setting the current name to that snapshot.
--
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)
4:18 p.m.
On 04/05/2012 01:16 PM, Fons Adriaensen wrote:
On Thu, Apr 05, 2012 at 12:14:03PM +0100, Rui Nuno
Capela wrote:
so true, and ain't that something? you actually need the native-open and
save(as...) commands enabled after all o.O
i rest my case ;)
cheers
--
rncbc aka Rui Nuno Capela
rncbc(a)rncbc.org
from what I read on the NSM User& API specs.
you can only create new,
open and save NSM-managed sessions as in each participating client
project's sub-directories. existing individual projects are out of the
picture. unless you "cheat" the NSM o.O
iow. what if, assuming Ardour were about a fully-compliant NSM client
and you want to open an existing Ardour session, one you've been working
hard previously but stand-lone ie. outside the NSM umbrella? i read that
you'll have to copy or move all ardour's session files _manually_ first,
or symlink at best, into the NSM's central/root directory and guess what
and where. that's the kind of "cheat" or "juggling" i was telling
you
about :)
You have a project of application A, created without NSM, and the project
is saved in P (a single file, or a directory).
You want to use P as part of an NSM session. Note that this scenario means
that A has some button to select if it runs under NSM or not. Let's assume
that the default is to run stand-alone.
There are two ways to do this:
1. ('Load' and 'New' are disabled when running NSM)
* Start A.
* Load P.
* Connect A to NSM. Application A will receive a path indicating
where to save its current project. The actual message is 'open',
but since there is nothing to open at the given path the only
sensible thing to do is to put the current project there.
App. A can do so immediately, and then continue as normal.
The whole thing amounts to a 'Save as' [*] with the name given
by NSM instead of the user. So it's really nothing new.
2. ('Load' and 'New' are not disabled but the application knows
how to handle then when running under NSM)
* Start A.
* Connect A to NSM. App. A will receive a path indicating where to
save the its project. Since A is now running under NSM, it remembers
this path as the 'current project' even when it loads another one,
or creates a complete new one (under these condition A is allowed
to have 'Load' and 'New' menu entries).
* Load P. App A knows that it should not save to P, but to the path
given by NSM. To keep things simple, it could copy P to that path
immediately and then continue as normal. Again this is essentially
a 'Save as'.
The only difference between the two is that in (2) the second and
third steps are swapped.
No 'manual' user action is required in either case.
[*] 'Save as' interpreted as most apps would, not as Ardour does it.
In Ardour, 'Save as' does not create a new project but a snapshot,
while setting the current name to that snapshot.
4:48 p.m.
On Thu, Apr 05, 2012 at 03:19:24PM +0100, Rui Nuno Capela wrote:
On 04/05/2012 01:16 PM, Fons Adriaensen wrote:
No, where do you get that ? Did you actually read what you comment on
and think about it for a second or two ? In case (1) both are disabled
while in managed mode. In case (2) 'Load' (or 'Open') is enabled (but
behaves slightly differently) and 'Save as' is disabled (in the menu,
the function is still used, to save to the path given by NSM).
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)
On Thu, Apr 05, 2012 at 12:14:03PM +0100, Rui
Nuno Capela wrote:
so true, and ain't that something? you actually need the native-open and
save(as...) commands enabled after all o.O from what I read on the NSM User& API specs.
you can only create new,
open and save NSM-managed sessions as in each participating client
project's sub-directories. existing individual projects are out of the
picture. unless you "cheat" the NSM o.O
iow. what if, assuming Ardour were about a fully-compliant NSM client
and you want to open an existing Ardour session, one you've been working
hard previously but stand-lone ie. outside the NSM umbrella? i read that
you'll have to copy or move all ardour's session files _manually_ first,
or symlink at best, into the NSM's central/root directory and guess what
and where. that's the kind of "cheat" or "juggling" i was telling
you
about :)
You have a project of application A, created without NSM, and the project
is saved in P (a single file, or a directory).
You want to use P as part of an NSM session. Note that this scenario means
that A has some button to select if it runs under NSM or not. Let's assume
that the default is to run stand-alone.
There are two ways to do this:
1. ('Load' and 'New' are disabled when running NSM)
* Start A.
* Load P.
* Connect A to NSM. Application A will receive a path indicating
where to save its current project. The actual message is 'open',
but since there is nothing to open at the given path the only
sensible thing to do is to put the current project there.
App. A can do so immediately, and then continue as normal.
The whole thing amounts to a 'Save as' [*] with the name given
by NSM instead of the user. So it's really nothing new.
2. ('Load' and 'New' are not disabled but the application knows
how to handle then when running under NSM)
* Start A.
* Connect A to NSM. App. A will receive a path indicating where to
save the its project. Since A is now running under NSM, it remembers
this path as the 'current project' even when it loads another one,
or creates a complete new one (under these condition A is allowed
to have 'Load' and 'New' menu entries).
* Load P. App A knows that it should not save to P, but to the path
given by NSM. To keep things simple, it could copy P to that path
immediately and then continue as normal. Again this is essentially
a 'Save as'.
The only difference between the two is that in (2) the second and
third steps are swapped.
No 'manual' user action is required in either case.
[*] 'Save as' interpreted as most apps would, not as Ardour does it.
In Ardour, 'Save as' does not create a new project but a snapshot,
while setting the current name to that snapshot.
6:19 p.m.
On 04/05/2012 03:48 PM, Fons Adriaensen wrote:
On Thu, Apr 05, 2012 at 03:19:24PM +0100, Rui Nuno
Capela wrote:
ah ok, sorry. scrap (1) then
re. (2) then i concur with you when "Open" and "Save(As...)" shall be
enabled *but* having different code-paths, behavior or internal
semantics if you prefer, when in "managed" than in native/original aka.
"non-managed" modes. chalked!
we might disagree however on that "slightly" part, though. i understand
that's behavior as seen from user pov. but under the hood things might
just not be that "slight"... the usual ymmv applies ;)
ps. i know you're not found of jack-session Fons, but ntl. fwiw.
qtractor has been making that distinction when serving jack-session
requests, for almost 2 years now :P
cheers
--
rncbc aka Rui Nuno Capela
rncbc(a)rncbc.org
On 04/05/2012 01:16 PM, Fons Adriaensen wrote:
No, where do you get that ? Did you actually read what you comment on
and think about it for a second or two ? In case (1) both are disabled
while in managed mode. In case (2) 'Load' (or 'Open') is enabled (but
behaves slightly differently) and 'Save as' is disabled (in the menu,
the function is still used, to save to the path given by NSM).
On Thu, Apr 05, 2012 at 12:14:03PM +0100, Rui
Nuno Capela wrote:
so true, and ain't that something? you actually need the native-open and
save(as...) commands enabled after all o.O from what I read on the NSM User& API
specs. you can only create new,
open and save NSM-managed sessions as in each participating client
project's sub-directories. existing individual projects are out of the
picture. unless you "cheat" the NSM o.O
iow. what if, assuming Ardour were about a fully-compliant NSM client
and you want to open an existing Ardour session, one you've been working
hard previously but stand-lone ie. outside the NSM umbrella? i read that
you'll have to copy or move all ardour's session files _manually_ first,
or symlink at best, into the NSM's central/root directory and guess what
and where. that's the kind of "cheat" or "juggling" i was telling
you
about :)
You have a project of application A, created without NSM, and the project
is saved in P (a single file, or a directory).
You want to use P as part of an NSM session. Note that this scenario means
that A has some button to select if it runs under NSM or not. Let's assume
that the default is to run stand-alone.
There are two ways to do this:
1. ('Load' and 'New' are disabled when running NSM)
* Start A.
* Load P.
* Connect A to NSM. Application A will receive a path indicating
where to save its current project. The actual message is 'open',
but since there is nothing to open at the given path the only
sensible thing to do is to put the current project there.
App. A can do so immediately, and then continue as normal.
The whole thing amounts to a 'Save as' [*] with the name given
by NSM instead of the user. So it's really nothing new.
2. ('Load' and 'New' are not disabled but the application knows
how to handle then when running under NSM)
* Start A.
* Connect A to NSM. App. A will receive a path indicating where to
save the its project. Since A is now running under NSM, it remembers
this path as the 'current project' even when it loads another one,
or creates a complete new one (under these condition A is allowed
to have 'Load' and 'New' menu entries).
* Load P. App A knows that it should not save to P, but to the path
given by NSM. To keep things simple, it could copy P to that path
immediately and then continue as normal. Again this is essentially
a 'Save as'.
The only difference between the two is that in (2) the second and
third steps are swapped.
No 'manual' user action is required in either case.
[*] 'Save as' interpreted as most apps would, not as Ardour does it.
In Ardour, 'Save as' does not create a new project but a snapshot,
while setting the current name to that snapshot.
7:10 p.m.
On Thu, 2012-04-05 at 17:20 +0100, Rui Nuno Capela wrote:
[...]
re. (2) then i concur with you when "Open"
and "Save(As...)" shall be
enabled *but* having different code-paths, behavior or internal
semantics if you prefer, when in "managed" than in native/original aka.
"non-managed" modes. chalked!
?
The app performing an action similar or identical to what "Save As"
might do is a completely different thing to the "Save As" menu item
being available to the user...
-dr
7:48 p.m.
On Thu, 2012-04-05 at 12:14 +0100, Rui Nuno Capela wrote:
On 04/05/2012 12:25 AM, David Robillard wrote:
> On Tue, 2012-04-03 at 18:04 +0100, Rui Nuno Capela wrote:
> [...]
>> ardour gets all its stuff under one own session directory, on a per
>> session/project basis, iirc just like NSM mandates,
>>
>> bbbuuuuuut...:) making that one and the same directory as from an
>> outsider/independent session manager like NSM is asking for a lot of
>> file and symlink juggling, if you ask me
[...]
> A directory of files is a directory of files.
The format Ardour would
> save to inside of a session is precisely the same format it already
> saves in, perhaps with some things being links.
[...]
ok then.
but again, i was implying about the NSM session directory location
restriction, not ardour's session/project directory/file format.
... You specifically asked for input about Ardour's directories.
You keep calling the *goal* here a "restriction". Look, if you want to
just save an XML file with references to files who knows where, feel
free. Nobody is going to break in to your house and hold a gun to your
head and make you do otherwise.
However, then any session containing qtractor will be fragile and
unarchivable. Why? Because the way you saved INHERENTLY makes that so.
This isn't some arbitrary NSM "restriction" to make Rui Nuno Capela's
life miserable, it's simply a necessary condition to make the desired
behaviour possible.
iow. what if, assuming Ardour were about a
fully-compliant NSM client
and you want to open an existing Ardour session, one you've been working
hard previously but stand-lone ie. outside the NSM umbrella? i read that
you'll have to copy or move all ardour's session files _manually_ first,
or symlink at best, into the NSM's central/root directory and guess what
and where. that's the kind of "cheat" or "juggling" i was telling
you
about :)
I agree that "open" should clearly work. The same amount of juggling
would have to happen regardless.
otoh, if its native(gui file menu)-open is available,
it would be dead
simple to get an existing qtractor project into a NSM session and
behold: later, the NSM would just save (a new stanza) of the qtractor
session/state file under the SM's designated central directory location
and that's perfect for qtractor, see? because all qtractor media content
files are external and independent of the state file. and if you (the
user) selects the archive/zip bundle format (.qtz suffix) as default,
then we'll get *all* qtractor project stuff under the nominated NSM
session directory tree (already compressed into one single archive/zip
file, though)
Assuming, conveniently, that all existing sessions are not archived
(.qtz) and all SM ones are. Otherwise, it's the exact same situation as
any other program. Notably, in this scheme, it's exactly the same for
any qtractor session saved within the SM. Same as Ardour but you tarred
it.
perhaps, automatic symlinking of all the external
files could be also
doable at the NSM-Save instant, 'coz qtractor state is, among other
important things, an inventory map of all those files anyway--some
invasive coding required, though ;)
looks like, after all, that qtractor could stand compliant to both NSM
levels 0 and 1+, in one fine blow, only if those file menu restrictions
get subverted or just plainly ignored:o) and all the code to comply with
the basic NSM API announce, open, save, close... gets eventually coded
in, of course
One fine blow that just so happens to be qtractor *not* saving in the
way you are so vehemently defending ;)
aha. this seems the case for "edgy"
applications like qtractor, when
their own file new, open, save, and save as... menu operations are made
completely orthogonal and independent of any general SM open/save ones.
try that with the not-so-edgy (mainstream?) applications ;)
It's not any different for any applications, loading existing stuff is
loading existing stuff. Things will indeed need to be copied or moved.
Unfortunate, perhaps, but necessary.
Your knee-jerk desire to defend qtractor's saving scheme at all costs
with a death-by-emoticon blitzkrieg is obscuring the fact that all of
this is inherent to session management. Qtractor has problems with it
because qtractor has problems with it. There is no working scheme
qtractor would have less problems with, because they are inherent
problems with qtractor + SM, not the SM itself.
Back in the realm of "solving problems" rather than "inflating egos",
there are two approaches you can use:
1) Completely save everything within the SM directory
2) Make your XML file point to links in the SM directory which point to
the configured store location
Sound familiar? It should, because it's precisely what every other app
has to do to refer to "external files". Qtractor just uses every file
as external files.
Of course, number 2 is completely pointless and silly unless sessions
share these files, but that doesn't really matter. The solution is the
same in any case.
You may not particularly like this because qtractor does not currently
save in either way, meaning you have to implement a new saving scheme,
but... well, qtractor simply doesn't currently save in a way that makes
SM work. To make it do so, yep, obviously gonna be a bit of work,
because it doesn't right now.
If you don't want to support it, then simply don't support it, but don't
try to paint that as a failing of the SM. It's not.
-dr
8:14 p.m.
On Thu, Apr 5, 2012 at 10:48 AM, David Robillard <d(a)drobilla.net> wrote:
On Thu, 2012-04-05 at 12:14 +0100, Rui Nuno Capela
wrote:
Dealing with existing projects is what the optional "Import to Session"
and
"Export from Session" commands are there for. These are basically Open and
Save As but with *defined* semantics.
Anyway, FWIW the way I imported all my pre-existing project to NSM was very
simple:
1) Create a new session and add all the clients you used in your
non-managed setup.
2) Close that session and overwrite the the uniquely named project
files/directories that the NSM clients have created with the ones from your
non-managed-setup
3) Open the project and restore JACK connections (either manually or with
some other patchbay) and save so that JACKPatch will know the graph.
4) Rinse and repeat for other pre-existing projects.
Since the system was designed to work with the Unix files/directories model
(instead of e.g. a database), I don't consider the user mv'ing, symlinking
etc to be hacks, but just normal usage.
Depending on how organized your pre-existing projects were, much of this
can be automated with scripting. If a client implements an Import to
Session menu option, then basically it would just have to do the cp or mv
itself (or if it lacks heavy state, then just open the file and be prepared
to save it under the NSM path when the time comes.) But the SM has nothing
to do with it.
On 04/05/2012 12:25 AM, David Robillard wrote:
> On Tue, 2012-04-03 at 18:04 +0100, Rui Nuno Capela wrote:
> [...]
>> ardour gets all its stuff under one own session directory, on a per
>> session/project basis, iirc just like NSM mandates,
>>
>> bbbuuuuuut...:) making that one and the same directory as from an
>> outsider/independent session manager like NSM is asking for a lot of
>> file and symlink juggling, if you ask me
[...]
> A directory of files is a directory of
files. The format Ardour would
> save to inside of a session is precisely the same format it already
> saves in, perhaps with some things being links.
[...]
ok then.
but again, i was implying about the NSM session directory location
restriction, not ardour's session/project directory/file format.
... You specifically asked for input about Ardour's directories.
You keep calling the *goal* here a "restriction". Look, if you want to
just save an XML file with references to files who knows where, feel
free. Nobody is going to break in to your house and hold a gun to your
head and make you do otherwise.
However, then any session containing qtractor will be fragile and
unarchivable. Why? Because the way you saved INHERENTLY makes that so.
This isn't some arbitrary NSM "restriction" to make Rui Nuno Capela's
life miserable, it's simply a necessary condition to make the desired
behaviour possible.
iow. what if, assuming Ardour were about a
fully-compliant NSM client
and you want to open an existing Ardour session, one you've been working
hard previously but stand-lone ie. outside the NSM umbrella? i read that
you'll have to copy or move all ardour's session files _manually_ first,
or symlink at best, into the NSM's central/root directory and guess what
and where. that's the kind of "cheat" or "juggling" i was telling
you
about :)
I agree that "open" should clearly work. The same amount of juggling
would have to happen regardless.
otoh, if its native(gui file menu)-open is
available, it would be dead
simple to get an existing qtractor project into a NSM session and
behold: later, the NSM would just save (a new stanza) of the qtractor
session/state file under the SM's designated central directory location
and that's perfect for qtractor, see? because all qtractor media content
files are external and independent of the state file. and if you (the
user) selects the archive/zip bundle format (.qtz suffix) as default,
then we'll get *all* qtractor project stuff under the nominated NSM
session directory tree (already compressed into one single archive/zip
file, though)
Assuming, conveniently, that all existing sessions are not archived
(.qtz) and all SM ones are. Otherwise, it's the exact same situation as
any other program. Notably, in this scheme, it's exactly the same for
any qtractor session saved within the SM. Same as Ardour but you tarred
it.
perhaps, automatic symlinking of all the external
files could be also
doable at the NSM-Save instant, 'coz qtractor state is, among other
important things, an inventory map of all those files anyway--some
invasive coding required, though ;)
looks like, after all, that qtractor could stand compliant to both NSM
levels 0 and 1+, in one fine blow, only if those file menu restrictions
get subverted or just plainly ignored:o) and all the code to comply with
the basic NSM API announce, open, save, close... gets eventually coded
in, of course
One fine blow that just so happens to be qtractor *not* saving in the
way you are so vehemently defending ;)
aha. this seems the case for "edgy"
applications like qtractor, when
their own file new, open, save, and save as... menu operations are made
completely orthogonal and independent of any general SM open/save ones.
try that with the not-so-edgy (mainstream?) applications ;)
It's not any different for any applications, loading existing stuff is
loading existing stuff. Things will indeed need to be copied or moved.
Unfortunate, perhaps, but necessary.
Your knee-jerk desire to defend qtractor's saving scheme at all costs
with a death-by-emoticon blitzkrieg is obscuring the fact that all of
this is inherent to session management. Qtractor has problems with it
because qtractor has problems with it. There is no working scheme
qtractor would have less problems with, because they are inherent
problems with qtractor + SM, not the SM itself.
Back in the realm of "solving problems" rather than "inflating
egos",
there are two approaches you can use:
1) Completely save everything within the SM directory
2) Make your XML file point to links in the SM directory which point to
the configured store location
Sound familiar? It should, because it's precisely what every other app
has to do to refer to "external files". Qtractor just uses every file
as external files.
Of course, number 2 is completely pointless and silly unless sessions
share these files, but that doesn't really matter. The solution is the
same in any case.
You may not particularly like this because qtractor does not currently
save in either way, meaning you have to implement a new saving scheme,
but... well, qtractor simply doesn't currently save in a way that makes
SM work. To make it do so, yep, obviously gonna be a bit of work,
because it doesn't right now.
If you don't want to support it, then simply don't support it, but don't
try to paint that as a failing of the SM. It's not.
-dr
8:56 p.m.
On Thu, 2012-04-05 at 11:14 -0700, J. Liles wrote:
[...]
Dealing with existing projects is what the optional "Import to
Session" and "Export from Session" commands are there for. These are
basically Open and Save As but with *defined* semantics.
My mistake, I was just going by what Rui wrote and didn't refer back.
Anyway, FWIW the way I imported all my pre-existing
project to NSM was
very simple:
1) Create a new session and add all the clients you used in your
non-managed setup.
2) Close that session and overwrite the the uniquely named project
files/directories that the NSM clients have created with the ones from
your non-managed-setup
3) Open the project and restore JACK connections (either manually or
with some other patchbay) and save so that JACKPatch will know the
graph.
4) Rinse and repeat for other pre-existing projects.
Since the system was designed to work with the Unix files/directories
model (instead of e.g. a database), I don't consider the user mv'ing,
symlinking etc to be hacks, but just normal usage.
Depending on how organized your pre-existing projects were, much of
this can be automated with scripting. If a client implements an Import
to Session menu option, then basically it would just have to do the cp
or mv itself (or if it lacks heavy state, then just open the file and
be prepared to save it under the NSM path when the time comes.) But
the SM has nothing to do with it.
Makes sense.
From a user friendly POV it would of course be nice if
apps implement
that, though, as you say, the SM has nothing to do with it. That
the
actual stuff that needs to happen is something the user *could* easily
do if they wanted to is a good thing.
-dr
10:38 p.m.
On 04/05/2012 07:14 PM, J. Liles wrote:
On Thu, Apr 5, 2012 at 10:48 AM, David Robillard <d(a)drobilla.net
<mailto:d@drobilla.net>> wrote:
On Thu, 2012-04-05 at 12:14 +0100, Rui Nuno Capela wrote:
so we all agree now that gui file menu "open" and "save as ..." should
be enabled but with an "import from..." and "export to..." semantics
respectively, when in managed mode
that concludes the discussion, on my call at least.
byee
--
rncbc aka Rui Nuno Capela
rncbc(a)rncbc.org
On 04/05/2012 12:25 AM, David Robillard wrote:
> On Tue, 2012-04-03 at 18:04 +0100, Rui Nuno Capela wrote:
> [...]
>> ardour gets all its stuff under one own session directory, on
a per
>> session/project basis, iirc just like
NSM mandates,
>>
>> bbbuuuuuut...:) making that one and the same directory as from an
>> outsider/independent session manager like NSM is asking for a
lot of
>> file and symlink juggling, if you ask me
[...]
> A directory of files is a directory of
files. The format
Ardour would
> save to inside of a session is precisely the
same format it already
> saves in, perhaps with some things being links.
[...]
ok then.
but again, i was implying about the NSM session directory location
restriction, not ardour's session/project directory/file format.
... You specifically asked for input about Ardour's directories.
You keep calling the *goal* here a "restriction". Look, if you want to
just save an XML file with references to files who knows where, feel
free. Nobody is going to break in to your house and hold a gun to your
head and make you do otherwise.
However, then any session containing qtractor will be fragile and
unarchivable. Why? Because the way you saved INHERENTLY makes that so.
This isn't some arbitrary NSM "restriction" to make Rui Nuno
Capela's
life miserable, it's simply a necessary condition to make the desired
behaviour possible.
iow. what if, assuming Ardour were about a
fully-compliant NSM client
and you want to open an existing Ardour session, one you've been
working
hard previously but stand-lone ie. outside the
NSM umbrella? i
read that
you'll have to copy or move all ardour's
session files _manually_
first,
or symlink at best, into the NSM's
central/root directory and
guess what
and where. that's the kind of
"cheat" or "juggling" i was telling you
about :)
I agree that "open" should clearly work. The same amount of juggling
would have to happen regardless.
otoh, if its native(gui file menu)-open is
available, it would be
dead
simple to get an existing qtractor project into a
NSM session and
behold: later, the NSM would just save (a new stanza) of the qtractor
session/state file under the SM's designated central directory
location
and that's perfect for qtractor, see? because
all qtractor media
content
files are external and independent of the state
file. and if you (the
user) selects the archive/zip bundle format (.qtz suffix) as default,
then we'll get *all* qtractor project stuff under the nominated NSM
session directory tree (already compressed into one single
archive/zip
file, though)
Assuming, conveniently, that all existing sessions are not archived
(.qtz) and all SM ones are. Otherwise, it's the exact same situation as
any other program. Notably, in this scheme, it's exactly the same for
any qtractor session saved within the SM. Same as Ardour but you tarred
it.
perhaps, automatic symlinking of all the external
files could be also
doable at the NSM-Save instant, 'coz qtractor state is, among other
important things, an inventory map of all those files anyway--some
invasive coding required, though ;)
looks like, after all, that qtractor could stand compliant to
both NSM
levels 0 and 1+, in one fine blow, only if those
file menu
restrictions
get subverted or just plainly ignored:o) and all
the code to
comply with
the basic NSM API announce, open, save, close...
gets eventually
coded
in, of course
One fine blow that just so happens to be qtractor *not* saving in the
way you are so vehemently defending ;)
aha. this seems the case for "edgy"
applications like qtractor, when
their own file new, open, save, and save as... menu operations
are made
completely orthogonal and independent of any
general SM open/save
ones.
try that with the not-so-edgy (mainstream?) applications ;)
It's not any different for any applications, loading existing stuff is
loading existing stuff. Things will indeed need to be copied or moved.
Unfortunate, perhaps, but necessary.
Your knee-jerk desire to defend qtractor's saving scheme at all costs
with a death-by-emoticon blitzkrieg is obscuring the fact that all of
this is inherent to session management. Qtractor has problems with it
because qtractor has problems with it. There is no working scheme
qtractor would have less problems with, because they are inherent
problems with qtractor + SM, not the SM itself.
Back in the realm of "solving problems" rather than "inflating
egos",
there are two approaches you can use:
1) Completely save everything within the SM directory
2) Make your XML file point to links in the SM directory which point to
the configured store location
Sound familiar? It should, because it's precisely what every other app
has to do to refer to "external files". Qtractor just uses every file
as external files.
Of course, number 2 is completely pointless and silly unless sessions
share these files, but that doesn't really matter. The solution is the
same in any case.
You may not particularly like this because qtractor does not currently
save in either way, meaning you have to implement a new saving scheme,
but... well, qtractor simply doesn't currently save in a way that makes
SM work. To make it do so, yep, obviously gonna be a bit of work,
because it doesn't right now.
If you don't want to support it, then simply don't support it, but don't
try to paint that as a failing of the SM. It's not.
-dr
Dealing with existing projects is what the optional "Import to Session"
and "Export from Session" commands are there for. These are basically
Open and Save As but with *defined* semantics.
Anyway, FWIW the way I imported all my pre-existing project to NSM was
very simple:
1) Create a new session and add all the clients you used in your
non-managed setup.
2) Close that session and overwrite the the uniquely named project
files/directories that the NSM clients have created with the ones from
your non-managed-setup
3) Open the project and restore JACK connections (either manually or
with some other patchbay) and save so that JACKPatch will know the graph.
4) Rinse and repeat for other pre-existing projects.
Since the system was designed to work with the Unix files/directories
model (instead of e.g. a database), I don't consider the user mv'ing,
symlinking etc to be hacks, but just normal usage.
Depending on how organized your pre-existing projects were, much of this
can be automated with scripting. If a client implements an Import to
Session menu option, then basically it would just have to do the cp or
mv itself (or if it lacks heavy state, then just open the file and be
prepared to save it under the NSM path when the time comes.) But the SM
has nothing to do with it.
8:11 p.m.
On Thu, 05 Apr 2012 12:14:03 +0100
Rui Nuno Capela <rncbc(a)rncbc.org> wrote:
iow. what if, assuming Ardour were about a
fully-compliant NSM client
and you want to open an existing Ardour session, one you've been working
hard previously but stand-lone ie. outside the NSM umbrella? i read that
you'll have to copy or move all ardour's session files _manually_ first,
or symlink at best, into the NSM's central/root directory and guess what
and where. that's the kind of "cheat" or "juggling" i was telling
you
about :)
Good point. As far as I remember this is covered the NSM API, though.
It says that "New", "Open, and "Save/Save As" commands have to
by
disabled while it is perfectly fine to offer a command "to import the
state of an existing project". So you get a new managed project but
with all state imported from an already existing possibly unmanaged
project.
Yours sincerely,
Dennis Schulmeister
--
Dennis Schulmeister - Schifferstr. 1 - 76189 Karlsruhe - Germany
Tel: +49 721/5978883 - Fax: +49 721/5978882 - Mob: +49 152/01994400
eMail: dennis(a)windows3.de - web: there-is.no-ip.org
3 Apr
3 Apr
4:21 p.m.
Am 3. April 2012 05:49 schrieb Joel Roth <joelz(a)pobox.com>om>:
(gaol one)
As I understand it, the primary motivation for a session
manager is to be able to save and restore the state of an
audio project[1] that consists of multiple interconnected
programs running on a multiprocessing Linux system.
In other words, the minimum capability sufficient to be
useful would be some sort of checkpointing mechanism.
A secondary goal, discussed extensively here, is that it
would be nice to be able to copy a session or export a
session. This is where all the contentious issues with
handling filesystem objects comes up.
We have two gaols, as Joel told us.
goal 1. store/restore - is already reached by NSM, if you ask me
goal 2. archive/copy/duplicate - is the point of this discussion
with goal 1. only
we have a session manager, that can handle projects you are currently
working on,
but if you want to, or have to, transfer the session to a different machine,
if you re-install your system, if you intent to store a sessions data,
if any data has to be moved, then -- your sessions are
very much lost -- as far as I can tell
As an NSM-client, you do what you want with the data, thus
nobody knows, how to automatically or manually fix lost path information,
how to ensure things are stored properly, etc...
with goal 2.
which could - at least to a very basic degree - be reached,
by forcing symlinks, there would be a tiny base, for further improvements
and dedicated helper scripts in the future
--
E.R.
4649
days inactive
4662
days old
linux-audio-dev@lists.linuxaudio.org
99 comments
18 participants
participants (18)
-
Dave Phillips -
David Robillard -
Dennis Schulmeister -
Emanuel Rumpf -
Fons Adriaensen -
J. Liles -
Joel Roth -
Lieven Moors -
Louigi Verona -
Nils -
Paul Davis -
Paul Giblock -
Renato -
rncbc -
rosea.grammostola -
Rui Nuno Capela
-
Thomas Vecchione -
Tim Westbrook