Notifications
Clear all

Naming of libraries for easier searching especially for users with high number of libraries

7 Posts
4 Users
1 Likes
218 Views
omnisector
(@omnisector)
Active Member
Joined: 3 years ago
Posts: 3
Topic starter  

I have lots of libraries, over 48 start with the words PlugInGuru or PlugInGuru O2. Is it possible to rename them and remove the words PlugInGuru so for example PlugInGuru MegaMagic Keys just show as MegaMagic keys. It will make finding the library name easier when looking down my list and can sort alphabetically.


   
Quote
(@getdunne)
Illustrious Member Admin
Joined: 5 years ago
Posts: 4410
 

@omnisector

Thank you for bringing this from Facebook to the Forum. As I had previously answered on Facebook, this is a valid concern, and I appreciate what you're saying. I have added this to my ever-growing to-do list.


   
ReplyQuote
(@getdunne)
Illustrious Member Admin
Joined: 5 years ago
Posts: 4410
 

For the benefit of SQL database afficionados, this change can be done with a single SQL UPDATE query, using the excellent, free DB Browser for SQLite app. Unify's patch database is the file Presets.db, found in the Libraries folder under the main Unify data folder.

UPDATE Presets SET library='MegaMagic Keys' WHERE library='PlugInGuru MegaMagic Keys'

I suggest closing all instances of Unify before opening the database in DB Browser for SQLite, and closing that app (or at least using the Write Changes button) before re-opening Unify.

The resulting changes will survive most database rebuilds made by by clicking the "lightning bolt" icon in Unify, but there will be cases (forced FULL rebuild, or addition of new patches to the specific library involved) where it might be necessary to repeat the manual UPDATE operation.


Unify's patch database is quite simplistic, which results in many limitations. It uses only a single large table (called Presets), which gets built when necessary by reading metadata from the actual patch files. That is to say, the patch files themselves are thus the source of "truth" for the system; the database table is essentially a glorified index for quick patch lookup.

Before anyone decides to berate me for not using normal form and/or not improving on this simplistic schema, please understand that (a) using a SQL database from a C++/JUCE program is FAR more miserable than anything you're used to, and (b) for the past two years, most of my time has been eaten up just keeping Unify working in the face of OS updates, especially on the Mac platform.

That said, I am interested to hear from all users about how they would like to see Unify's patch database system evolve in future, AND from any with strong database experience, ideas about how to implement such changes.


   
ReplyQuote
(@dsteinschneider)
Eminent Member
Joined: 1 year ago
Posts: 19
 

Posted by: @getdunne

 

Before anyone decides to berate me for not using normal form and/or not improving on this simplistic schema, please understand that (a) using a SQL database from a C++/JUCE program is FAR more miserable than anything you're used to, and (b) for the past two years, most of my time has been eaten up just keeping Unify working in the face of OS updates, especially on the Mac platform.

That said, I am interested to hear from all users about how they would like to see Unify's patch database system evolve in future, AND from any with strong database experience, ideas about how to implement such changes.

I've been using SQL for small business work since the 90's. Mostly MSSQL but also MySQL, SQLite and SQL Anywhere. I've learned that a fully normalized design isn't always best - sometimes a single table is the best solution.

 


   
ReplyQuote
(@randallk)
New Member
Joined: 4 months ago
Posts: 2
 

Posted by: @getdunne

 

Unify's patch database is quite simplistic, which results in many limitations. It uses only a single large table (called Presets), which gets built when necessary by reading metadata from the actual patch files. That is to say, the patch files themselves are thus the source of "truth" for the system; the database table is essentially a glorified index for quick patch lookup.

Before anyone decides to berate me for not using normal form and/or not improving on this simplistic schema, please understand that (a) using a SQL database from a C++/JUCE program is FAR more miserable than anything you're used to, and (b) for the past two years, most of my time has been eaten up just keeping Unify working in the face of OS updates, especially on the Mac platform.

That said, I am interested to hear from all users about how they would like to see Unify's patch database system evolve in future, AND from any with strong database experience, ideas about how to implement such changes.

I don't have a great deal of SQL experience but I do have a couple of decades of DB design experience. Absolutely nothing wrong with keeping things simple. In the spirit of simplicity, how about adding a logical field to the Presets table to indicate that the name has been entered by the user? When TRUE, that would indicate that the name in the Presets table is the source of "truth" rather than the corresponding patch file. During a forced FULL rebuild, the code could simply skip the Preset records with that field/flag set to TRUE removed link

HTH

 


   
ReplyQuote
(@getdunne)
Illustrious Member Admin
Joined: 5 years ago
Posts: 4410
 

@randallk

Thank you for the suggestion. Adding fields is straightforward; the hard part is updating the GUI and supporting code. I will continue to look into this.

Also please note your comment was suppressed for moderation, because it contained a link. Our forum software (which I didn't write) doesn't allow newer users to post links, but I don't know exactly when it decides you're not "new" and switches over to permitting links. When in doubt, "write out" links e.g. "google <dot> com <slash> blah <slash> blah" and I can edit the post to fix the URLs.


   
ReplyQuote
(@randallk)
New Member
Joined: 4 months ago
Posts: 2
 

Posted by: @getdunne

Adding fields is straightforward; the hard part is updating the GUI and supporting code.

Oh, for sure! You're doing an amazing job as a one-man development team!

What I had in mind was not making any GUI changes, i.e. when someone uses an SQL UPDATE to change a Preset name, they would also set my proposed logical field to TRUE to indicate that they have changed the default name. Admittedly, it would require a code change for the library rebuild routine (to skip user-changed Preset names), but that's about as minimal impact as I can think of to ensure that user-set names (via SQL) are preserved during a full rebuild. 🙂 Just a half-baked thought.

 

Posted by: @getdunne

Also please note your comment was suppressed for moderation, because it contained a link.

Interesting. I don't recall adding a link. Maybe the way I typed TRUE <slash> ON or something like that was interpreted as a link. I'll be careful about how I use a <slash> going forward. 🙂


   
getdunne reacted
ReplyQuote
Share: