Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Problem with Organs cache and File menu options #886

Closed
paolo2504 opened this issue Nov 23, 2021 · 8 comments · Fixed by #1141
Closed

Problem with Organs cache and File menu options #886

paolo2504 opened this issue Nov 23, 2021 · 8 comments · Fixed by #1141

Comments

@paolo2504
Copy link

paolo2504 commented Nov 23, 2021

I open this new post starting from a past similar post still open.
I have added more new thoughts and screenshots about this.

Issue description:
I am not actually able to manage Organs load when samplesets folder is not available (for example because located on external drive, possibly not connected).

Scenario
We know that GO is able to load and manage CACHED organs: this is perfect to reduce load timings. In addition, loading only caches means that original samplesets are not mandatory ( unless some changes due) so can be deleted, thus reducing disk space wasting.

To cache organs, user simply loads organ and close it (if auto management of cache is enabled) or manually manage cache with File/Update cache if no auto is set.
Considering that GO always loads Organs cache (if present), it is not necessary to keep original samplesets available on disks; this means that they can be loaded the first time from folders/external drives that can be later removed/disconnected.

Well, this is what i believed initially; unfortunately i found this seems not really possible for some reasons.
In fact, GO loads organs by doing File/Load, Favorites, File/Open or File/Open recent.
Unfortunalty i realized as follows.
GO does not load organs caches if they are NOT listed in File/Load dialog, and organs are NOT listed if drive is not connected ! Shortly speaking, GO is not able to load them because it doesn't see them.
Also, it is not possible to use Favorites (see details below) because I found that GO in this case always points to the very first folder of the organs installation, not just the last one.
In this case, it doesn't matter if the external drive is connected or not because GO is looking only at the folder from which organs were installed the very first time.
For me this is a BUG.
Lastly, even File/Open or File/Open recent cannot be used in case the drive is not connected. In a similar way as File/Load, if external drive is not connected GO is not able to see organs and then load their cache..

someone would ask: why not keep samplesets on a local disk ? And why disconnect an ext drive ?
Simple: samplesets are usually very big. It is normal to have dozens of gb for samplesets. Why waste so much space without reason (as GO uses cache) ? And why attach an external drive to the pc ? It is uncomfortable to have a pc with a usb drive on the organ shelf where probably I have less space to put it on.

Hope a solution can be found. Thanks.

Issue details and screenshots.

File-Load (images 1., 2.)
Organs are properly populated and loaded ONLY if drive/folder from which they were last time loaded is connected/available otherwise you cannot load them because they're simply not listed.

File-Favorites (images 3., 4.). Possible BUG.
The Organs list (image 3.) is populated ONLY by the ORIGINAL directory from which organs were first loaded and NOT by the LAST directory they were loaded from (error shown in image 4.).

