Re: jOrgan>File>Save FEATURE

classic Classic list List threaded Threaded
27 messages Options
12
Reply | Threaded
Open this post in threaded view
|

Re: jOrgan>File>Save FEATURE

jbeach2646
Would it be possible to add a “Save AS...” feature to the File Menu in jOrgan?  This would allow a disposition to be loaded, changed significantly with respect to Customizer, Input and Output
in Fluidsynth, etc., and, then, saved as a different,  titled disposition.   What I have always done is to make a copy of a disposition in the jOrgan folder and, then, rename it to purpose, and, then,
open the renamed disposition in jOrgan, make desired changes and, then, Save it.   Most Windows programs have the “Save As....” option which is really beneficial when significant changes
have been made to an original file and both the original and the edited version of it are desired to be kept.  Opening a file in Windows, generally, means a copy of the original is imported and
the changes made, if “Save(d),” are saved to the original file.  However, if the “Save As...”  feature is used, the original file is unaffected by the changes and the “Saved As Renamed” file, only,
contains the edited changes.  The obvious advantage of this is that when a desired change or edition is made to a disposition in the course of using it, it may prove to be undesirable.  Preserving the original, unedited, such as “Save As...” allows,  is really beneficial.
 
John Beach

------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
jOrgan-user mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/jorgan-user
Reply | Threaded
Open this post in threaded view
|

Re: jOrgan>File>Save FEATURE

jOrgan - User mailing list
AGREED!

A "SAVE AS" feature would certainly help!

:>)
pk

Friday, June 1, 2018, 10:27 AM PDT, John Beach wrote:

<snip>
Would it be possible to add a “Save AS...” feature to the File Menu in jOrgan?  This would allow a disposition to be loaded, changed significantly with respect to Most Windows programs have the “Save As....” option which is really beneficial when significant changes

The obvious advantage of this is that when a desired change or edition is made to a disposition in the course of using it, it may prove to be undesirable.  Preserving the original, unedited, such as “Save As...” allows,  is really beneficial.
 
<snip>


------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
jOrgan-user mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/jorgan-user
Reply | Threaded
Open this post in threaded view
|

Re: jOrgan>File>Save FEATURE

RoyR
   This question was asked several times when Sven was the boss man and the answer was always a resounding "No". I understand (Or rather don't, really, not being a Java programmer!) that it is technically difficult and would involve a major change of structure. Any Java experts care to comment?

      Have fun,

            Roy.



On Fri, 1 Jun 2018 at 18:43, Paul Kealy via jOrgan-user <[hidden email]> wrote:
AGREED!

A "SAVE AS" feature would certainly help!

:>)
pk

Friday, June 1, 2018, 10:27 AM PDT, John Beach wrote:

<snip>
Would it be possible to add a “Save AS...” feature to the File Menu in jOrgan?  This would allow a disposition to be loaded, changed significantly with respect to Most Windows programs have the “Save As....” option which is really beneficial when significant changes

The obvious advantage of this is that when a desired change or edition is made to a disposition in the course of using it, it may prove to be undesirable.  Preserving the original, unedited, such as “Save As...” allows,  is really beneficial.
 
<snip>

------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot_______________________________________________
jOrgan-user mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/jorgan-user

------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
jOrgan-user mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/jorgan-user
Reply | Threaded
Open this post in threaded view
|

Re: jOrgan>File>Save FEATURE

jbeach2646
Roy, perhaps, it is the difference between “Construct Mode” –Save—, and File>Save in “Console Mode”.  As elements are created or changes are made to the disposition, in Construct Mode, they are saved to the disposition.  However, in Console Mode, usually at the shutdown of jOrgan, the pop-up window asks whether the disposition is to be saved.  You have to answer before
jOrgan will shut down.
 
We discussed the possibility of a “Customizer Module” within jOrgan which would allow the semi-permanent storage of a user’s specific devices’  Inputs/Outputs with respect to a PC, to which a disposition would be “connected” on importing.  Somewhat like, “here’s what’s available, use it!”  or “My alternatives of choice are somewhat limited, deal with it.”
 
John Beach
 
Sent: Friday, June 1, 2018 2:01 PM
Subject: Re: [jOrgan-user] jOrgan>File>Save FEATURE
 
   This question was asked several times when Sven was the boss man and the answer was always a resounding "No". I understand (Or rather don't, really, not being a Java programmer!) that it is technically difficult and would involve a major change of structure. Any Java experts care to comment?
 
      Have fun,

            Roy.
 
 
 
On Fri, 1 Jun 2018 at 18:43, Paul Kealy via jOrgan-user <[hidden email]> wrote:
AGREED!

A "SAVE AS" feature would certainly help!
 
:>)
pk
 
Friday, June 1, 2018, 10:27 AM PDT, John Beach wrote:

<snip>
Would it be possible to add a “Save AS...” feature to the File Menu in jOrgan?  This would allow a disposition to be loaded, changed significantly with respect to Most Windows programs have the “Save As....” option which is really beneficial when significant changes

The obvious advantage of this is that when a desired change or edition is made to a disposition in the course of using it, it may prove to be undesirable.  Preserving the original, unedited, such as “Save As...” allows,  is really beneficial.
 
<snip>
 
------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot_______________________________________________
jOrgan-user mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/jorgan-user


------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot


_______________________________________________
jOrgan-user mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/jorgan-user

------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
jOrgan-user mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/jorgan-user
Reply | Threaded
Open this post in threaded view
|

Re: jOrgan>File>Save FEATURE

jOrgan - User mailing list
In reply to this post by RoyR

When I am experimenting with a disposition I simply copy it to a new folder with “test” in the name… no problem then.

Cheers

Marc-Paul

 


From: Roy Radford [mailto:[hidden email]]
Sent: Friday, June 01, 2018 1:02 PM
To: jorgan-user
Subject: Re: [jOrgan-user] jOrgan>File>Save FEATURE

 

   This question was asked several times when Sven was the boss man and the answer was always a resounding "No". I understand (Or rather don't, really, not being a Java programmer!) that it is technically difficult and would involve a major change of structure. Any Java experts care to comment?

 

      Have fun,

 

            Roy.

 

 

 

On Fri, 1 Jun 2018 at 18:43, Paul Kealy via jOrgan-user <[hidden email]> wrote:

AGREED!


A "SAVE AS" feature would certainly help!

 

:>)

pk

 

Friday, June 1, 2018, 10:27 AM PDT, John Beach wrote:

 

<snip>

Would it be possible to add a “Save AS...” feature to the File Menu in jOrgan?  This would allow a disposition to be loaded, changed significantly with respect to Most Windows programs have the “Save As....” option which is really beneficial when significant changes

 

The obvious advantage of this is that when a desired change or edition is made to a disposition in the course of using it, it may prove to be undesirable.  Preserving the original, unedited, such as “Save As...” allows,  is really beneficial.

 

<snip>

 

------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot_______________________________________________
jOrgan-user mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/jorgan-user


------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
jOrgan-user mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/jorgan-user
Reply | Threaded
Open this post in threaded view
|

Re: jOrgan>File>Save FEATURE

