Is it OK to create a Pull Request on the unify-batch repository?

@ssquared I'd be delighted to get a PR from you, thank you.

This is a tricky case, because you want to change the top-level library-name, but keep certain internal file references (in this case, Guru Sampler) unchanged. Bear in mind that there are several other kinds of file references, e.g. references to MIDI files in MIDIBox, so ideally you'd need to add several checkboxes, or at least ensure that your one checkbox disables them all.

I have a version of the LibraryRenamer source-code which I use for this kind of tricky situation, full of #define's and #ifdef's so I can add custom code for each case.

@getdunne

Oh cool.  Thank you.  Thanks for pointing out the other kinds of references.  It does make better sense to create individual checkboxes.  I can see someone making their own patch pointing to a PlugInGuru sample but then using their own MIDI file (which they will likely want renamed to the new library reference).  And if you don't like the changes, you can always deny the PR.

Those changes should be fairly easy, it's just a matter of when I'll get back to it.  Hopefully later this week.  I'll try testing what I can.

I am currently working on a library with many bread-and-butter analog synth-style sounds to give out.  GuruSampler is a fairly nice subtractive synth and wanted to show how powerful it is.  I'm having a tough time deciding on a library name and needed to rename it.  My problem is every time I'm ready to wrap things up, I get carried away and create more patches.  I finally decided to get to finishing the library.

Posted by: @ssquared

↑

I am currently working on a library with many bread-and-butter analog synth-style sounds to give out.

If you're planning on sharing your library with others, you should definitely create a folder called Samples in the library folder, with at least one sub-folder, copy all the samples you intend to distribute into that sub-folder, and ensure the patches reference the sample files in that location. Guru Sampler's file references will then be relative to the library folder, so they can be used on any system, regardless what path the user chose for Unify's top-level data folder.

See https://pluginguru.net/unify/manual/doku.php?id=guru-sampler#using_your_own_samples and follow the links from there, especially https://pluginguru.net/unify/manual/doku.php?id=sampler-import#unify_guru_sampler_folder_structure where I explain why your Samples folder needs at least one sub-folder.

Note if you use samples, MIDI files, etc. from the Unify Standard Library in your patches, LibraryRenamer will not change their paths, because they will already be valid for every Unify installation.

You can set up a custom folder hierarchy under your library's Samples folder, i.e., if your samples fall into groups like "Digital", "Analog", or whatever, it's a good idea to create an appropriately-named sub-folder for each under your library's Samples folder. In most Unify libraries, John usually makes just one sub-folder, with the same name as the library, but have a look at the Samples folder for the Unify Standard Library to see another approach.

Just bear in mind that if you change the hierarchy after creating patches, LibraryRenamer won't know that, and will only change the top-level name in each file path. It's then just a matter of opening each of your patches, checking each Guru Sampler or MIDIBox instance, re-loading any missing files manually one at a time, then re-saving the patch.

Getting all the file references right is a very important step in getting any Unify library ready for distribution. Mistakes are very common, and the main reason I maintain a custom/hackable version of LibraryRenamer is to automate the process of fixing them on a case-by-case basis.

@getdunne

I am not using any of my own samples.  The samples are all from the PlugInGuru "Electric Dreams" library (and some from the Unify Standard Library).  This sound library will only work if you have the Electric Dreams library.  Will distributing this library still be a potential issue if someone installs Unify libraries in a different directory?

I originally thought I'd make 10 presets and post for Thanksgiving as a Thank You.  When that didn't happen, I thought 25 would be good for the end of year and New Year.  Now, months later, the library has gotten much larger than I ever expected, but patches are starting to sound the same, so I figure it's probably time to stop and finally get this out.

Posted by: @getdunne

↑

LibraryRenamer will not change their paths, because they will already be valid for every Unify installation.

Yeah.  I noticed that in the code.  I needed the same behavior (don't overwrite the library name) when I'm using samples from any PlugInGuru library.  This was the whole problem I ran into.  LibraryRenamer does not rename when using the Unify Standard Library but does rename when I point to any other PlugInGuru library.  My fix is definitely working for my use case, but maybe it will break if a user installs their PlugInGuru libraries to a different directory.  I was about to manually edit all 80+ patches and resave under the new library name until I decided to look at the LibraryRenamer code to see if I could come up with a quicker solution.  Having never used JUCE before, it did take a bit to figure out the GUI placement using the bounds, but the rest was nice and straightforward.

@ssquared

To answer all your "what if Unify libraries are installed in a different directory" questions, in general it should be fine, because all these file references are relative to the library root folder, whose location (wherever the user chose to place it) is known to Unify.

However, given that you've explained this is basically an add-on to Electric Dreams, I think your planned solution will be fine.

I'll get in touch directly with a couple of other suggestions.

Thanks.  Really appreciate all your help and insight into this.

EDIT:  Spelling error.

@getdunne

Want to follow up on this now that we've gone through the whole process.

Thanks for the approval.  Appreciate the time.  I was going back and forth between short and simple text or that long thing I ended up using.  Thanks for cleaning it up.

Believe it or not, the most time-consuming pieces were figuring out the text on the checkboxes and the four lines handling the Bounds.  I hope JUCE has some type of visual GUI editor.  If you had to manually program all the control placements in Unify, that could not have been easy.

@ssquared

I appreciate the contributions!

As you probably know from experience, writing GUI code and ensuring that it works well enough to sustain the end-user illusion that "the GUI is the program" is usually 80 to 90 percent of the total effort. Unfortunately JUCE is a rather low-level C++ framework, and doesn't help a lot.

The Projucer app which comes with JUCE does include a simplistic GUI editor, but it's essentially deprecated now, and the code it generates is very ugly, full of absolute numeric coordinates. As you can see in this code, I prefer to use the methods of juce::Rectangle, which provide ways to use only a few absolute numbers (mainly for dimensions) and express how components are laid out vertically or horizontally.

@getdunne

Interesting.  I had to use Projucer to get the necessary files for the JuceLibrayCode directory.  This contained some header, cpp and mm files I needed to compile the main program source.  If Projucer is getting deprecated, is there another process I should have used to get the necessary JUCE files?  I may have only needed some main header file (don't recall the name).

Posted by: @ssquared

↑

Projucer is getting deprecated...

Projucer itself is not deprecated, although the developers are now encouraging people to use CMake instead. See the Examples/CMake folder in the main JUCE folder. (And no, the process is not nearly as obvious as they try to make it seem. Nothing is obvious in JUCE. Its learning curve is one of the steepest I've ever encountered.)

What is deprecated is the GUI Editor capabilities in Projucer.

Interesting link.  Thanks.  Led to many other good links/reads.

Hahaha.  Saw one post as far back as 2018 stating the GUI editor was deprecated (even back then).