subject:"\[LAD\] NSM \- handling large files"


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,

bbbuut...:) 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...



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
rn...@rncbc.org
___
Linux-audio-dev mailing list
Linux-audio-dev@lists.linuxaudio.org
http://lists.linuxaudio.org/listinfo/linux-audio-dev

Re: [LAD] NSM - handling large files

2012-04-05 Thread Fons Adriaensen

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)

___
Linux-audio-dev mailing list
Linux-audio-dev@lists.linuxaudio.org
http://lists.linuxaudio.org/listinfo/linux-audio-dev

Re: [LAD] NSM - handling large files


On 04/05/2012 01:16 PM, Fons Adriaensen wrote:

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.


 [*] '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.


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
rn...@rncbc.org
___
Linux-audio-dev mailing list
Linux-audio-dev@lists.linuxaudio.org
http://lists.linuxaudio.org/listinfo/linux-audio-dev

Re: [LAD] NSM - handling large files

2012-04-05 Thread Fons Adriaensen

On Thu, Apr 05, 2012 at 03:19:24PM +0100, Rui Nuno Capela wrote:
 On 04/05/2012 01:16 PM, Fons Adriaensen wrote:
 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.
 
  [*] '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.
 

 so true, and ain't that something? you actually need the native-open and  
 save(as...) commands enabled after all o.O

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)

___
Linux-audio-dev mailing list
Linux-audio-dev@lists.linuxaudio.org
http://lists.linuxaudio.org/listinfo/linux-audio-dev

Re: [LAD] NSM - handling large files


On 04/05/2012 03:48 PM, Fons Adriaensen wrote:

On Thu, Apr 05, 2012 at 03:19:24PM +0100, Rui Nuno Capela wrote:

On 04/05/2012 01:16 PM, Fons Adriaensen wrote:

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.

[*] '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.



so true, and ain't that something? you actually need the native-open and
save(as...) commands enabled after all o.O


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).



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
rn...@rncbc.org
___
Linux-audio-dev mailing list
Linux-audio-dev@lists.linuxaudio.org
http://lists.linuxaudio.org/listinfo/linux-audio-dev

Re: [LAD] NSM - handling large files

2012-04-05 Thread David Robillard

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


___
Linux-audio-dev mailing list
Linux-audio-dev@lists.linuxaudio.org
http://lists.linuxaudio.org/listinfo/linux-audio-dev

Re: [LAD] NSM - handling large files

2012-04-05 Thread David Robillard

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,
 
  bbbuut...:) 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

Re: [LAD] NSM - handling large files

2012-04-05 Thread Dennis Schulmeister

On Thu, 05 Apr 2012 12:14:03 +0100
Rui Nuno Capela rn...@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: den...@windows3.de - web: there-is.no-ip.org
___
Linux-audio-dev mailing list
Linux-audio-dev@lists.linuxaudio.org
http://lists.linuxaudio.org/listinfo/linux-audio-dev

Re: [LAD] NSM - handling large files

2012-04-05 Thread J. Liles

On Thu, Apr 5, 2012 at 10:48 AM, David Robillard d...@drobilla.net wrote:

 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,
  
   bbbuut...:) 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

Re: [LAD] NSM - handling large files

2012-04-05 Thread David Robillard

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



___
Linux-audio-dev mailing list
Linux-audio-dev@lists.linuxaudio.org
http://lists.linuxaudio.org/listinfo/linux-audio-dev

Re: [LAD] NSM - handling large files


On 04/05/2012 07:14 PM, J. Liles wrote:


On Thu, Apr 5, 2012 at 10:48 AM, David Robillard d...@drobilla.net
mailto:d...@drobilla.net wrote:

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,
  
   bbbuut...:) 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

Re: [LAD] NSM - handling large files

2012-04-04 Thread Louigi Verona

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/
___
Linux-audio-dev mailing list
Linux-audio-dev@lists.linuxaudio.org
http://lists.linuxaudio.org/listinfo/linux-audio-dev

Re: [LAD] NSM - handling large files

2012-04-04 Thread Emanuel Rumpf

Am 4. April 2012 08:11 schrieb Louigi Verona louigi.ver...@gmail.com:

 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.
