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.


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

















_______________________________________________
Linux-audio-dev mailing list
[email protected]
http://lists.linuxaudio.org/listinfo/linux-audio-dev

Reply via email to