From gbertis at yahoo.com.br Mon Apr 2 16:08:58 2012
From: gbertis at yahoo.com.br (Guilherme Bertissolo)
Date: Mon, 2 Apr 2012 09:08:58 -0700 (PDT)
Subject: [LAD] (no subject)
Message-ID: <1333382938.39266.YahooMailMobile@web126002.mail.ne1.yahoo.com>
http://enacte.cl/components/02efpk.html
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
From rosea.grammostola at gmail.com Mon Apr 2 16:11:42 2012
From: rosea.grammostola at gmail.com (rosea.grammostola)
Date: Mon, 02 Apr 2012 18:11:42 +0200
Subject: [LAD] NSM - handling large files
In-Reply-To:
References: <4F74D2D2.8030109@rncbc.org> <4F75762C.7090505@rncbc.org>
Message-ID: <4F79CFBE.1070007@gmail.com>
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
From malnourite at gmail.com Mon Apr 2 17:17:13 2012
From: malnourite at gmail.com (J. Liles)
Date: Mon, 2 Apr 2012 10:17:13 -0700
Subject: [LAD] NSM - handling large files
In-Reply-To: <4F79CFBE.1070007@gmail.com>
References:
<4F74D2D2.8030109@rncbc.org>
<4F75762C.7090505@rncbc.org>
<4F79CFBE.1070007@gmail.com>
Message-ID:
On Mon, Apr 2, 2012 at 9:11 AM, rosea.grammostola
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."
From rncbc at rncbc.org Mon Apr 2 18:29:57 2012
From: rncbc at rncbc.org (Rui Nuno Capela)
Date: Mon, 02 Apr 2012 19:29:57 +0100
Subject: [LAD] NSM - handling large files
In-Reply-To: <4F79CFBE.1070007@gmail.com>
References: <4F74D2D2.8030109@rncbc.org> <4F75762C.7090505@rncbc.org>
<4F79CFBE.1070007@gmail.com>
Message-ID: <4F79F025.5020600@rncbc.org>
On 04/02/2012 05:11 PM, rosea.grammostola 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?
>
> 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?
it's just unlikely, not that it won't apply to the rules :)
for instance, qtractor doesn't apply to the jack-session and ladish
rules on 100% but it works on both as long as you don't EVER mix
qtractor sessions directories with SM's session directories. that is, it
is always possible to use qtractor's gui file menu save/save as... to
replace any SM session directory but not recommended though, ever.
depending on "unpredictable circumstances", one will sooner or later
break either or both session states (qtractor session and/or the SM's
one) when you try to load any later on
point is, in qtractor terms at least, saving a managed-session takes a
different and specific code path. read that like a managed-session save
operation is kind of a instant snapshot, which doesn't even change the
current qtractor session title, path or dirty flag at all, if any
nb. all this applies whether the "external files symlinking" are
implemented or not (will that be an option or shall be mandatory by SM
protocol design?); it's about session state integrity and not session
directory "centrality" or "portability"
in conclusion. qtractor may be always made to work as a NSM client.
that's orthogonal to the "session directory dilemma", which i think this
is what Paul's referring to
alas, all is just not *my* top priority atm. meanwhile, any patch would
be welcome, of course ;)
byee
--
rncbc aka Rui Nuno Capela
rncbc at rncbc.org
From xbran at web.de Mon Apr 2 18:29:51 2012
From: xbran at web.de (Emanuel Rumpf)
Date: Mon, 2 Apr 2012 20:29:51 +0200
Subject: [LAD] NSM - handling large files
In-Reply-To:
References:
<4F74D2D2.8030109@rncbc.org>
<4F75762C.7090505@rncbc.org>
<4F79CFBE.1070007@gmail.com>
Message-ID:
Am 2. April 2012 19:17 schrieb J. Liles :
> 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.
From pgiblox at gmail.com Mon Apr 2 18:39:33 2012
From: pgiblox at gmail.com (Paul Giblock)
Date: Mon, 2 Apr 2012 14:39:33 -0400
Subject: [LAD] NSM - handling large files
In-Reply-To: <4F79F025.5020600@rncbc.org>
References:
<4F74D2D2.8030109@rncbc.org>
<4F75762C.7090505@rncbc.org>
<4F79CFBE.1070007@gmail.com> <4F79F025.5020600@rncbc.org>
Message-ID:
> 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?
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
From xbran at web.de Mon Apr 2 18:51:44 2012
From: xbran at web.de (Emanuel Rumpf)
Date: Mon, 2 Apr 2012 20:51:44 +0200
Subject: [LAD] NSM - handling large files
In-Reply-To:
References:
<4F74D2D2.8030109@rncbc.org>
<4F75762C.7090505@rncbc.org>
<4F79CFBE.1070007@gmail.com> <4F79F025.5020600@rncbc.org>
Message-ID:
Am 2. April 2012 20:39 schrieb Paul Giblock :
> 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.
From pgiblox at gmail.com Mon Apr 2 19:07:03 2012
From: pgiblox at gmail.com (Paul Giblock)
Date: Mon, 2 Apr 2012 15:07:03 -0400
Subject: [LAD] NSM - handling large files
In-Reply-To:
References:
<4F74D2D2.8030109@rncbc.org>
<4F75762C.7090505@rncbc.org>
<4F79CFBE.1070007@gmail.com> <4F79F025.5020600@rncbc.org>
Message-ID:
> > 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...
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.
-- Paul
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
From malnourite at gmail.com Mon Apr 2 19:11:14 2012
From: malnourite at gmail.com (J. Liles)
Date: Mon, 2 Apr 2012 12:11:14 -0700
Subject: [LAD] NSM - handling large files
In-Reply-To:
References:
<4F74D2D2.8030109@rncbc.org>
<4F75762C.7090505@rncbc.org>
<4F79CFBE.1070007@gmail.com> <4F79F025.5020600@rncbc.org>
Message-ID:
On Mon, Apr 2, 2012 at 12:07 PM, Paul Giblock 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...
From malnourite at gmail.com Mon Apr 2 19:22:58 2012
From: malnourite at gmail.com (J. Liles)
Date: Mon, 2 Apr 2012 12:22:58 -0700
Subject: [LAD] NSM - handling large files
In-Reply-To:
References:
<4F74D2D2.8030109@rncbc.org>
<4F75762C.7090505@rncbc.org>
<4F79CFBE.1070007@gmail.com>
Message-ID:
On Mon, Apr 2, 2012 at 11:29 AM, Emanuel Rumpf 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.
From seablaede at gmail.com Mon Apr 2 19:34:02 2012
From: seablaede at gmail.com (Thomas Vecchione)
Date: Mon, 2 Apr 2012 15:34:02 -0400
Subject: [LAD] NSM - handling large files
In-Reply-To:
References:
<4F74D2D2.8030109@rncbc.org>
<4F75762C.7090505@rncbc.org>
<4F79CFBE.1070007@gmail.com> <4F79F025.5020600@rncbc.org>
Message-ID:
On Mon, Apr 2, 2012 at 3:11 PM, J. Liles wrote:
> On Mon, Apr 2, 2012 at 12:07 PM, Paul Giblock 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
From iondiode at yahoo.com Mon Apr 2 19:48:42 2012
From: iondiode at yahoo.com (Tim Westbrook)
Date: Tue, 3 Apr 2012 07:48:42 +1200
Subject: [LAD] NSM - handling large files
In-Reply-To:
References:
<4F74D2D2.8030109@rncbc.org>
<4F75762C.7090505@rncbc.org>
<4F79CFBE.1070007@gmail.com> <4F79F025.5020600@rncbc.org>
Message-ID:
> 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
From xbran at web.de Mon Apr 2 20:05:16 2012
From: xbran at web.de (Emanuel Rumpf)
Date: Mon, 2 Apr 2012 22:05:16 +0200
Subject: [LAD] NSM - handling large files
In-Reply-To:
References:
<4F74D2D2.8030109@rncbc.org>
<4F75762C.7090505@rncbc.org>
<4F79CFBE.1070007@gmail.com>
Message-ID:
Am 2. April 2012 21:22 schrieb J. Liles :
>
> 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.
From xbran at web.de Mon Apr 2 20:22:19 2012
From: xbran at web.de (Emanuel Rumpf)
Date: Mon, 2 Apr 2012 22:22:19 +0200
Subject: [LAD] NSM - handling large files
In-Reply-To:
References:
<4F74D2D2.8030109@rncbc.org>
<4F75762C.7090505@rncbc.org>
<4F79CFBE.1070007@gmail.com> <4F79F025.5020600@rncbc.org>
Message-ID:
A new thought:
Lets say we did store the session as tar.gz,
and we de-referenced the symlinks.
Means: We have all files related to the session th the tar.gz.
So far, so good.
Now we re-import the session to NSM:
We extract that tar.gz in the NSM sessions-folder.
Note: instead of symlinks we have now real files in the symlinks
directory (because we de-referenced before creating the tar.gz).
Real files should not go to the symlinks directory.
But we could have a simple script, to move these files
to the "nsm-large-files/" folder and re-create the symlinks.
Now we should have a state very similar to where we began.
(exception: we did not restore the file-paths we've had originally,
but symlinked to the nsm-large-files folder instead)
I think this is acceptable
- the session stayed valid at least.
--
E.R.
From rosea.grammostola at gmail.com Mon Apr 2 21:32:45 2012
From: rosea.grammostola at gmail.com (rosea.grammostola)
Date: Mon, 02 Apr 2012 23:32:45 +0200
Subject: [LAD] Non Session Management
In-Reply-To: <1333045249.21680.5.camel@verne.drobilla.net>
References: <1332429009.6203.6.camel@verne.drobilla.net> <20120326214033.GA30612@linuxaudio.org> <20120327194126.GA21421@linuxaudio.org> <1332906376.9469.27.camel@verne.drobilla.net> <20120328183152.3c5f8a1c@gmail.com> <1332956024.9469.63.camel@verne.drobilla.net> <1332960825.9469.80.camel@verne.drobilla.net>
<1333045249.21680.5.camel@verne.drobilla.net>
Message-ID: <4F7A1AFD.3010105@gmail.com>
Apart from the Qtractor scenario (which seems not to be an impossible
hurdle to take), there is one question left for me and that is:
*Is it needed to remove JackSession support, in order to add NSM support?*
I don't expect this to be true, but afaik JackSession is disabled in the
NSM Yoshimi patch. I suspect that distro maintainers wants all available
session options to be enabled for their users.
Other question might be if NSM is able to run crossplatform, but I
believe the answer is YES (correct me if I'm wrong).
Then of course you have the issue whether devs wants to apply to the
strict NSM rules, but apart from issues reported by Rui, I didn't hear
any arguments against it from developers yet.
Regards,
\r
From joelz at pobox.com Tue Apr 3 05:49:05 2012
From: joelz at pobox.com (Joel Roth)
Date: Mon, 2 Apr 2012 19:49:05 -1000
Subject: [LAD] NSM - handling large files
In-Reply-To:
References:
Message-ID: <20120403054905.GB3415@sprite>
On Thu, Mar 29, 2012 at 03:44:17PM +0200, Emanuel Rumpf wrote:
> Back to life - back to reality
>
> 1. We start qtractor as part of a session, create some midi-tracks,
> include some external wav-files.
>
> Should the SM "know" about these external files, as I suggested ?
> (Allowing the user to find out basic info about it. )
> Or leave it completely to qtractor ?
As a developer of limited abilities, I would like the bar
of integrating Nama with other programs to be as low
as possible. :-)
As I understand it, the primary motivation for a session
manager is to be able to save and restore the state of an
audio project[1] that consists of multiple interconnected
programs running on a multiprocessing Linux system.
In other words, the minimum capability sufficient to be
useful would be some sort of checkpointing mechanism.
A secondary goal, discussed extensively here, is that it
would be nice to be able to copy a session or export a
session. This is where all the contentious issues with
handling filesystem objects comes up.
The latter goal should be optional, IMO, rather than required.
Managing files, seems relatively simple in the case of
of Nama, which is a purely non-destructive editor,
Once recorded, Nama *never* modifies or deletes audio files,
so these files don't need to be involved in checkpointing.
(If a user wants to delete WAV files associated with a bad
take, that is her responsibility.)
All the mutable state information for a project is
serialized and stored as JSON. State files for a project
can be named. In future they will be placed under
VCS to add branching (and possibly
merging) abilities.
If Nama (or Qtractor, Ardour, etc.) is to clone a project,
that concern is internal to the app: I wouldn't expect a
session manager to know it should link the files in the .wav
directory and copy the other files. (Straight copying of
files might not even be appropriate if those files are
under a VCS.)
> 2. We record a new file in qtractor. Where would it be stored ?
>
> Should the SM "know" about this file ?
There could be advantages to knowing, however if the aim is
to integrate multiple apps, it will be simpler if the SM and
app only need to communicate the project name and checkpoint
ID. (It gets more complicated than that since the SM
will need to know that Nama should be responsible for
configuring Ecasound and for either connecting Ecasound to
JACK clients or reporting when Ecasound is ready to be
connected.)
> 3. A session is duplicated.
> How does the SM handle the recorded and external files?
Branching a project (assuming VCS, which I believe is the
future :-) would be cheaper than duplicating a project.
If the SM wants an app to duplicate a project, I would
expect the SM to ask the app to create a new project as a
copy of an existing project. Whether the app chooses to use
symlinking, hardlinking, copying files or branching under a
VCS seems to be the app's internal concern.
> 4. A session is exported.
> Jonathan said, current practice is a simple directory copy.
> Well ! Simple and not bad at all.
> But what about the external files ?
> Just make some symlinks for them ?
The state files and audio files for a Nama project
are in a single directory, easy to copy.
However the .namarc config file specifying the ALSA devices
to be used, the audio recording format, the mixdown format
and many other program behaviors currently exists only
in $HOME.
Even if this file were linked or copied into the project
directory, it may not be seamlessly portable to the
audio hardware and configuration of another system.
If the process of exporting cannot be defined unambiguously,
or involves vast complexity, we might be more successful by
initially restricting our *first* steps to checkpointing
functionality.
Minimizing complexity seems important, as
the Linux audio world has already gone through
several session management APIs, with none yet
widely adopted.
Regards,
Joel
1. I use the terms "project" and "session" interchangeably.
>
> --
> E.R.
--
Joel Roth
From xbran at web.de Tue Apr 3 06:59:32 2012
From: xbran at web.de (Emanuel Rumpf)
Date: Tue, 3 Apr 2012 06:59:32 +0000
Subject: [LAD] NSM - handling large files
In-Reply-To:
References:
<4F74D2D2.8030109@rncbc.org>
<4F75762C.7090505@rncbc.org>
<4F79CFBE.1070007@gmail.com>
Message-ID:
Am 2. April 2012 20:05 schrieb Emanuel Rumpf :
>
> 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.
From xbran at web.de Tue Apr 3 07:04:55 2012
From: xbran at web.de (Emanuel Rumpf)
Date: Tue, 3 Apr 2012 07:04:55 +0000
Subject: [LAD] NSM - handling large files
In-Reply-To:
References:
<4F74D2D2.8030109@rncbc.org>
<4F75762C.7090505@rncbc.org>
<4F79CFBE.1070007@gmail.com>
Message-ID:
>
> ?- offer accaptable integrity.
>
All further, extended functionality (export, import, copy, ...)
could then become part of a script or of version 2.0 of NSM.
From rncbc at rncbc.org Tue Apr 3 08:05:00 2012
From: rncbc at rncbc.org (rncbc)
Date: Tue, 03 Apr 2012 09:05:00 +0100
Subject: [LAD] NSM - handling large files
In-Reply-To: <20120403054905.GB3415@sprite>
References:
<20120403054905.GB3415@sprite>
Message-ID: <9264a665805b61a7c3ef4d8d2521ce07@rncbc.org>
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 ?
>
>
> 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.
>
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
From list at nilsgey.de Tue Apr 3 09:21:14 2012
From: list at nilsgey.de (Nils)
Date: Tue, 3 Apr 2012 11:21:14 +0200
Subject: [LAD] NSM - handling large files
In-Reply-To:
References:
<4F74D2D2.8030109@rncbc.org>
<4F75762C.7090505@rncbc.org>
<4F79CFBE.1070007@gmail.com>
Message-ID: <20120403112114.4fdb7d8f@nilsgey.de>
On Tue, 3 Apr 2012 07:04:55 +0000
Emanuel Rumpf wrote many things.
Emanuel,
why don't you write your own Session Manager (Protocol)?
You seem to be very knowledgable.
Nils
From rosea.grammostola at gmail.com Tue Apr 3 09:38:38 2012
From: rosea.grammostola at gmail.com (rosea.grammostola)
Date: Tue, 03 Apr 2012 11:38:38 +0200
Subject: [LAD] NSM - handling large files
In-Reply-To: <9264a665805b61a7c3ef4d8d2521ce07@rncbc.org>
References: <20120403054905.GB3415@sprite>
<9264a665805b61a7c3ef4d8d2521ce07@rncbc.org>
Message-ID: <4F7AC51E.7070507@gmail.com>
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 ?
>>
>
>>
>> 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.
>>
>
>
> 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 at lists.linuxaudio.org
> http://lists.linuxaudio.org/listinfo/linux-audio-dev
From rosea.grammostola at gmail.com Tue Apr 3 09:41:55 2012
From: rosea.grammostola at gmail.com (rosea.grammostola)
Date: Tue, 03 Apr 2012 11:41:55 +0200
Subject: [LAD] NSM - handling large files
In-Reply-To: <4F7AC51E.7070507@gmail.com>
References: <20120403054905.GB3415@sprite>
<9264a665805b61a7c3ef4d8d2521ce07@rncbc.org>
<4F7AC51E.7070507@gmail.com>
Message-ID: <4F7AC5E3.8020904@gmail.com>
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 ?
>>>
>>
>>>
>>> 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.
>>>
>>
>>
>> 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 at lists.linuxaudio.org
>> http://lists.linuxaudio.org/listinfo/linux-audio-dev
>
From rncbc at rncbc.org Tue Apr 3 09:51:42 2012
From: rncbc at rncbc.org (rncbc)
Date: Tue, 03 Apr 2012 10:51:42 +0100
Subject: [LAD] NSM - handling large files
In-Reply-To: <4F7AC51E.7070507@gmail.com>
References: "\""
"
<20120403054905.GB3415@sprite>
<9264a665805b61a7c3ef4d8d2521ce07@rncbc.org>
<4F7AC51E.7070507@gmail.com>
Message-ID: <5e25fdd113b7a6d1b04d4dbf8253787d@rncbc.org>
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 ?
>>>
>>
>>>
>>> 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.
>>>
>>
>>
>> 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
From rosea.grammostola at gmail.com Tue Apr 3 12:55:20 2012
From: rosea.grammostola at gmail.com (rosea.grammostola)
Date: Tue, 03 Apr 2012 14:55:20 +0200
Subject: [LAD] NSM - handling large files
In-Reply-To: <5e25fdd113b7a6d1b04d4dbf8253787d@rncbc.org>
References: "\"" " <20120403054905.GB3415@sprite> <9264a665805b61a7c3ef4d8d2521ce07@rncbc.org> <4F7AC51E.7070507@gmail.com>
<5e25fdd113b7a6d1b04d4dbf8253787d@rncbc.org>
Message-ID: <4F7AF338.7080605@gmail.com>
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 ?
>>>>
>>>
>>>>
>>>> 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.
>>>>
>>>
>>>
>>> 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.
Regards,
\r
From rosea.grammostola at gmail.com Tue Apr 3 13:35:06 2012
From: rosea.grammostola at gmail.com (rosea.grammostola)
Date: Tue, 03 Apr 2012 15:35:06 +0200
Subject: [LAD] NSM - handling large files
In-Reply-To: <4F7AF338.7080605@gmail.com>
References: "\"" " <20120403054905.GB3415@sprite> <9264a665805b61a7c3ef4d8d2521ce07@rncbc.org> <4F7AC51E.7070507@gmail.com>
<5e25fdd113b7a6d1b04d4dbf8253787d@rncbc.org>
<4F7AF338.7080605@gmail.com>
Message-ID: <4F7AFC8A.4060401@gmail.com>
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 ?
>>>>>
>>>>
>>>>>
>>>>> 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.
>>>>>
>>>>
>>>>
>>>> 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
From xbran at web.de Tue Apr 3 13:44:47 2012
From: xbran at web.de (Emanuel Rumpf)
Date: Tue, 3 Apr 2012 13:44:47 +0000
Subject: [LAD] NSM - handling large files
In-Reply-To: <20120403112114.4fdb7d8f@nilsgey.de>
References:
<4F74D2D2.8030109@rncbc.org>
<4F75762C.7090505@rncbc.org>
<4F79CFBE.1070007@gmail.com>
<20120403112114.4fdb7d8f@nilsgey.de>
Message-ID:
Am 3. April 2012 09:21 schrieb Nils :
>
> 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.
From louigi.verona at gmail.com Tue Apr 3 14:18:26 2012
From: louigi.verona at gmail.com (Louigi Verona)
Date: Tue, 3 Apr 2012 18:18:26 +0400
Subject: [LAD] NSM - handling large files
In-Reply-To:
References:
<4F74D2D2.8030109@rncbc.org>
<4F75762C.7090505@rncbc.org>
<4F79CFBE.1070007@gmail.com>
<20120403112114.4fdb7d8f@nilsgey.de>
Message-ID:
Guys, is there any info on JACK Session state? What apps are supported? How
to use?
--
Louigi Verona
http://www.louigiverona.ru/
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
From xbran at web.de Tue Apr 3 14:21:47 2012
From: xbran at web.de (Emanuel Rumpf)
Date: Tue, 3 Apr 2012 14:21:47 +0000
Subject: [LAD] NSM - handling large files
In-Reply-To: <5e25fdd113b7a6d1b04d4dbf8253787d@rncbc.org>
References:
<20120403054905.GB3415@sprite>
<9264a665805b61a7c3ef4d8d2521ce07@rncbc.org>
<4F7AC51E.7070507@gmail.com>
<5e25fdd113b7a6d1b04d4dbf8253787d@rncbc.org>
Message-ID:
Am 3. April 2012 05:49 schrieb Joel Roth :
> (gaol one)
> As I understand it, the primary motivation for a session
> manager is to be able to save and restore the state of an
> audio project[1] that consists of multiple interconnected
> programs running on a multiprocessing Linux system.
>
> In other words, the minimum capability sufficient to be
> useful would be some sort of checkpointing mechanism.
>
> A secondary goal, discussed extensively here, is that it
> would be nice to be able to copy a session or export a
> session. This is where all the contentious issues with
> handling filesystem objects comes up.
We have two gaols, as Joel told us.
goal 1. store/restore - is already reached by NSM, if you ask me
goal 2. archive/copy/duplicate - is the point of this discussion
with goal 1. only
we have a session manager, that can handle projects you are currently
working on,
but if you want to, or have to, transfer the session to a different machine,
if you re-install your system, if you intent to store a sessions data,
if any data has to be moved, then -- your sessions are
very much lost -- as far as I can tell
As an NSM-client, you do what you want with the data, thus
nobody knows, how to automatically or manually fix lost path information,
how to ensure things are stored properly, etc...
with goal 2.
which could - at least to a very basic degree - be reached,
by forcing symlinks, there would be a tiny base, for further improvements
and dedicated helper scripts in the future
--
E.R.
From rosea.grammostola at gmail.com Tue Apr 3 14:21:39 2012
From: rosea.grammostola at gmail.com (rosea.grammostola)
Date: Tue, 03 Apr 2012 16:21:39 +0200
Subject: [LAD] NSM - handling large files
In-Reply-To:
References: <4F74D2D2.8030109@rncbc.org> <4F75762C.7090505@rncbc.org> <4F79CFBE.1070007@gmail.com> <20120403112114.4fdb7d8f@nilsgey.de>
Message-ID: <4F7B0773.2070106@gmail.com>
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
From rncbc at rncbc.org Tue Apr 3 17:04:21 2012
From: rncbc at rncbc.org (Rui Nuno Capela)
Date: Tue, 03 Apr 2012 18:04:21 +0100
Subject: [LAD] NSM - handling large files
In-Reply-To: <4F7AF338.7080605@gmail.com>
References: "\"" " <20120403054905.GB3415@sprite> <9264a665805b61a7c3ef4d8d2521ce07@rncbc.org> <4F7AC51E.7070507@gmail.com>
<5e25fdd113b7a6d1b04d4dbf8253787d@rncbc.org>
<4F7AF338.7080605@gmail.com>
Message-ID: <4F7B2D95.5030202@rncbc.org>
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 ?
>>>>>
>>>>
>>>>>
>>>>> 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.
>>>>>
>>>>
>>>>
>>>> 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,
bbbuuuuuut...:) making that one and the same directory as from an
outsider/independent session manager like NSM is asking for a lot of
file and symlink juggling, if you ask me
i'm not an expert in ardour internals, someone else could chime in and
help me here.
my feeling again is that the effort to comply with NSM isn't, won't be
so easy for any lass-than-simple-textbook-like client examples
once again, i call for some ardour expertise. i'm even afraid to ask
this btw, but does ardour work with jack-session already? o.O
aham
> However, it might be fair to take a look at how JackSession does this
> and answer the question why it is or why it is not a problem to not have
> these saving restrictions.
>
jack-session has some fsck-up restrictions of its own
one that i had historical complaints is about this non-reusable session
directory restriction (here, the "non" particle, is not a pun;) which
meant that you can't save into the same session directory twice
a "really-smart/intelligent" SM could copy and re(sym)link all the
references under each client participant's session sub-directory, yes, a
chimeric kind of effort comes to mind :o)
alas. this jack-session restriction has been somewhat circumvented by
the "versioning" feature on qjackctl-as-jack-session-manager, by yours
truly. yes it's true, but it shows you how cumbersome is like when one
has to go around and break the red tape of those draconian SM's ;)
and now NSM is about asking for even more and thicker red tape...
cough
now, i could suggest NSM API to be split in levels of compliance and
restrictiveness, so to speak:
- level 0 :- clients just store/retrieve their own private state from a
supplied and independent session sub-directory; no GUI File menu
restrictions; no file location restrictions, no symlinks, no juggling,
no dupes, no sh*t.
- level 1+ :- anything that (may progressively?) imposes each one the
mentioned non-restrictions of level 0.
starting with level 0, there's a fair chance for NSM to revolve, and
even co-exist peacefully with jack-session and ladish. call me a dreamer :)
cheers
--
rncbc aka Rui Nuno Capela
rncbc at rncbc.org
From malnourite at gmail.com Tue Apr 3 17:17:13 2012
From: malnourite at gmail.com (J. Liles)
Date: Tue, 3 Apr 2012 10:17:13 -0700
Subject: [LAD] NSM - handling large files
In-Reply-To: <4F7AFC8A.4060401@gmail.com>
References:
<20120403054905.GB3415@sprite>
<9264a665805b61a7c3ef4d8d2521ce07@rncbc.org>
<4F7AC51E.7070507@gmail.com>
<5e25fdd113b7a6d1b04d4dbf8253787d@rncbc.org>
<4F7AF338.7080605@gmail.com> <4F7AFC8A.4060401@gmail.com>
Message-ID:
On Tue, Apr 3, 2012 at 6:35 AM, rosea.grammostola
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...
From malnourite at gmail.com Tue Apr 3 17:34:00 2012
From: malnourite at gmail.com (J. Liles)
Date: Tue, 3 Apr 2012 10:34:00 -0700
Subject: [LAD] NSM - handling large files
In-Reply-To: <4F7B2D95.5030202@rncbc.org>
References:
<20120403054905.GB3415@sprite>
<9264a665805b61a7c3ef4d8d2521ce07@rncbc.org>
<4F7AC51E.7070507@gmail.com>
<5e25fdd113b7a6d1b04d4dbf8253787d@rncbc.org>
<4F7AF338.7080605@gmail.com> <4F7B2D95.5030202@rncbc.org>
Message-ID:
On Tue, Apr 3, 2012 at 10:04 AM, Rui Nuno Capela 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...
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
From falktx at gmail.com Tue Apr 3 23:24:23 2012
From: falktx at gmail.com (Filipe Lopes)
Date: Wed, 4 Apr 2012 00:24:23 +0100
Subject: [LAD] JACK CV Ports API
Message-ID:
hey lads,
sharing an idea I had here
my (currently in development) host directly exposes plugin ports to jack -
audio as audio, midi as midi, and parameters as a midi port for midi-cc
usage.
while coding for lv2 plugins, I noticed the CV port type, more info here:
http://lv2plug.in/ns/ext/cv-port/
I didn't yet coded support for it, but I'll do soon. Those kind of ports
will be exposed to jack as pure audio ports.
Non-daw and non-mixer also use this kind of ports, and maybe others.
The problem is that users shouldn't connect normal audio and CV ports
together...
so I came up with an idea that is simple and fairly easy to implement - a
new jack port flag.
example:
port = jack_port_register(client, port_name, JACK_DEFAULT_AUDIO_TYPE,
JackPortIsInput|JackPortIsCV, 0);
patchbays can check for this flag and represent the port as a different
type (I've done it here myself as jack keeps any custom port flag values I
set, and works just fine).
in the jack library code we can check for the flag and not allow port
connections.
what do you think?
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
From d at drobilla.net Wed Apr 4 00:20:27 2012
From: d at drobilla.net (David Robillard)
Date: Tue, 03 Apr 2012 20:20:27 -0400
Subject: [LAD] JACK CV Ports API
In-Reply-To:
References:
Message-ID: <1333498827.22058.0.camel@verne.drobilla.net>
On Wed, 2012-04-04 at 00:24 +0100, Filipe Lopes wrote:
> hey lads,
> sharing an idea I had here
>
> my (currently in development) host directly exposes plugin ports to
> jack - audio as audio, midi as midi, and parameters as a midi port for
> midi-cc usage.
> while coding for lv2 plugins, I noticed the CV port type, more info
> here:
> http://lv2plug.in/ns/ext/cv-port/
>
> I didn't yet coded support for it, but I'll do soon. Those kind of
> ports will be exposed to jack as pure audio ports.
> Non-daw and non-mixer also use this kind of ports, and maybe others.
> The problem is that users shouldn't connect normal audio and CV ports
> together...
>
> so I came up with an idea that is simple and fairly easy to implement
> - a new jack port flag.
>
> example:
> port = jack_port_register(client, port_name, JACK_DEFAULT_AUDIO_TYPE,
> JackPortIsInput|JackPortIsCV, 0);
>
> patchbays can check for this flag and represent the port as a
> different type (I've done it here myself as jack keeps any custom port
> flag values I set, and works just fine).
> in the jack library code we can check for the flag and not allow port
> connections.
>
> what do you think?
++
-dr
From malnourite at gmail.com Wed Apr 4 00:45:04 2012
From: malnourite at gmail.com (J. Liles)
Date: Tue, 3 Apr 2012 17:45:04 -0700
Subject: [LAD] JACK CV Ports API
In-Reply-To:
References:
Message-ID:
On Tue, Apr 3, 2012 at 4:24 PM, Filipe Lopes wrote:
> hey lads,
> sharing an idea I had here
>
> my (currently in development) host directly exposes plugin ports to jack -
> audio as audio, midi as midi, and parameters as a midi port for midi-cc
> usage.
> while coding for lv2 plugins, I noticed the CV port type, more info here:
> http://lv2plug.in/ns/ext/cv-port/
>
> I didn't yet coded support for it, but I'll do soon. Those kind of ports
> will be exposed to jack as pure audio ports.
> Non-daw and non-mixer also use this kind of ports, and maybe others.
> The problem is that users shouldn't connect normal audio and CV ports
> together...
>
> so I came up with an idea that is simple and fairly easy to implement - a
> new jack port flag.
>
> example:
> port = jack_port_register(client, port_name, JACK_DEFAULT_AUDIO_TYPE,
> JackPortIsInput|JackPortIsCV, 0);
>
> patchbays can check for this flag and represent the port as a different
> type (I've done it here myself as jack keeps any custom port flag values I
> set, and works just fine).
> in the jack library code we can check for the flag and not allow port
> connections.
>
> what do you think?
>
>
BTW, SpiralSynthModular is another program that uses JACK audio ports for
CV.
Seems perfectly reasonable to me, although I would rather it be the
connection manager that disallows the connections rather than JACK itself.
Some users may have valid reasons for wanting to force a connection between
Audio and CV ports (such as sending an analog control voltage signal out of
the audio interface)... And consider the case right now for programs which
have not been updated to set the appropriate flag on their CV ports--those
connections would have to be forced until the programs are updated. But
even if the connection manager just used the information to display the
ports in a different color, it would still be useful. Also, obviously you
need a #define or something to indicate that the version of libjack has the
enum for CV ports.
As you point out, it's a very simple change and I think it's about time we
had *something* in place for this and in lieu of arbitrary port types and
data representations, this will certainly work for the CV case.
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
From louigi.verona at gmail.com Wed Apr 4 08:11:49 2012
From: louigi.verona at gmail.com (Louigi Verona)
Date: Wed, 4 Apr 2012 12:11:49 +0400
Subject: [LAD] NSM - handling large files
In-Reply-To:
References:
<20120403054905.GB3415@sprite>
<9264a665805b61a7c3ef4d8d2521ce07@rncbc.org>
<4F7AC51E.7070507@gmail.com>
<5e25fdd113b7a6d1b04d4dbf8253787d@rncbc.org>
<4F7AF338.7080605@gmail.com> <4F7B2D95.5030202@rncbc.org>
Message-ID:
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/
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
From xbran at web.de Wed Apr 4 09:06:00 2012
From: xbran at web.de (Emanuel Rumpf)
Date: Wed, 4 Apr 2012 09:06:00 +0000
Subject: [LAD] NSM - handling large files
In-Reply-To:
References:
<20120403054905.GB3415@sprite>
<9264a665805b61a7c3ef4d8d2521ce07@rncbc.org>
<4F7AC51E.7070507@gmail.com>
<5e25fdd113b7a6d1b04d4dbf8253787d@rncbc.org>
<4F7AF338.7080605@gmail.com> <4F7B2D95.5030202@rncbc.org>
Message-ID:
Am 4. April 2012 08:11 schrieb Louigi Verona :
> 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.
From rosea.grammostola at gmail.com Wed Apr 4 11:18:07 2012
From: rosea.grammostola at gmail.com (rosea.grammostola)
Date: Wed, 04 Apr 2012 13:18:07 +0200
Subject: [LAD] NSM - handling large files
In-Reply-To: <4F7B2D95.5030202@rncbc.org>
References: "\"" " <20120403054905.GB3415@sprite> <9264a665805b61a7c3ef4d8d2521ce07@rncbc.org> <4F7AC51E.7070507@gmail.com> <5e25fdd113b7a6d1b04d4dbf8253787d@rncbc.org> <4F7AF338.7080605@gmail.com>
<4F7B2D95.5030202@rncbc.org>
Message-ID: <4F7C2DEF.5000504@gmail.com>
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
From rncbc at rncbc.org Wed Apr 4 12:22:39 2012
From: rncbc at rncbc.org (Rui Nuno Capela)
Date: Wed, 04 Apr 2012 13:22:39 +0100
Subject: [LAD] NSM - handling large files
In-Reply-To: <4F7C2DEF.5000504@gmail.com>
References: "\"" " <20120403054905.GB3415@sprite> <9264a665805b61a7c3ef4d8d2521ce07@rncbc.org> <4F7AC51E.7070507@gmail.com> <5e25fdd113b7a6d1b04d4dbf8253787d@rncbc.org> <4F7AF338.7080605@gmail.com>
<4F7B2D95.5030202@rncbc.org> <4F7C2DEF.5000504@gmail.com>
Message-ID: <4F7C3D0F.5030206@rncbc.org>
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
rncbc at rncbc.org
From rosea.grammostola at gmail.com Wed Apr 4 12:35:53 2012
From: rosea.grammostola at gmail.com (rosea.grammostola)
Date: Wed, 04 Apr 2012 14:35:53 +0200
Subject: [LAD] NSM - handling large files
In-Reply-To: <4F7C3D0F.5030206@rncbc.org>
References: "\"" " <20120403054905.GB3415@sprite> <9264a665805b61a7c3ef4d8d2521ce07@rncbc.org> <4F7AC51E.7070507@gmail.com> <5e25fdd113b7a6d1b04d4dbf8253787d@rncbc.org> <4F7AF338.7080605@gmail.com> <4F7B2D95.5030202@rncbc.org>
<4F7C2DEF.5000504@gmail.com> <4F7C3D0F.5030206@rncbc.org>
Message-ID: <4F7C4029.1070503@gmail.com>
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
From xbran at web.de Wed Apr 4 13:25:02 2012
From: xbran at web.de (Emanuel Rumpf)
Date: Wed, 4 Apr 2012 13:25:02 +0000
Subject: [LAD] NSM - handling large files
In-Reply-To: <4F7C2DEF.5000504@gmail.com>
References: