linuxaudio.org

On Thu, 2012-04-05 at 12:14 +0100, Rui Nuno Capela wrote:

quoted text
> On 04/05/2012 12:25 AM, David Robillard wrote:

> > On Tue, 2012-04-03 at 18:04 +0100, Rui Nuno Capela wrote:

> > [...]

> >> ardour gets all its stuff under one own session directory, on a per

> >> session/project basis, iirc just like NSM mandates,

> >>

> >> bbbuuuuuut...:) making that one and the same directory as from an

> >> outsider/independent session manager like NSM is asking for a lot of

> >> file and symlink juggling, if you ask me

[...]

quoted text
> > 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.

[...]

quoted text
> 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

quoted text
> 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

quoted text
> 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

quoted text
> 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

quoted text
> their own file new, open, save, and save as... menu operations are made

> completely orthogonal and independent of any general SM open/save ones.

>

> try that with the not-so-edgy (mainstream?) applications ;)

It's not any different for any applications, loading existing stuff is

loading existing stuff.  Things will indeed need to be copied or moved.

Unfortunate, perhaps, but necessary.
Your knee-jerk desire to defend qtractor's saving scheme at all costs

with a death-by-emoticon blitzkrieg is obscuring the fact that all of

this is inherent to session management.  Qtractor has problems with it

because qtractor has problems with it.  There is no working scheme

qtractor would have less problems with, because they are inherent

problems with qtractor + SM, not the SM itself.
Back in the realm of "solving problems" rather than "inflating egos",

there are two approaches you can use:
1) Completely save everything within the SM directory

2) Make your XML file point to links in the SM directory which point to

the configured store location
Sound familiar?  It should, because it's precisely what every other app

has to do to refer to "external files".  Qtractor just uses every file

as external files.
Of course, number 2 is completely pointless and silly unless sessions

share these files, but that doesn't really matter.  The solution is the

same in any case.
You may not particularly like this because qtractor does not currently

save in either way, meaning you have to implement a new saving scheme,

but... well, qtractor simply doesn't currently save in a way that makes

SM work.  To make it do so, yep, obviously gonna be a bit of work,

because it doesn't right now.
If you don't want to support it, then simply don't support it, but don't

try to paint that as a failing of the SM.  It's not.
-dr
_______________________________________________

Linux-audio-dev mailing list

Linux-audio-dev@lists.linuxaudio.org

http://lists.linuxaudio.org/listinfo/linux-audio-dev