___
Linux-audio-dev mailing list
Linux-audio-dev@lists.linuxaudio.org
http://lists.linuxaudio.org/listinfo/linux-audio-dev

Re: [LAD] NSM - handling large files


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

___
Linux-audio-dev mailing list
Linux-audio-dev@lists.linuxaudio.org
http://lists.linuxaudio.org/listinfo/linux-audio-dev

Re: [LAD] NSM - handling large files


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.


cheers
--
rncbc aka Rui Nuno Capela
rn...@rncbc.org
___
Linux-audio-dev mailing list
Linux-audio-dev@lists.linuxaudio.org
http://lists.linuxaudio.org/listinfo/linux-audio-dev

Re: [LAD] NSM - handling large files


On 04/04/2012 02:22 PM, Rui Nuno Capela 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.


Another question. If you compare NSM level 0 (!) with JackSession. Which 
session manager do you prefer and why?


Regards,
\r
___
Linux-audio-dev mailing list
Linux-audio-dev@lists.linuxaudio.org
http://lists.linuxaudio.org/listinfo/linux-audio-dev

Re: [LAD] NSM - handling large files

2012-04-04 Thread Emanuel Rumpf

Am 4. April 2012 11:18 schrieb rosea.grammostola rosea.grammost...@gmail.com:

 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.
___
Linux-audio-dev mailing list
Linux-audio-dev@lists.linuxaudio.org
http://lists.linuxaudio.org/listinfo/linux-audio-dev

Re: [LAD] NSM - handling large files

2012-04-04 Thread Fons Adriaensen

On Wed, Apr 04, 2012 at 01:25:02PM +, 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)

___
Linux-audio-dev mailing list
Linux-audio-dev@lists.linuxaudio.org
http://lists.linuxaudio.org/listinfo/linux-audio-dev

Re: [LAD] NSM - handling large files


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
___
Linux-audio-dev mailing list
Linux-audio-dev@lists.linuxaudio.org
http://lists.linuxaudio.org/listinfo/linux-audio-dev

Re: [LAD] NSM - handling large files


On 04/04/2012 01:35 PM, rosea.grammostola wrote:

On 04/04/2012 02:22 PM, Rui Nuno Capela 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.


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.


of course it's a biased opinion

nuff said :)
--
rncbc aka Rui Nuno Capela
rn...@rncbc.org
___
Linux-audio-dev mailing list
Linux-audio-dev@lists.linuxaudio.org
http://lists.linuxaudio.org/listinfo/linux-audio-dev

Re: [LAD] NSM - handling large files


On 04/04/2012 04:39 PM, Rui Nuno Capela wrote:


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.


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
___
Linux-audio-dev mailing list
Linux-audio-dev@lists.linuxaudio.org
http://lists.linuxaudio.org/listinfo/linux-audio-dev

Re: [LAD] NSM - handling large files


On 04/04/2012 04:55 PM, rosea.grammostola wrote:

On 04/04/2012 04:39 PM, Rui Nuno Capela wrote:


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.


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

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


___
Linux-audio-dev mailing list
Linux-audio-dev@lists.linuxaudio.org
http://lists.linuxaudio.org/listinfo/linux-audio-dev

Re: [LAD] NSM - handling large files


On 04/04/2012 03:55 PM, rosea.grammostola wrote:

On 04/04/2012 04:39 PM, Rui Nuno Capela wrote:


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.


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 
purestrict 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
rn...@rncbc.org
___
Linux-audio-dev mailing list
Linux-audio-dev@lists.linuxaudio.org
http://lists.linuxaudio.org/listinfo/linux-audio-dev

Re: [LAD] NSM - handling large files

2012-04-04 Thread J. Liles

On Wed, Apr 4, 2012 at 5:22 AM, Rui Nuno Capela rn...@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 );

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...
___
Linux-audio-dev mailing list
Linux-audio-dev@lists.linuxaudio.org
http://lists.linuxaudio.org/listinfo/linux-audio-dev

Re: [LAD] NSM - handling large files


On 04/04/2012 05:46 PM, Rui Nuno Capela wrote:

On 04/04/2012 03:55 PM, rosea.grammostola wrote:

On 04/04/2012 04:39 PM, Rui Nuno Capela wrote:


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.


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
purestrict to the JS business (aka. protocol) and nothing more.
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.




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


___
Linux-audio-dev

Re: [LAD] NSM - handling large files

2012-04-04 Thread Fons Adriaensen

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)

___
Linux-audio-dev mailing list
Linux-audio-dev@lists.linuxaudio.org
http://lists.linuxaudio.org/listinfo/linux-audio-dev

Re: [LAD] NSM - handling large files


On 04/04/2012 05:19 PM, J. Liles wrote:



On Wed, Apr 4, 2012 at 5:22 AM, Rui Nuno Capela rn...@rncbc.org
mailto:rn...@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
rn...@rncbc.org
___
Linux-audio-dev mailing list
Linux-audio-dev@lists.linuxaudio.org
http://lists.linuxaudio.org/listinfo/linux-audio-dev

Re: [LAD] NSM - handling large files


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
rn...@rncbc.org
___
Linux-audio-dev mailing list
Linux-audio-dev@lists.linuxaudio.org
http://lists.linuxaudio.org/listinfo/linux-audio-dev

Re: [LAD] NSM - handling large files


On 04/04/2012 08:51 PM, Rui Nuno Capela wrote:

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?


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


___
Linux-audio-dev mailing list
Linux-audio-dev@lists.linuxaudio.org
http://lists.linuxaudio.org/listinfo/linux-audio-dev

Re: [LAD] NSM - handling large files


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


___
Linux-audio-dev mailing list
Linux-audio-dev@lists.linuxaudio.org
http://lists.linuxaudio.org/listinfo/linux-audio-dev

Re: [LAD] NSM - handling large files

2012-04-04 Thread Fons Adriaensen

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)

___
Linux-audio-dev mailing list
Linux-audio-dev@lists.linuxaudio.org
http://lists.linuxaudio.org/listinfo/linux-audio-dev

Re: [LAD] NSM - handling large files

2012-04-04 Thread David Robillard

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

___
Linux-audio-dev mailing list
Linux-audio-dev@lists.linuxaudio.org
http://lists.linuxaudio.org/listinfo/linux-audio-dev

Re: [LAD] NSM - handling large files

2012-04-04 Thread J. Liles

On Wed, Apr 4, 2012 at 1:48 PM, Fons Adriaensen f...@linuxaudio.org wrote:

 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 ?


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.
___
Linux-audio-dev mailing list
Linux-audio-dev@lists.linuxaudio.org
http://lists.linuxaudio.org/listinfo/linux-audio-dev

Re: [LAD] NSM - handling large files

2012-04-04 Thread J. Liles

On Wed, Apr 4, 2012 at 3:22 PM, J. Liles malnour...@gmail.com wrote:



 On Wed, Apr 4, 2012 at 1:48 PM, Fons Adriaensen f...@linuxaudio.orgwrote:

 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 ?


 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.


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).



___
Linux-audio-dev mailing list
Linux-audio-dev@lists.linuxaudio.org
http://lists.linuxaudio.org/listinfo/linux-audio-dev

Re: [LAD] NSM - handling large files

On 04/04/2012 11:22 PM, David Robillard wrote:

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:

Thanks, with my apologies in advance for my reply. :)

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

___
Linux-audio-dev mailing list
Linux-audio-dev@lists.linuxaudio.org
http://lists.linuxaudio.org/listinfo/linux-audio-dev

Re: [LAD] NSM - handling large files

2012-04-04 Thread David Robillard

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,
 
 bbbuut...:) 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


___
Linux-audio-dev mailing list
Linux-audio-dev@lists.linuxaudio.org
http://lists.linuxaudio.org/listinfo/linux-audio-dev

Re: [LAD] NSM - handling large files

2012-04-03 Thread Emanuel Rumpf

Am 2. April 2012 20:05 schrieb Emanuel Rumpf xb...@web.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.
___
Linux-audio-dev mailing list
Linux-audio-dev@lists.linuxaudio.org
http://lists.linuxaudio.org/listinfo/linux-audio-dev

Re: [LAD] NSM - handling large files

2012-04-03 Thread Emanuel Rumpf


  - offer accaptable integrity.


All further, extended functionality (export, import, copy, ...)
could then become part of a script or of version 2.0 of NSM.
___
Linux-audio-dev mailing list
Linux-audio-dev@lists.linuxaudio.org
http://lists.linuxaudio.org/listinfo/linux-audio-dev

Re: [LAD] NSM - handling large files

2012-04-03 Thread rncbc


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.


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
___
Linux-audio-dev mailing list
Linux-audio-dev@lists.linuxaudio.org
http://lists.linuxaudio.org/listinfo/linux-audio-dev

Re: [LAD] NSM - handling large files

2012-04-03 Thread Nils

On Tue, 3 Apr 2012 07:04:55 +
Emanuel Rumpf xb...@web.de wrote many things.

Emanuel,

why don't you write your own Session Manager (Protocol)?
You seem to be very knowledgable.

Nils
___
Linux-audio-dev mailing list
Linux-audio-dev@lists.linuxaudio.org
http://lists.linuxaudio.org/listinfo/linux-audio-dev

Re: [LAD] NSM - handling large files


On 04/03/2012 10:05 AM, rncbc wrote:

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).




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@lists.linuxaudio.org
http://lists.linuxaudio.org/listinfo/linux-audio-dev


___
Linux-audio-dev mailing list
Linux-audio-dev@lists.linuxaudio.org
http://lists.linuxaudio.org/listinfo/linux-audio-dev

Re: [LAD] NSM - handling large files


On 04/03/2012 11:38 AM, rosea.grammostola wrote:

On 04/03/2012 10:05 AM, rncbc wrote:

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).


* not the primary reason for this choice




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@lists.linuxaudio.org
http://lists.linuxaudio.org/listinfo/linux-audio-dev




___
Linux-audio-dev mailing list
Linux-audio-dev@lists.linuxaudio.org
http://lists.linuxaudio.org/listinfo/linux-audio-dev

Re: [LAD] NSM - handling large files

2012-04-03 Thread rncbc


On 03.04.2012 10:38, rosea.grammostola wrote:

On 04/03/2012 10:05 AM, rncbc wrote:

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).



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
___
Linux-audio-dev mailing list
Linux-audio-dev@lists.linuxaudio.org
http://lists.linuxaudio.org/listinfo/linux-audio-dev

Re: [LAD] NSM - handling large files


On 04/03/2012 02:55 PM, rosea.grammostola wrote:

On 04/03/2012 11:51 AM, rncbc wrote:

On 03.04.2012 10:38, rosea.grammostola wrote:

On 04/03/2012 10:05 AM, rncbc wrote:

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).



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.


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.


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

___
Linux-audio-dev mailing list
Linux-audio-dev@lists.linuxaudio.org
http://lists.linuxaudio.org/listinfo/linux-audio-dev

Re: [LAD] NSM - handling large files

2012-04-03 Thread Emanuel Rumpf

Am 3. April 2012 09:21 schrieb Nils l...@nilsgey.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.
___
Linux-audio-dev mailing list
Linux-audio-dev@lists.linuxaudio.org
http://lists.linuxaudio.org/listinfo/linux-audio-dev

Re: [LAD] NSM - handling large files

2012-04-03 Thread Louigi Verona

Guys, is there any info on JACK Session state? What apps are supported? How
to use?

-- 
Louigi Verona
http://www.louigiverona.ru/
___
Linux-audio-dev mailing list
Linux-audio-dev@lists.linuxaudio.org
http://lists.linuxaudio.org/listinfo/linux-audio-dev

Re: [LAD] NSM - handling large files


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
___
Linux-audio-dev mailing list
Linux-audio-dev@lists.linuxaudio.org
http://lists.linuxaudio.org/listinfo/linux-audio-dev

Re: [LAD] NSM - handling large files

2012-04-03 Thread Rui Nuno Capela


On 04/03/2012 01:55 PM, rosea.grammostola wrote:

On 04/03/2012 11:51 AM, rncbc wrote:

On 03.04.2012 10:38, rosea.grammostola wrote:

On 04/03/2012 10:05 AM, rncbc wrote:

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).



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.


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).



speaking of which

ardour gets all its stuff under one own session directory, on a per 
session/project basis, iirc just like NSM mandates,


