Updating patch causes double patch

(@craigr68)

You need to check that the library has not been duplicated. Carefully browse the installed libraries. I had the same.

Good luck.

Les.

@craigr68

This usually happens when you've saved patched somewhere outside the Patches folder for the library they're part of. As you say, a full database rebuild fixes the problem.

Something similar can also happen when you save a modified version of a library patch: you end up with both .upf and .unify files with the same patch name. In this case you will normally be able to load both files. I now recommend a three-step process to avoid the problem:

1. Load the original library patch (.upf version)
2. Right-click the patch name and choose "DELETE this patch" (.upf file gets deleted, patch itself remains in memory)
3. Click Save... and re-save the patch with whatever changes you wish (only your new .unify file will exist and appear in patch list/DB)

I'll be the first to admit this is clumsy, but it is an effective way to avoid duplicate patches.

@getdunne 

It happened again.  Actually it seems to happen quite a bit, so it's not hard to recreate.  But I found only the .unify version.  There is no .upf version (screenshot- patch name is "CC PAD - From Clouds to Space.unify").  This time if I click on the bogus patch, it doesn't highlight, but brings up a completely different patch Hybrid Simple Giant (screenshot2).  It would make you think that I had "Hybrid Simple Giant" open and then somehow saved it as "CC PAD - From Clouds to Space", which I don't think I did.

Is there a way to upload more than one file at a time?  I always have to edit the post to get the 2nd file uploaded.

@craigr68

The only way I can give you a proper answer is if you zip and post your Presets.db file, which you'll find in the main Unify Libraries folder, and also specify which patches (or at least one) that you're seeing duplicates of.

PS Attaching multiple files individually is possible, but miserable; you have to use the "source" editor. It's far easier to simply attach one zip archive.

@getdunne 

So this time it happened with patch named Moogeous1 Minimoog. 

Zip file contains: presets.db (after it happened), Unify screenshot showing the duplicate patch name, screenshot showing "Mine" library folder which contains no duplicate base file names.  Second zip file contains presets.db after I fixed it with full rebuild for comparison.

Because I've had this problem off and on for some time, I usually go thru the "Save->Save As->Save->Do you want to replace it->Yes" sequence.  I don't think I've had a problem doing it that way, but it's a few steps.

Thank you.

@craigr68

It seems you saved a patch called "Moogeous1 Minimoog" to a file called "CC Pad - From Clouds to Space" in the same library "Mine".

Here is what I did to figure this out. I used DB Browser for SQLite, because Unify's patch database file (Presets.db) is simply a SQLitedatabase. I opened the Presets.db file and entered the SQL command

SELECT * FROM Presets WHERE name LIKE 'Moogeous%'

in the Execute SQL tab, then hit the Execute button (right-pointing triangle icon). This tells the database to list all records where the name field starts with "Moogeous". As you can see from the attached screenshot, there are two files with completely different names, in the same library folder.

My best guess as to what happened is that, one of the times when you went to save your patch, you accidentally clicked on an existing file name and confirmed that you wanted to save the patch under that name. The patch name and file name hence do not match, and you ended up with two different files having the same patch-name.

Unfortunately, Unify does not handle duplicated patch-names well, and because when you left-click on an entry in the patch list, Unify actually looks up the patch by name in the database, and opens the first file that matched. Hence, you can't selectively load one of a group of same-named patches that way. However, you can do so by right-clicking. You can choose to simply load each patch, or if you want to understand why the duplicate name is appearing, you can choose "Reveal in Explorer". Once you know which is which, you can right-click and choose "DELETE this patch" to remove the duplicate(s).

@getdunne 

This is what the screen looks like before I hit update.  It seems odd that I could have left clicked on another patch in the patch list, especially numerous times this has happened?  I see why I don't have a problem with the "save as" routine, because there I'm telling it specifically what file to overwrite.  Update doesn't really indicate what file is going to be overwritten.  I wonder if that could be put in the dialog before saving.  Anyway, I know more of what to watch out for.  Thanks again.

@craigr68

Sorry, I did not write clearly. The business about accidentally clicking arises when you hit "Save As" from the Unify Save dialog, which presents a standard Windows (or Mac) file-save dialog. If you change the file name there, either by manually editing it, or possibly by accidentally clicking on one of the displayed files, you can easily end up with a file-name/patch-name mismatch.

If you click "Update" instead of "Save As...", Unify will automatically update whatever file you actually loaded, even if its name does not match the patch name.

I don't know what leads to the mix up with Patch Name and File Name.  I see what you mean about this happening with "Save As", but I don't think I had done that - but maybe.  I installed DB Browser and will be watching out for it to happen next time until I find the "a ha" moment.  Why not put in the save dialog box what it thinks the physical file name is so we could compare and know before we hit update?  Because update itself doesn't let you know otherwise.  I guess I can use Reveal in Explorer as alternative.

Posted by: @craigr68

