[LAD] Non Session Management

rosea.grammostola rosea.grammostola at gmail.com
Thu Mar 29 10:08:05 UTC 2012


On 03/29/2012 11:41 AM, rosea.grammostola wrote:
> On 03/29/2012 12:02 PM, Louigi Verona wrote:
>> my 2 cents from user perspective: I know where I save my files, I know
>> where my sample collections are. i know that if i delete my sample
>> collection, sessions won't load. i don't need any program to tell me
>> that.
>>
>> in fact, in using FL Studio or Cubase or LMMS you have the same
>> situation. a project can use same files as another project and if you
>> damage those files - well, sorry.

Ah your reply was a reaction on the 'saving large file in NSM 
discussion'. I would suggest you to quote the relevant part of the 
discussion and then type your reply, otherwise it's hard follow the 
discussion(s).

\r


>>
>
> Where are we talking about? The fact that the session manager manages
> the saving of the projects only? E.g. that's not possible to save a
> yoshimi 'project' from the GUI in Yoshimi when Yoshimi is in a session.
> (see below for details ***)
>
> It's a good thing to discuss indeed!
>
> The situation with a session is different I think. In your examples you
> use one application. In a Ardour session files are stored in the project
> folder normally.
>
> With a session you use more then one different applications, that's
> makes the stuff rather complex. I see an good point in making the
> situation less complex for and by the SM.
> Afaik you can do with your files what you want, by copying or moving
> from the NON Session folder.
> I also expect that an Ardour project saved in a NSM session, can also be
> opened by Ardour without being in a NSM session.
> Also I guess it will be still possible to export files (and import) from
> Ardour to anywhere you want, if Ardour would be in a NSM session.
>
> An example why this can be useful is the problems I had using
> JackSession with Hydrogen. Hydrogen didn't do the saving of the session
> folder and the hydrogen project right. This was probably avoided when
> they added NSM and followed the strict rules of it.
>
>
>
>> I do not see any reason for complications in session manager design. i
>> agree with david, all of this is unnecessary and only will make NSM a
>> session manager developers would be reluctant to adopt.
>
> That's how you see it, but the question is, is this true? Maybe we
> should let the developers speak for themselves. It would be good anyway
> that they speak out.
>
> It might be good if Jonathan Liles explains here why he has made the
> choice.
>
> \r
>
>
> ***
>
> 1.1.1. New
>
> This option may empty/reset the current file or project (possibly after
> user confirmation). UNDER NO CIRCUMSTANCES should it allow the user to
> create a new project/file in another location.
> 1.1.2. Open
>
> This option MUST be disabled.
>
> The application may, however, elect to implement an option called
> 'Import into Session', creates a copy of a file/project which is then
> saved at the session path provided by NSM.
> 1.1.3. Save
>
> This option should behave as normal, saving the current file/project as
> established by the NSM open message.
>
> UNDER NO CIRCUMSTANCES should this option present the user with a choice
> of where to save the file.
> 1.1.4. Save As
>
> This option MUST be disabled.
>
> The application may, however, elect to implement an option called
> 'Export from Session', which creates a copy of the current file/project
> which is then saved in a user-specified location outside of the session
> path provided by NSM.
> 1.1.5. Close (as distinguished from Quit or Exit)
>
> This option MUST be disabled unless its meaning is to disconnect the
> application from session management.
> 1.1.6. Quit or Exit
>
> This option may behave as normal (possibly asking the user to confirm
> exiting).
>
>
>
> http://non.tuxfamily.org/nsm/API.html
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>




More information about the Linux-audio-dev mailing list