bbbuut...:) 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


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

Re: [LAD] NSM - handling large files

2012-04-03 Thread J. Liles

On Tue, Apr 3, 2012 at 6:35 AM, rosea.grammostola
rosea.grammost...@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...
___
Linux-audio-dev mailing list
Linux-audio-dev@lists.linuxaudio.org
http://lists.linuxaudio.org/listinfo/linux-audio-dev

Re: [LAD] NSM - handling large files

2012-04-03 Thread J. Liles

On Tue, Apr 3, 2012 at 10:04 AM, Rui Nuno Capela rn...@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...
___
Linux-audio-dev mailing list
Linux-audio-dev@lists.linuxaudio.org
http://lists.linuxaudio.org/listinfo/linux-audio-dev

Re: [LAD] NSM - handling large files

2012-04-02 Thread rosea.grammostola


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

___
Linux-audio-dev mailing list
Linux-audio-dev@lists.linuxaudio.org
http://lists.linuxaudio.org/listinfo/linux-audio-dev

Re: [LAD] NSM - handling large files

2012-04-02 Thread J. Liles

On Mon, Apr 2, 2012 at 9:11 AM, rosea.grammostola
rosea.grammost...@gmail.com wrote:
 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?

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.

 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.
___
Linux-audio-dev mailing list
Linux-audio-dev@lists.linuxaudio.org
http://lists.linuxaudio.org/listinfo/linux-audio-dev

Re: [LAD] NSM - handling large files

Am 2. April 2012 19:17 schrieb J. Liles malnour...@gmail.com:

 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.
___
Linux-audio-dev mailing list
Linux-audio-dev@lists.linuxaudio.org
http://lists.linuxaudio.org/listinfo/linux-audio-dev

Re: [LAD] NSM - handling large files

2012-04-02 Thread Paul Giblock

 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?);

Do all target filesystems support symbolic links?
___
Linux-audio-dev mailing list
Linux-audio-dev@lists.linuxaudio.org
http://lists.linuxaudio.org/listinfo/linux-audio-dev

Re: [LAD] NSM - handling large files

Am 2. April 2012 20:39 schrieb Paul Giblock pgib...@gmail.com:
 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...

-- 
E.R.
___
Linux-audio-dev mailing list
Linux-audio-dev@lists.linuxaudio.org
http://lists.linuxaudio.org/listinfo/linux-audio-dev

Re: [LAD] NSM - handling large files

2012-04-02 Thread J. Liles

On Mon, Apr 2, 2012 at 12:07 PM, Paul Giblock pgib...@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...
___
Linux-audio-dev mailing list
Linux-audio-dev@lists.linuxaudio.org
http://lists.linuxaudio.org/listinfo/linux-audio-dev

Re: [LAD] NSM - handling large files

2012-04-02 Thread J. Liles

On Mon, Apr 2, 2012 at 11:29 AM, Emanuel Rumpf xb...@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.
___
Linux-audio-dev mailing list
Linux-audio-dev@lists.linuxaudio.org
http://lists.linuxaudio.org/listinfo/linux-audio-dev

Re: [LAD] NSM - handling large files

2012-04-02 Thread Thomas Vecchione

On Mon, Apr 2, 2012 at 3:11 PM, J. Liles malnour...@gmail.com wrote:

 On Mon, Apr 2, 2012 at 12:07 PM, Paul Giblock pgib...@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...


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
___
Linux-audio-dev mailing list
Linux-audio-dev@lists.linuxaudio.org
http://lists.linuxaudio.org/listinfo/linux-audio-dev

Re: [LAD] NSM - handling large files

2012-04-02 Thread Tim Westbrook

 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
___
Linux-audio-dev mailing list
Linux-audio-dev@lists.linuxaudio.org
http://lists.linuxaudio.org/listinfo/linux-audio-dev

Re: [LAD] NSM - handling large files

Am 2. April 2012 21:22 schrieb J. Liles malnour...@gmail.com:

 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.
___
Linux-audio-dev mailing list
Linux-audio-dev@lists.linuxaudio.org
http://lists.linuxaudio.org/listinfo/linux-audio-dev

Re: [LAD] NSM - handling large files