I guess I can use Reveal in Explorer as alternative.

That's what it's there for.

I created a script that reads the database and shows where the fileName and name differ.  Special characters in the patch name are often the culprit since they can't be used in physical file names.  I noticed the special characters get translated to underscore when saving.  I'm not concerned with those since there's not much that can be done about it other than to avoid naming patches with special characters.  But then there are some patches where the 2 differ when they got fat fingered, misspelled or something else.  There are a bunch like that in the screenshot.  Of course if you go "update" instead of "save as", there won't be a problem.  Just to avoid problems with my own patches, I make sure the two match.  Since then, I haven't had problems with double entries since I figured out how the whole thing works.  Thanks.

By the way, love the new global volume control in 1.8

@craigr68 ,

That is a very useful script you have created. Would you be kind enough to share it here?

@eallan 

Sure, glad to.  Unzip the attachment somewhere.  Edit the UnifyFolder line shown below and it should run.  Included in the zip is a Lib folder that reads the database.  Also a license file that complies with the Lib creator's wishes.  The script is a little messy because it was a rushed tangent I got off on.

UnifyFolder=C:\CAKEWALK\Unify ;wherever your Unify folder is

@craigr68 ,

Many thanks for posting your script - will endeavour to try it out tomorrow.

@eallan 

Actually, try this new revision.  I added the database row number to the display (screenshot).  Also, now if you double click on any row, it should load that patch in Standalone Unify.  But you have to enable OSC in Unify settings (screenshot).

@craigr68 ,

Hi , tried you latest script today and works very well and double clicking on a line

loads the patch into unify.

I have noticed that clicking on Row does not then list the patches sequentially by row number

but jumps about. Is it meant to list numbers in decending/ascending order?

Would it be possible to add toggle button to show either all patches or only mismatched

names patches?

That way your script would act as a Patch Browser/Launcher too.

The ability to just show one Library from a list of all available would save some scrolling

and also help to locate a particular patch quicker.

@eallan 

Ya, it sorts kind of weird when you click on Row.  I can't see where it's worth it to fix that at this point.  It was a last minute deal to add it. 

To answer your second part question - I've been working on my new Alternative Unify Browser using OSC.  I'm calling it UnifyOSC.ahk.  I've tested it quite a bit and done as much as possible to make it painless to install (I hope).  The layout (Screenshot1) is similar to my former midi version but works using OSC and Unify Standalone, which means no more Midi Bank files.  Also, I have an extra feature.  When you hold down your sustain pedal, a smaller screen of your favorites appears.  At that time, if you press the associated computer keyboard key (such as the letter a), then the associated patch should open in Unify Standalone.  There's a file "Readme.txt" in the zip that shows directions.  Script assumes screen resolution is 1920 x 1080 but could be adjusted.  It's kind of cool with dual monitors to separate script and Unify to see it in action.

Screenshot2 shows Fav screen overlaying script in background.  Screenshot3 shows Fav screen with script hidden to tray.

(@getdunne)

Even though this post got off onto some tangents, this is still consistently a problem for me.  I think I've identified the problem occurs when a Midi program change is sent to Unify followed by an Update.  Could you please check this out.  I've attached some screenshots.

Shot1 - starting out, DBBrowser shows 2 patches called Patch1 & Patch2
Shot 2 - shows what Patch1 looks like in Unify - the browser shows the two separate patches - everything normal at this point
Shot 3 - then I send Unify a Midi program change to change to patch2 ("https://pluginguru.net/unify/manual/doku.php?id=midi-patch-select")
And it switches to patch2
Shot 4 - then I go Update
Shot 5 - then I have two patches named Patch2
Shot 6 - DBbrowser shows the mix up

As you pointed out before - It's easy to fix by just deleting the bogus patch, and while it remains loaded in Unify, resaving it to the correct filename.

@craigr68

VERY interesting, thank you for the detailed report. Unify must be missing a step somewhere, when responding to MIDI program changes. I've had a quick look in the code already, and didn't see anything obvious, but you've given me enough detail here to reproduce the issue.

Many thanks!

UPDATE: I found the problem. It's a bit intricate, but I'll get it fixed.

UPDATE 2: Fixed.

@getdunne 

In an earlier release, you fixed the problem with updates after a Midi program change.  Now, I think we have this same problem with the new OSC commands.  (Screenshots.zip below)

2.jpg - shows DB is normal with no doubles

3.jpg - shows the embedded instance before I send it the OSC command to change patch

4.jpg - shows the embedded instance after I send it the OSC command to change patch to PIANO STRGS VOICES

5.jpg - I do "update", now there's two PIANO STRGS VOICES in the browser

6.jpg - DB shows the obvious problem.

A full DB rebuild fixes the problem temporarily until I do the same sequence again.  And like before , "Save as" works ok.

@craigr68

Thanks for spotting this, and for the detailed report. I found the bug, and it will be fixed in the next beta.