[LAD] NSM - handling large files

J. Liles malnourite at gmail.com
Mon Apr 2 17:17:13 UTC 2012


On Mon, Apr 2, 2012 at 9:11 AM, rosea.grammostola
<rosea.grammostola at 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."



More information about the Linux-audio-dev mailing list