How to reproduce:
a) load whatever organ from a folder (i.e. D:\samplesets)
b) delete cache, move organ from D:\samplesets to another folder (i.e. G:\samplesets)
c) delete D:\samplesets
d) load organ from the new samplesets folder G:\samplesets to recreate cache .
At this point, when drive/folder is connected/available the organ is listed/loaded doing File/Load as usual.
This is correct.
Now choose Favorites (you'll see your organ listed). Try to load it and you'll get error "unable to read D:\samplesets\yourorgan..."
It looks that Favorites always point to the original ODF Path of the very first organ installation.

I never realized this previously.
In the past I had 10 Organs.
Now I deleted all their caches and reloaded, from a different folder, just 4 of them. Well: the Favorites list still is showing 10 organs and if I try to load one of the 4 organs newly loaded I get error “unable to read from ” not the new one (that on the contrary is working fine if I do File/load)..

File-Open, File/Open recent (images 5., 6.)
These File menu options work fine, keeping in mind that the samplesets drive/folder must be connected/available.

Images 7., 8.
Settings used.

Issue screenshots.zip

@paolo2504
Copy link
Author

paolo2504 commented Nov 23, 2021

I have a question: what kind of informations are saved in the two files grandorgueconfig and grandorgueconfig.last ?
I suppose .last is a backup and the other is keeping all Settings: is that true ?
I was looking for OdFPath but the file is not ascii yet binary…

@oleg68
Copy link
Contributor

oleg68 commented Nov 23, 2021

This file is a gzip archive. You can unpack it.

@paolo2504
Copy link
Author

This file is a gzip archive. You can unpack it.

Uhm.. interesting. If this is the settings used by GO why zip it and not leave it as usual as .txt or .cfg ascii file ?..

@paolo2504
Copy link
Author

paolo2504 commented Nov 23, 2021

I had a look at the config file after unpacking it and I now it is more clear what is probably happening with this new issue.
In the past I had been programming for yrs with many languages, not c and c++ unfortunately, and many times I had to deal with config/settings files. I remember there were instructions to write/append/update specific sections and keywords inside .ini, .cfg., .txt files.
looking at my grandorgueconfig file I finally found the old and the new ODFPath entries, the old 10-15 ones with the old samplesets path and the 3-4 new ones.
All there starting top-down from the oldest to the newest.
Now I suppose that GO simply append all entries without really delete the old, no more used, ones. However, some functions like Favorites seem (just an hipo) still to use them while other not. Unfortunately, I even suppose that the code is somehow not able to clearly identify what is new and what is old so that File/load and Favorites work differently.

It seems there is some confusion in the code…
For me the problem will be solved deleting the config file and redoing all like a fresh installation.
this is bad and it is exactly what I wanted to avoid. Anyway, it is obvious to me that this part of GO code should be fully reviewed.

@larspalo
Copy link
Contributor

This file is a gzip archive. You can unpack it.

Uhm.. interesting. If this is the settings used by GO why zip it and not leave it as usual as .txt or .cfg ascii file ?..

Because users are not supposed to mess with those files... Not joking.

Please also note that you do have the option to select what should be included on your favorites and even at all available organs (registered).

And to the point of this issue. It wasn't really expected of the user to do what you're doing to begin with anyway. Disk space is extremely cheap nowadays. Most of us having more than 30+ organs just leave them as is on disk and never worry about it.

@paolo2504
Copy link
Author

paolo2504 commented Nov 23, 2021

Appreciate your kind reply but unfortunately I do worry about it and I do need to optimize disk space mgmt. Trying to do this, I’m finding some bugs in Go code and this cannot be under extimated.
You’re right, I’m a user even if a user skilled in IT and, as a user, I prefer to exactly know what pgm do on my devices. Finally, there is no reason to try to hide a settings file: no security issue on that. Since at least 30 years settings files like .cfg or .ini are written as open text because this way can be easily read and parsed in memory. It’s nonsense to zip because then to be read must be unzipped and this takes a little bit more time, a little longer code and add chances of code faults.

@larspalo
Copy link
Contributor

The compression is kind of like the shell of most other products. If you break the seal - you break the warranty. Oh no, I forgot. It's open source GNU GPL, it does not come with any warranty.

Now to summarize:

GO does leave lots of litter (garbage) that easily can be orphaned and impossible to (currently) remove from within the program. This is an issue that I absolutely think should be addressed.

PS. Don't remove the sampleset from it's original location and just run from the cache. The cache may very easily be invalidated by any small change you make to your settings/setup. The cache is only supposed to be used for speeding up the reading of a sampleset at the expense of higher disk usage, not to replace the original sampleset. If you're really concerned about disk space then don't create caches at all and only use the newer organ package samplesets that are much more storage efficient than the old styles.

@paolo2504
Copy link
Author

paolo2504 commented Nov 24, 2021

thanks.

I could agree on what you say but at this point i would suggest to either toggle the option to set the Samplesets directory under Settings because not properly working and advise users that there are issues with Favorites and File/Load if they change that directory , until they will be hopefully fixed in some future.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging a pull request may close this issue.

3 participants