Aaron Laws
In reply to this post by RoyR
On Fri, Jun 1, 2018 at 2:01 PM, Roy Radford <[hidden email]> wrote:
   This question was asked several times when Sven was the boss man and the answer was always a resounding "No". I understand (Or rather don't, really, not being a Java programmer!) that it is technically difficult and would involve a major change of structure. Any Java experts care to comment?

      Have fun,

            Roy.

I'm quite familiar with java, but I would imagine any vehement objection to this feature would be on principle rather than technical grounds. Do you have any comments from the archive handy?

------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
jOrgan-user mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/jorgan-user
Reply | Threaded
Open this post in threaded view
|

Re: jOrgan>File>Save FEATURE

John Reimer
Administrator
Aaron,

I have already looked for the relevant thread by doing a Forum archive
search, and for some reason failed to find it. I think that Rick (Greenfox)
has the details at his fingertips. The matter has been discussed a number of
times over the years, and Sven was quite resolute in his opposition to it. I
think it has something to do with getting things out of kilter with the path
details of various associated files. It is too easy to create big problems
if the Save As function is made available. It is much better to require
users to move the disposition file somewhere, rename it, and then move it
back.

John Reimer



--
Sent from: http://jorgan.999862.n4.nabble.com/jOrgan-User-f999863.html

------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
jOrgan-user mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/jorgan-user
Reply | Threaded
Open this post in threaded view
|

Re: jOrgan>File>Save FEATURE

RoyR
In reply to this post by Aaron Laws
No, anything I had is lost in the mists of time but I think it was something to do with the extra files that are saved with a Disposition, things like the Memory file and links to Soundfonts etc, whether they are all renamed along with the Disposition. I sometimes used to rename the Disposition outside jOrgan and leave it linked to the same Memory file. I don't need the Soundfont files as I use external hardware synths. (Edirol SD-20s).

      Have fun,

            Roy.



On Sun, 3 Jun 2018 at 12:05, Aaron Laws <[hidden email]> wrote:
On Fri, Jun 1, 2018 at 2:01 PM, Roy Radford <[hidden email]> wrote:
   This question was asked several times when Sven was the boss man and the answer was always a resounding "No". I understand (Or rather don't, really, not being a Java programmer!) that it is technically difficult and would involve a major change of structure. Any Java experts care to comment?

      Have fun,

            Roy.

I'm quite familiar with java, but I would imagine any vehement objection to this feature would be on principle rather than technical grounds. Do you have any comments from the archive handy?
------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot_______________________________________________
jOrgan-user mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/jorgan-user

------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
jOrgan-user mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/jorgan-user
Reply | Threaded
Open this post in threaded view
|

Re: jOrgan>File>Save FEATURE

John Reimer
Administrator
In reply to this post by John Reimer
John Reimer wrote
> It is much better to require users to move the disposition file somewhere,
> rename it, and then move it back.

Sorry. That should have read, "It is much better to require users to COPY
the disposition file somewhere, rename it, and then move it 'back'."

John Reimer




--
Sent from: http://jorgan.999862.n4.nabble.com/jOrgan-User-f999863.html

------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
jOrgan-user mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/jorgan-user
Reply | Threaded
Open this post in threaded view
|

Re: jOrgan>File>Save FEATURE

RoyR
In reply to this post by John Reimer
I do the same but Save As was handy if you just wanted to try a few quick experiments without risking the working Disposition.

      Have fun,

            Roy.



On Sun, 3 Jun 2018 at 12:29, John Reimer <[hidden email]> wrote:
Aaron,

I have already looked for the relevant thread by doing a Forum archive
search, and for some reason failed to find it. I think that Rick (Greenfox)
has the details at his fingertips. The matter has been discussed a number of
times over the years, and Sven was quite resolute in his opposition to it. I
think it has something to do with getting things out of kilter with the path
details of various associated files. It is too easy to create big problems
if the Save As function is made available. It is much better to require
users to move the disposition file somewhere, rename it, and then move it
back.

John Reimer



--
Sent from: http://jorgan.999862.n4.nabble.com/jOrgan-User-f999863.html

------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
jOrgan-user mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/jorgan-user

------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
jOrgan-user mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/jorgan-user
Reply | Threaded
Open this post in threaded view
|

Re: jOrgan>File>Save FEATURE

lwalls
In reply to this post by jbeach2646
The problem with "Save As" is not technical (as, for example, some kind of Java issue).
The real problem with "Save As" is: What to do about the .memory file?

When you configure a "Memory Level" element in jOrgan it creates, by default ANOTHER
separate file named the same as the .disposition, but with the ".memory" suffix.
AND, a reference to that file is embedded within the .disposition as the content of the
"Storage" property of the "Memory Level" element.

Now, suppose you would want to save disp1.disposition as disp2.disposition.  Would you
also want to make a copy of disp1.memory and name it disp2.memory?  If so, you would also
have to go into the disp2.disposition file and CHANGE the Storage property of the Memory
Level element to reference the file name: disp2.memory.

But what if you had overridden the default name in the Storage property and named it
something like xyz.memory...a perfectly acceptable option.  Now, when you save
disp1.disposition as disp2.disposition do you make a copy of the xyz.memory file and name
it something else? if so, what?

Or do you leave it named as is: xyz.memory?

Now you have TWO different dispositions (disp1 and disp2) that reference the SAME
xyz.memory file.  Now suppose you edit disp2.disposition and make changes to some things
that are stored in the xyz.memory file.  Then you play disp2 and make memory level
changes.  Now when you go back to play disp1, its stored Memory Level settings retrieved
from the xyz.memory file that disp2 changed may be corrupted.  What do you do about this
situation?

Another hitch: What if you actually DO want two or more different dispositions to all
reference the SAME .memory file.  In this case you don't want some "Save As" operation
copying and changing the name of the .memory file...or do you?

And what about the case where the .disposition file and the .memory file are located in
different folders/directories?  And what if the "Save As" folder/directory different from
those other two?  Is the .memory file copied and renamed to the third folder, or does it
remain in its original folder and just gets renamed?

And what if disp1 has MULTIPLE Memory Level elements (no unheard of), and each one points
to a DIFFERENT .memory file.  Now you have all the above issues and more.

Lots of questions...and no answers...thus: no "Save As" function in jOrgan.

At least when YOU have to do the copying and renaming OUTSIDE of jOrgan, it is YOU who
becomes resposible for answering for and dealing with any of these issues that may be
present in YOUR particular case -- not the jOrgan developer.

CLW
--------------------------------------------------------------------


On 6/1/2018 1:27 PM, John Beach wrote:

> Would it be possible to add a “Save AS...” feature to the File Menu in jOrgan?  This would
> allow a disposition to be loaded, changed significantly with respect to Customizer, Input
> and Output
> in Fluidsynth, etc., and, then, saved as a different,  titled disposition.   What I have
> always done is to make a copy of a disposition in the jOrgan folder and, then, rename it
> to purpose, and, then,
> open the renamed disposition in jOrgan, make desired changes and, then, Save it.   Most
> Windows programs have the “Save As....” option which is really beneficial when significant
> changes
> have been made to an original file and both the original and the edited version of it are
> desired to be kept.  Opening a file in Windows, generally, means a copy of the original is
> imported and
> the changes made, if “Save(d),” are saved to the original file. However, if the “Save
> As...”  feature is used, the original file is unaffected by the changes and the “Saved As
> Renamed” file, only,
> contains the edited changes.  The obvious advantage of this is that when a desired change
> or edition is made to a disposition in the course of using it, it may prove to be
> undesirable.  Preserving the original, unedited, such as “Save As...” allows,  is really
> beneficial.

------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
jOrgan-user mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/jorgan-user
Reply | Threaded
Open this post in threaded view
|

Re: jOrgan>File>Save FEATURE

eagles051387
Here is an interesting idea,

Instead of save as you have a versioning function? One you can see the evolution of your disposition if you don’t like changes you made you would easily have a previous version available.

Sent from my iPhone

> On 03 Jun 2018, at 15:13, Lynn Walls <[hidden email]> wrote:
>
> The problem with "Save As" is not technical (as, for example, some kind of Java issue). The real problem with "Save As" is: What to do about the .memory file?
>
> When you configure a "Memory Level" element in jOrgan it creates, by default ANOTHER separate file named the same as the .disposition, but with the ".memory" suffix.
> AND, a reference to that file is embedded within the .disposition as the content of the "Storage" property of the "Memory Level" element.
>
> Now, suppose you would want to save disp1.disposition as disp2.disposition.  Would you also want to make a copy of disp1.memory and name it disp2.memory?  If so, you would also
> have to go into the disp2.disposition file and CHANGE the Storage property of the Memory Level element to reference the file name: disp2.memory.
>
> But what if you had overridden the default name in the Storage property and named it something like xyz.memory...a perfectly acceptable option.  Now, when you save disp1.disposition as disp2.disposition do you make a copy of the xyz.memory file and name it something else? if so, what?
>
> Or do you leave it named as is: xyz.memory?
>
> Now you have TWO different dispositions (disp1 and disp2) that reference the SAME xyz.memory file.  Now suppose you edit disp2.disposition and make changes to some things that are stored in the xyz.memory file.  Then you play disp2 and make memory level changes.  Now when you go back to play disp1, its stored Memory Level settings retrieved from the xyz.memory file that disp2 changed may be corrupted.  What do you do about this situation?
>
> Another hitch: What if you actually DO want two or more different dispositions to all reference the SAME .memory file.  In this case you don't want some "Save As" operation copying and changing the name of the .memory file...or do you?
>
> And what about the case where the .disposition file and the .memory file are located in different folders/directories?  And what if the "Save As" folder/directory different from those other two?  Is the .memory file copied and renamed to the third folder, or does it remain in its original folder and just gets renamed?
>
> And what if disp1 has MULTIPLE Memory Level elements (no unheard of), and each one points to a DIFFERENT .memory file.  Now you have all the above issues and more.
>
> Lots of questions...and no answers...thus: no "Save As" function in jOrgan.
>
> At least when YOU have to do the copying and renaming OUTSIDE of jOrgan, it is YOU who becomes resposible for answering for and dealing with any of these issues that may be present in YOUR particular case -- not the jOrgan developer.
>
> CLW
> --------------------------------------------------------------------
>
>
>> On 6/1/2018 1:27 PM, John Beach wrote:
>> Would it be possible to add a “Save AS...” feature to the File Menu in jOrgan?  This would allow a disposition to be loaded, changed significantly with respect to Customizer, Input and Output
>> in Fluidsynth, etc., and, then, saved as a different,  titled disposition.   What I have always done is to make a copy of a disposition in the jOrgan folder and, then, rename it to purpose, and, then,
>> open the renamed disposition in jOrgan, make desired changes and, then, Save it.   Most Windows programs have the “Save As....” option which is really beneficial when significant changes
>> have been made to an original file and both the original and the edited version of it are desired to be kept.  Opening a file in Windows, generally, means a copy of the original is imported and
>> the changes made, if “Save(d),” are saved to the original file. However, if the “Save As...”  feature is used, the original file is unaffected by the changes and the “Saved As Renamed” file, only,
>> contains the edited changes.  The obvious advantage of this is that when a desired change or edition is made to a disposition in the course of using it, it may prove to be undesirable.  Preserving the original, unedited, such as “Save As...” allows,  is really beneficial.
>
> ------------------------------------------------------------------------------
> Check out the vibrant tech community on one of the world's most
> engaging tech sites, Slashdot.org! http://sdm.link/slashdot
> _______________________________________________
> jOrgan-user mailing list
> [hidden email]
> https://lists.sourceforge.net/lists/listinfo/jorgan-user

------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
jOrgan-user mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/jorgan-user
Reply | Threaded
Open this post in threaded view
|

Re: jOrgan>File>Save FEATURE

Aaron Laws
In reply to this post by lwalls

On Sun, Jun 3, 2018 at 9:13 AM, Lynn Walls <[hidden email]> wrote:
The problem with "Save As" is not technical (as, for example, some kind of Java issue). The real problem with "Save As" is: What to do about the .memory file?

When you configure a "Memory Level" element in jOrgan it creates, by default ANOTHER separate file named the same as the .disposition, but with the ".memory" suffix.
AND, a reference to that file is embedded within the .disposition as the content of the "Storage" property of the "Memory Level" element.

Now, suppose you would want to save disp1.disposition as disp2.disposition.  Would you also want to make a copy of disp1.memory and name it disp2.memory?  If so, you would also
have to go into the disp2.disposition file and CHANGE the Storage property of the Memory Level element to reference the file name: disp2.memory.

But what if you had overridden the default name in the Storage property and named it something like xyz.memory...a perfectly acceptable option.  Now, when you save disp1.disposition as disp2.disposition do you make a copy of the xyz.memory file and name it something else? if so, what?

Or do you leave it named as is: xyz.memory?

Now you have TWO different dispositions (disp1 and disp2) that reference the SAME xyz.memory file.  Now suppose you edit disp2.disposition and make changes to some things that are stored in the xyz.memory file.  Then you play disp2 and make memory level changes.  Now when you go back to play disp1, its stored Memory Level settings retrieved from the xyz.memory file that disp2 changed may be corrupted.  What do you do about this situation?

Another hitch: What if you actually DO want two or more different dispositions to all reference the SAME .memory file.  In this case you don't want some "Save As" operation copying and changing the name of the .memory file...or do you?

And what about the case where the .disposition file and the .memory file are located in different folders/directories?  And what if the "Save As" folder/directory different from those other two?  Is the .memory file copied and renamed to the third folder, or does it remain in its original folder and just gets renamed?

And what if disp1 has MULTIPLE Memory Level elements (no unheard of), and each one points to a DIFFERENT .memory file.  Now you have all the above issues and more.

Lots of questions...and no answers...thus: no "Save As" function in jOrgan.

At least when YOU have to do the copying and renaming OUTSIDE of jOrgan, it is YOU who becomes resposible for answering for and dealing with any of these issues that may be present in YOUR particular case -- not the jOrgan developer.

CLW

Excellent observation. So it's not as trivial as "Save As" a text document. I suppose a feature like this would have either to prompt the user for the new memory file, or perhaps have a sensible default (perhaps copy the referenced memory file to the new disposition name, but with a ".memory" suffix). Then again, why is the .memory file separate? Perhaps it could be included in the disposition? Maybe the intent was to be able to have an artificially larger memory bank so that, for instance, multiple organists can each have their own .memory file to make sharing the organ easier. Also this makes it more practical for a virtual organ to have the same memory limitations as the organ being imitated: in the case that the original organ has a painfully small memory bank, this is somewhat alleviated by being able to change out .memory files.

------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
jOrgan-user mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/jorgan-user
Reply | Threaded
Open this post in threaded view
|

Re: jOrgan>File>Save FEATURE

jbeach2646
In reply to this post by eagles051387
Thanks, Lynn and Jonathan, for you comments on the "Save As..." idea.  As I
said at the start of my initial post, my practice has been to go to the
jOrgan folder and Dispositions and to make
a copy of a disposition, renaming the copy to indicate the difference I wish
to delineate.  Most often, the need for two dispositions which are identical
copies has to do with the two different
usages, organ playing and midi file playback which require two different
setups with respect to input, USB-Midi Cable for organ playing and Loopbe
Virtual Midi Cable for Midi Sequencer program input.  Also, I, frequently,
listen to jOrgan with earphones, but also have the capability to play
through amplified speakers from multiple soundcards, so the desirability of
having
the dispositions with "preset inputs/outputs" eliminates the need to make
those changes each time a disposition loads.
The explanation about the .memory is interesting and I have never seen that
because I don't use memory levels, so I have never seen a disposition.memory
file in any of my homemade
dispositions, although I have seen them in some of the dispositions created
by other members of the forum.

John Beach

-----Original Message-----
From: Jonathan Aquilina
Sent: Sunday, June 3, 2018 11:54 AM
To: [hidden email]
Subject: Re: [jOrgan-user] jOrgan>File>Save FEATURE

Here is an interesting idea,

Instead of save as you have a versioning function? One you can see the
evolution of your disposition if you don’t like changes you made you would
easily have a previous version available.

Sent from my iPhone

> On 03 Jun 2018, at 15:13, Lynn Walls <[hidden email]> wrote:
>
> The problem with "Save As" is not technical (as, for example, some kind of
> Java issue). The real problem with "Save As" is: What to do about the
> .memory file?
>
> When you configure a "Memory Level" element in jOrgan it creates, by
> default ANOTHER separate file named the same as the .disposition, but with
> the ".memory" suffix.
> AND, a reference to that file is embedded within the .disposition as the
> content of the "Storage" property of the "Memory Level" element.
>
> Now, suppose you would want to save disp1.disposition as
> disp2.disposition.  Would you also want to make a copy of disp1.memory and
> name it disp2.memory?  If so, you would also
> have to go into the disp2.disposition file and CHANGE the Storage property
> of the Memory Level element to reference the file name: disp2.memory.
>
> But what if you had overridden the default name in the Storage property
> and named it something like xyz.memory...a perfectly acceptable option.
> Now, when you save disp1.disposition as disp2.disposition do you make a
> copy of the xyz.memory file and name it something else? if so, what?
>
> Or do you leave it named as is: xyz.memory?
>
> Now you have TWO different dispositions (disp1 and disp2) that reference
> the SAME xyz.memory file.  Now suppose you edit disp2.disposition and make
> changes to some things that are stored in the xyz.memory file.  Then you
> play disp2 and make memory level changes.  Now when you go back to play
> disp1, its stored Memory Level settings retrieved from the xyz.memory file
> that disp2 changed may be corrupted.  What do you do about this situation?
>
> Another hitch: What if you actually DO want two or more different
> dispositions to all reference the SAME .memory file.  In this case you
> don't want some "Save As" operation copying and changing the name of the
> .memory file...or do you?
>
> And what about the case where the .disposition file and the .memory file
> are located in different folders/directories?  And what if the "Save As"
> folder/directory different from those other two?  Is the .memory file
> copied and renamed to the third folder, or does it remain in its original
> folder and just gets renamed?
>
> And what if disp1 has MULTIPLE Memory Level elements (no unheard of), and
> each one points to a DIFFERENT .memory file.  Now you have all the above
> issues and more.
>
> Lots of questions...and no answers...thus: no "Save As" function in
> jOrgan.
>
> At least when YOU have to do the copying and renaming OUTSIDE of jOrgan,
> it is YOU who becomes resposible for answering for and dealing with any of
> these issues that may be present in YOUR particular case -- not the jOrgan
> developer.
>
> CLW
> --------------------------------------------------------------------
>
>
>> On 6/1/2018 1:27 PM, John Beach wrote:
>> Would it be possible to add a “Save AS...” feature to the File Menu in
>> jOrgan?  This would allow a disposition to be loaded, changed
>> significantly with respect to Customizer, Input and Output
>> in Fluidsynth, etc., and, then, saved as a different,  titled
>> disposition.   What I have always done is to make a copy of a disposition
>> in the jOrgan folder and, then, rename it to purpose, and, then,
>> open the renamed disposition in jOrgan, make desired changes and, then,
>> Save it.   Most Windows programs have the “Save As....” option which is
>> really beneficial when significant changes
>> have been made to an original file and both the original and the edited
>> version of it are desired to be kept.  Opening a file in Windows,
>> generally, means a copy of the original is imported and
>> the changes made, if “Save(d),” are saved to the original file. However,
>> if the “Save As...”  feature is used, the original file is unaffected by
>> the changes and the “Saved As Renamed” file, only,
>> contains the edited changes.  The obvious advantage of this is that when
>> a desired change or edition is made to a disposition in the course of
>> using it, it may prove to be undesirable.  Preserving the original,
>> unedited, such as “Save As...” allows,  is really beneficial.
>
> ------------------------------------------------------------------------------
> Check out the vibrant tech community on one of the world's most
> engaging tech sites, Slashdot.org! http://sdm.link/slashdot
> _______________________________________________
> jOrgan-user mailing list
> [hidden email]
> https://lists.sourceforge.net/lists/listinfo/jorgan-user

------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
jOrgan-user mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/jorgan-user 



------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
jOrgan-user mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/jorgan-user
Reply | Threaded
Open this post in threaded view
|

Re: jOrgan>File>Save FEATURE

John Reimer
Administrator
In reply to this post by lwalls
lwalls wrote
>  
> The real problem with "Save As" is: What to do about the .memory file?

Lynn,

Thank you for all that detail. I must confess it makes my eyes glaze over.
And not just because I have cataract operations awaiting me some time in the
future!

But the thought did occur do me, do you advise copying, renaming and
locating the whole folder where the particular disposition resides (as well
as renaming the disposition)? Is there any advantage in doing this?

John Reimer




--
Sent from: http://jorgan.999862.n4.nabble.com/jOrgan-User-f999863.html

------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
jOrgan-user mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/jorgan-user
Reply | Threaded
Open this post in threaded view
|

Re: jOrgan>File>Save FEATURE

jbeach2646
Also, if .memory files are so correlative to a .disposition, is that .memory
file loaded automatically with the disposition on opening.  And, if it does,
when a disposition is copied, is the
.memory file copied with it?
From the jOrgan Wiki, the purpose of the memory extension is stated below:

"The memory extension enables you to store the state of combinations:
The memory element is required to support combination levels in your
disposition.
The memory view controls memory levels."

I know that Memory is chosen from the View menu and has been a part of
jOrgan since the recorder element was added.  Memory must be selected along
with the recorder element when recording or playing back recordings.
Seemingly, this is a kind of "shell element,"  yet individualized by each
disposition and its stop complements and the referenced elements in
combinations.  This feature is, simply, effectuated by selecting it in the
jOrgan View menu and a .memory file is not stored in the disposition folder
of a particular disposition.
Apparently, if Memory Levels are created, the "Memory" file is stored
separately in the folder of the disposition with it, as I have seen this
file in the disposition folders of some
jOrgan disposition creators.

As I stated previously, my main reason for copying a disposition is to
obviate the need to reset MIDI inputs and outputs relative to organ playing
and Midi file play, respectively, and also the
audio outputs from a single soundcard source output for headphones and a
dual or multiple outputs for external audio amplifiers with multiple speaker
units.  So, technically, this does not
involve "Memory" at all and would not prevent or complicate a "Save As" File
menu feature.  Most MIDI sequencer programs allow all kinds of editions to
.mid files.  After they are all made,
the file can be saved as an entirely separate .mid file under a different
name, without changing the .mid original file which was the basis for it.
No copy of the original needs to be made before opening the copied file in
the MIDI sequencer program.  I believe this is, generally, true of most
Windows programs, that a file opened in most programs can be "Save(d) as..."
a new name, and the original, from which it is derived, will not be changed
with the "Save As" function.

John Beach















-----Original Message-----
From: John Reimer
Sent: Sunday, June 3, 2018 10:35 PM
To: [hidden email]
Subject: Re: [jOrgan-user] jOrgan>File>Save FEATURE

lwalls wrote
>
> The real problem with "Save As" is: What to do about the .memory file?

Lynn,

Thank you for all that detail. I must confess it makes my eyes glaze over.
And not just because I have cataract operations awaiting me some time in the
future!

But the thought did occur do me, do you advise copying, renaming and
locating the whole folder where the particular disposition resides (as well
as renaming the disposition)? Is there any advantage in doing this?

John Reimer




--
Sent from: http://jorgan.999862.n4.nabble.com/jOrgan-User-f999863.html

------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
jOrgan-user mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/jorgan-user 



------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
jOrgan-user mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/jorgan-user
Reply | Threaded
Open this post in threaded view
|

Re: jOrgan>File>Save FEATURE

greenfox
In reply to this post by John Reimer
Hi John

I don't remember when the discussion was, but do agree that the multiple associated files involved in a jOrgan disposition make a Save As function frought with danger.

The multiple associated files are both a blessing and a curse. I would suggest it could be argued to split off further things into individual files, like input console MIDI settings as an example. These should not be inextricably linked into a disposition, but should be able to be combined with a new disposition without requiring reconfiguring everything. 

To "repackage" a jOrgan disposition you really do need to create a new folder and ensure you have all the required files positioned correctly. 

Another concern of mine is that the jOrgan installer gives completely the wrong idea of how files and folders should be positioned. A lot of problems for novice users stem from this situation. 

Regards 
Rick

On Sun, 3 Jun 2018 9:29 pm John Reimer <[hidden email]> wrote:
Aaron,

I have already looked for the relevant thread by doing a Forum archive
search, and for some reason failed to find it. I think that Rick (Greenfox)
has the details at his fingertips. The matter has been discussed a number of
times over the years, and Sven was quite resolute in his opposition to it. I
think it has something to do with getting things out of kilter with the path
details of various associated files. It is too easy to create big problems
if the Save As function is made available. It is much better to require
users to move the disposition file somewhere, rename it, and then move it
back.

John Reimer



--
Sent from: http://jorgan.999862.n4.nabble.com/jOrgan-User-f999863.html

------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
jOrgan-user mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/jorgan-user

------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
jOrgan-user mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/jorgan-user
greenfox - Brisbane Queensland Australia
Reply | Threaded
Open this post in threaded view
|

Re: jOrgan>File>Save FEATURE

greenfox
In reply to this post by jbeach2646
There is not just the .memory file. There is also the .skin file. There may also be MIDI files, and if the disposition uses Fluidsynth there could be one or more .SF2 files, or some other link to samples. 

I agree, there should be an easier way to allow for input settings and output settings to be stored and recalled other than a complete copy of a disposition renamed.

The problem is that different people use jOrgan in different ways so what is a fix for one becomes a new problem for another. 

Regards 
Rick  

On Mon, 4 Jun 2018 5:19 pm John Beach <[hidden email]> wrote:
Also, if .memory files are so correlative to a .disposition, is that .memory
file loaded automatically with the disposition on opening.  And, if it does,
when a disposition is copied, is the
.memory file copied with it?
From the jOrgan Wiki, the purpose of the memory extension is stated below:

"The memory extension enables you to store the state of combinations:
The memory element is required to support combination levels in your
disposition.
The memory view controls memory levels."

I know that Memory is chosen from the View menu and has been a part of
jOrgan since the recorder element was added.  Memory must be selected along
with the recorder element when recording or playing back recordings.
Seemingly, this is a kind of "shell element,"  yet individualized by each
disposition and its stop complements and the referenced elements in
combinations.  This feature is, simply, effectuated by selecting it in the
jOrgan View menu and a .memory file is not stored in the disposition folder
of a particular disposition.
Apparently, if Memory Levels are created, the "Memory" file is stored
separately in the folder of the disposition with it, as I have seen this
file in the disposition folders of some
jOrgan disposition creators.

As I stated previously, my main reason for copying a disposition is to
obviate the need to reset MIDI inputs and outputs relative to organ playing
and Midi file play, respectively, and also the
audio outputs from a single soundcard source output for headphones and a
dual or multiple outputs for external audio amplifiers with multiple speaker
units.  So, technically, this does not
involve "Memory" at all and would not prevent or complicate a "Save As" File
menu feature.  Most MIDI sequencer programs allow all kinds of editions to
.mid files.  After they are all made,
the file can be saved as an entirely separate .mid file under a different
name, without changing the .mid original file which was the basis for it.
No copy of the original needs to be made before opening the copied file in
the MIDI sequencer program.  I believe this is, generally, true of most
Windows programs, that a file opened in most programs can be "Save(d) as..."
a new name, and the original, from which it is derived, will not be changed
with the "Save As" function.

John Beach















-----Original Message-----
From: John Reimer
Sent: Sunday, June 3, 2018 10:35 PM
To: [hidden email]
Subject: Re: [jOrgan-user] jOrgan>File>Save FEATURE

lwalls wrote
>
> The real problem with "Save As" is: What to do about the .memory file?

Lynn,

Thank you for all that detail. I must confess it makes my eyes glaze over.
And not just because I have cataract operations awaiting me some time in the
future!

But the thought did occur do me, do you advise copying, renaming and
locating the whole folder where the particular disposition resides (as well
as renaming the disposition)? Is there any advantage in doing this?

John Reimer




--
Sent from: http://jorgan.999862.n4.nabble.com/jOrgan-User-f999863.html

------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
jOrgan-user mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/jorgan-user



------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
jOrgan-user mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/jorgan-user

------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
jOrgan-user mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/jorgan-user
greenfox - Brisbane Queensland Australia
Reply | Threaded
Open this post in threaded view
|

Re: jOrgan>File>Save FEATURE

lwalls
In reply to this post by jbeach2646
John,

jOrgan never "copies" a disposition.  So if a .disposition file is ever "copied", it is
copied by the user.  Since the .memory file is a totally separate file, It would only be
copied if the user explicitly copied it as well.

CLW

-------------------------------------------------------------------------------

On 6/4/2018 3:18 AM, John Beach wrote:
> ... when a disposition is
> copied, is the
> .memory file copied with it?

------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
jOrgan-user mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/jorgan-user
Reply | Threaded
Open this post in threaded view
|

Re: jOrgan>File>Save FEATURE

lwalls
In reply to this post by greenfox
All good points, Rick.  And as you pointed out earlier, the jOrgan Windows installer
places all its "local" (user modifiable) files under the same folder that it uses to store
the program files.

More recent versions of Windows have strongly suggested that this is a "security" no-no.
Nothing but the static files of the app should ever be stored under the "Program Files" or
the"Program Files (x86)" folders.  In fact, Windows now requires that any program trying
to store stuff in these "Windows"-owned folders must be running with "Administrator"
privileges.  No user app should need to be run with administrator privileges.

All the dispositions and related files should be stored under the "local", private folder
structure belonging to the individual user, or the "all users" structure.

CLW
-----------------------------------------------

On 6/4/2018 3:56 AM, [hidden email] wrote:
> There is not just the .memory file. There is also the .skin file. There may also be MIDI
> files, and if the disposition uses Fluidsynth there could be one or more .SF2 files, or
> some other link to samples.
>
> I agree, there should be an easier way to allow for input settings and output settings to
> be stored and recalled other than a complete copy of a disposition renamed.
>
> The problem is that different people use jOrgan in different ways so what is a fix for one
> becomes a new problem for another.

------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
jOrgan-user mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/jorgan-user
12