[LAD] NSM - handling large files

Rui Nuno Capela rncbc at rncbc.org
Thu Apr 5 16:20:19 UTC 2012


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
rncbc at rncbc.org



More information about the Linux-audio-dev mailing list