After reopening the application and a similar catalog, the automatically added extension got more complicated. See the attached screen shot of the chord originally named 6,9(no5). Not only did Synfire add the .v1 extension to this chord, under Rotations/Modes it includes this chord with further name variants: C6,9(no5.v1) and C6,9(no5.v2) -- probably all supposed to mean the same C6,9(no5) chord.
Red = Name or alternative names have conflicts with already existing items. In this case the alternative names included blank (invisible names). Fixed the bug now.
For naming arbitrary structures, try the Suggestion button.
Your file had read-only items in it. This is no longer used when a new catalog is created. I fixed them (attached).
> Your file had read-only items in it. This is no longer used when a new catalog is created.
Is there a way to fix this myself for other catalogs I have?
I can confirm that the updated file you sent fixed both issues: the .v1 name of the major chord could be changed, and the red chord entries are gone. With my existing other catalogs the problems still persist.
> You can create a new minimal catalog and then merge your custom catalogs
I now tried that, and the actual merging seemed to work (e.g., I unticked that the imported catalog should be able to overwrite entries of the initial minimal catalog, and afterwards the original major chord definition seemed to be untouched), but then saving the resulting extended catalog resulted in an error. The resulting catalog file got some extention .temp automatically added, which makes is unusable (likely intentional). Crash report sent.
BTW: Under File > New, there is no entry for creating a new catalog. A new catalog can be created, however, once some other catalog was opened -- but you first need to have one of those, it seems...
The crash report indicates a file sharing violation (dropbox issue?).
There also may be a leftover file 'User.prefs.temp' in your Config folder (delete it). In general, if there are '.temp' files when Synfire was quit, delete them.
> The crash report indicates a file sharing violation (dropbox issue?).
Ah, that is very helpful. Indeed, I have my Documents and Compositions folder assigned to be automatically backuped by Dropbox. So, that is not possible then?
Some more details: This problem seemingly only occurs when trying to save a catalog file. All other Synfire file types (e.g., arrrangements) can be saved without such error (and also other applications have no problem with this backup setup). Also, when trying to overwrite an existing catalog file, Synfire *deletes* the existing file and then successfully instead saves a file with the same name and an additional .temp extension. When trying to save a new file, the additional .temp extension is added, but the file is saved again anyway.
So, at some stage perhaps there is a way around this, as seemingly saving works anyway?
In the meantime, I will have to think about how to automatically backup compositions with Dropbox and still avoid this issue.
> In general, if there are '.temp' files when Synfire was quit, delete them.
Hm. I don't think that is a good idea if Synfire did not just add but also *rename* some file (that I have been working on for quite some time) by attaching the extension .temp.
> There also may be a leftover file 'User.prefs.temp' in your Config folder (delete it)
For completeness, there has not been any User.prefs.temp file.
If some dropbox task holds onto a file and Synfire tries to rename it, yes that may cause a sharing violation. But I have no experience with dropbox, so I can't really tell.
If a file already exists, Synfire saves the new version with '.temp' appended. When done the old file is deleted and the new one is renamed to have the '.temp' removed.
I now simply resolved the .temp catalogs by removing the .temp extension. Seems to work, fingers crossed...
That way I tried to fixed a preexisting catalog, where I started with a basic catalog and merged in my previously existing catalogs with weird issues like the major chord being renamed .v1 and some chord entries marked in red. There are now no red chrods anymore, and major is finally an empty string again, but I still get (temp?) chords named with extensions like Gb6,9(no5.v1) and Gb6,9(no5.v2) -- even both these identical chords in the palette (!) where the matching chord in the catalog is named without such versioning. So, seemingly there still are some fishy renamings going on.
These automatically added names do not show up in the catalog, even if View > Temporary Items is selected.
More generally on palettes, it seems that once some automatically added name is somehow in the system, then simply loading a catalog that names this entry properly does not resolve the wrongly named entry. It seems only catalogs loaded at the very beginning can avoid certain naming problems.
Wed, 2022-10-26 - 13:22 Permalink
Removing some seemingly automatically added alternative name with a .v1 extension resulted in a crash; submitted the crash report.
Wed, 2022-10-26 - 13:29 Permalink
After reopening the application and a similar catalog, the automatically added extension got more complicated. See the attached screen shot of the chord originally named 6,9(no5). Not only did Synfire add the .v1 extension to this chord, under Rotations/Modes it includes this chord with further name variants: C6,9(no5.v1) and C6,9(no5.v2) -- probably all supposed to mean the same C6,9(no5) chord.
Wed, 2022-10-26 - 13:34 Permalink
Context: I want to use palettes based on scales without a fifths, so I need chords like this one.
Wed, 2022-10-26 - 14:13 Permalink
Thanks for the file.
Red = Name or alternative names have conflicts with already existing items. In this case the alternative names included blank (invisible names). Fixed the bug now.
For naming arbitrary structures, try the Suggestion button.
Your file had read-only items in it. This is no longer used when a new catalog is created. I fixed them (attached).
Wed, 2022-10-26 - 17:41 Permalink
Thanks for the quick reaction!
> Your file had read-only items in it. This is no longer used when a new catalog is created.
Is there a way to fix this myself for other catalogs I have?
I can confirm that the updated file you sent fixed both issues: the .v1 name of the major chord could be changed, and the red chord entries are gone. With my existing other catalogs the problems still persist.
Wed, 2022-10-26 - 17:32 Permalink
No. You can create a new minimal catalog and then merge your custom catalogs. Haven't tested but that should work.
A new build is just uploading, btw. also with the alternative names fixed.
Wed, 2022-10-26 - 17:41 Permalink
> You can create a new minimal catalog and then merge your custom catalogs
Will try that, thanks!
Wed, 2022-11-02 - 14:10 Permalink
> You can create a new minimal catalog and then merge your custom catalogs
I now tried that, and the actual merging seemed to work (e.g., I unticked that the imported catalog should be able to overwrite entries of the initial minimal catalog, and afterwards the original major chord definition seemed to be untouched), but then saving the resulting extended catalog resulted in an error. The resulting catalog file got some extention .temp automatically added, which makes is unusable (likely intentional). Crash report sent.
BTW: Under File > New, there is no entry for creating a new catalog. A new catalog can be created, however, once some other catalog was opened -- but you first need to have one of those, it seems...
Wed, 2022-11-02 - 18:56 Permalink
The crash report indicates a file sharing violation (dropbox issue?).
There also may be a leftover file 'User.prefs.temp' in your Config folder (delete it). In general, if there are '.temp' files when Synfire was quit, delete them.
Wed, 2022-11-02 - 18:57 Permalink
Only a single global catalog can exist at any time.
Wed, 2022-11-02 - 19:58 Permalink
> The crash report indicates a file sharing violation (dropbox issue?).
Ah, that is very helpful. Indeed, I have my Documents and Compositions folder assigned to be automatically backuped by Dropbox. So, that is not possible then?
Some more details: This problem seemingly only occurs when trying to save a catalog file. All other Synfire file types (e.g., arrrangements) can be saved without such error (and also other applications have no problem with this backup setup). Also, when trying to overwrite an existing catalog file, Synfire *deletes* the existing file and then successfully instead saves a file with the same name and an additional .temp extension. When trying to save a new file, the additional .temp extension is added, but the file is saved again anyway.
So, at some stage perhaps there is a way around this, as seemingly saving works anyway?
In the meantime, I will have to think about how to automatically backup compositions with Dropbox and still avoid this issue.
> In general, if there are '.temp' files when Synfire was quit, delete them.
Hm. I don't think that is a good idea if Synfire did not just add but also *rename* some file (that I have been working on for quite some time) by attaching the extension .temp.
> There also may be a leftover file 'User.prefs.temp' in your Config folder (delete it)
For completeness, there has not been any User.prefs.temp file.
Wed, 2022-11-02 - 21:12 Permalink
If some dropbox task holds onto a file and Synfire tries to rename it, yes that may cause a sharing violation. But I have no experience with dropbox, so I can't really tell.
If a file already exists, Synfire saves the new version with '.temp' appended. When done the old file is deleted and the new one is renamed to have the '.temp' removed.
Thu, 2022-11-03 - 11:24 Permalink
I now simply resolved the .temp catalogs by removing the .temp extension. Seems to work, fingers crossed...
That way I tried to fixed a preexisting catalog, where I started with a basic catalog and merged in my previously existing catalogs with weird issues like the major chord being renamed .v1 and some chord entries marked in red. There are now no red chrods anymore, and major is finally an empty string again, but I still get (temp?) chords named with extensions like Gb6,9(no5.v1) and Gb6,9(no5.v2) -- even both these identical chords in the palette (!) where the matching chord in the catalog is named without such versioning. So, seemingly there still are some fishy renamings going on.
These automatically added names do not show up in the catalog, even if View > Temporary Items is selected.
More generally on palettes, it seems that once some automatically added name is somehow in the system, then simply loading a catalog that names this entry properly does not resolve the wrongly named entry. It seems only catalogs loaded at the very beginning can avoid certain naming problems.
Anyway, thanks a lot for your support.