I agree the deduplication is counter intuitive with the bank management.
You can sort of disable deduplication if the fingerprint implementation uses all bytes of a patch, including program position and name. But importing the bank a second time would still show an empty list. Why am I so focused on deduplication? Because when sorting patches, you want to assign patch type and mark favorites. If you have the same patches under a different name or program position, you would be wasting a lot of time.
I think the correct way is to:
Fix the problem that renamed patches are not sent to the synth (which was the original issue here)
Always import full banks and files, to stop confusing users from getting less patches in an import than were there (I have been confused by this already as well)
Allow patches to appear multiple times in a list (this is actually possible) and under different names (which is not possible yet).
Automatically create banks for imports where applicable (not easy)
The original database structure patches becomes the repository for the data structure of the patch, i.e. the parameters. They might or might not contain program positions and names.
The "PatchInList" structure in addition to the new program position also gets a name allowing to record the name of the patch in this list - and this name is unique to the list, and is written into the patch data only before it is sent to the synth. This should allow for @salzaverde's completely valid use case to add the song number into the patch name.
Thanks @salzaverde for the pull requests, i will look at them at next opportunity! And then I need to make a plan on the changes required for this!
@Andy2No Thanks as always for your input, appreciated!
I agree the deduplication is counter intuitive with the bank management.
You can sort of disable deduplication if the fingerprint implementation uses all bytes of a patch, including program position and name. But importing the bank a second time would still show an empty list. Why am I so focused on deduplication? Because when sorting patches, you want to assign patch type and mark favorites. If you have the same patches under a different name or program position, you would be wasting a lot of time.
I think the correct way is to:
The original database structure patches becomes the repository for the data structure of the patch, i.e. the parameters. They might or might not contain program positions and names.
The "PatchInList" structure in addition to the new program position also gets a name allowing to record the name of the patch in this list - and this name is unique to the list, and is written into the patch data only before it is sent to the synth. This should allow for @salzaverde's completely valid use case to add the song number into the patch name.
Thanks @salzaverde for the pull requests, i will look at them at next opportunity! And then I need to make a plan on the changes required for this!
@Andy2No Thanks as always for your input, appreciated!
Originally posted by @christofmuc in https://github.com/christofmuc/KnobKraft-orm/issues/353#issuecomment-2452556015