29 Mar
2012
29 Mar
'12
1:08 p.m.
On 03/29/2012 11:41 AM, rosea.grammostola wrote:
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.
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
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