U-he preset randomizer tool (open-source CLI)

[Fannon]

In some threads here, the topic of randomly generating or merging u-he presets came up.

This got me curious and I started creating my own CLI tool that can generate randomized presets. It will browse your entire preset library for a given u-he synth and then use real values from real patches as a basis for generation. That should also make it rather generic, e.g. work for many u-he synths in the same way.

Here is the project: https://github.com/Fannon/u-he-preset-r ... randomizer

If you have Node.js (https://nodejs.org), you can run it directly in your Terminal / Command Prompt:

Code: Select all

npx u-he-preset-randomizer@latest

The project is now in a usable state, supporting random generation or merging of existing presets.
For an up-to-date description, have a look at the link above.

[RugerioDelStereo]

Sounds interesting Fannon, great initiative!

[CrystalWizard]

Have you seen this?:
http://www.darwinarts.com/

[gonzomaster]

In some threads here, the topic of randomly generating or merging u-he presets came up.

This got me curious and I started creating my own CLI tool that can generate randomized presets. It will browse your entire preset library for a given u-he synth and then use real values from real patches as a basis for generation. That should also make it rather generic, e.g. work for many u-he synths in the same way.

Here is the project: https://github.com/Fannon/u-he-preset-r ... randomizer

I just started working at it yesterday evening, and it is currently at a very minimal state. It can only generate fully randomized presets. But I have more ideas how to extend it, including choosing presets to randomize or merge with each other and choosing the amount / type of randomization. Also, I haven't tested it well and only tried Diva so far.

Diva is a good starting point for this project. I used the u-he randomizer some time ago; there were some problems (patches could not be played anymore and got silent, unusual pitch variations and nonsense variations, ...). I think, some kind of control (stability of some settings) woud be fine.

[Fannon]

Yes, I also thought that Diva would be simple to get started with due to how the synth is laid out and it having no complicated concepts like custom wavetables / osc curves.

FYI, this is how it looks like when you execute the tool in Windows Command Prompt:

2024-05-04 13_21_24-(1) KVR Audio - User Control Panel - Compose message and 4 more pages - Personal.png

[Fannon]

Have you seen this?:
http://www.darwinarts.com/

No, I haven't seen it. Looks like its "gone" and not available anymore.

I'm not so sure about the use of "genetic algorithm". This would imply to me that there's some fitness function involved which can automatically decide if one generated patch is better than another. But only the end-user can decide that manually. So I think an external tool probably has to stick to merging existing presets with each other (and introducing some randomness), which may feel like creating "offspring" presets.

Btw. I've now implemented a feature to take a specific base preset, and introduce random elements from other patches in your library:

Code: Select all

npx u-he-preset-randomizer --synth Diva --preset "HS Greek Horn" --randomness 20 --amount 5

(This command will create 5 random variations of the "HS Greek Horn" preset, with 20% randomization ratio)

[AtomOfScent]

This is awesome! I had a very similar idea a few months ago and started on it using Python but then went on a long trip so put it on the back-burner.

The basic concept was to divide the preset file format into distinct sections, randomly choose preset files in a selected folder, take one section from each, and merge into a new one. I wasn't sure how to handle the binary part so I'll definitely have a look at how this works...

An idea could be to use Favourites.db.txt for creating hybrids of presets the user already likes, or if merging random ones always choose 1-2 from the fav database to increase the likelihood of desirable results.

Once the basic functionality is complete I might see how hard it is to port to Python and add a GUI.

[Fannon]

Update: I've now added the functionality to merge multiple presets with each other, based on random ratios between them.

This is awesome! I had a very similar idea a few months ago and started on it using Python but then went on a long trip so put it on the back-burner.

The basic concept was to divide the preset file format into distinct sections, randomly choose preset files in a selected folder, take one section from each, and merge into a new one. I wasn't sure how to handle the binary part so I'll definitely have a look at how this works...

Cool! Yes, I also thought about the "section" approach. Even nicer would be if the randomizer would know which section is really active in the preset and only use values from such active sections. Otherwise there's a high chance that the disabled sections just have init values or random / non musical stuff in it.

An idea could be to use Favourites.db.txt for creating hybrids of presets the user already likes, or if merging random ones always choose 1-2 from the fav database to increase the likelihood of desirable results.

That's a nice idea! I couldn't find this Favorites.db.txt. Is this some export you made yourself? I do export my favorites from time to time by dragging (shift dragging?) them into dedicated .uhe-fav files. It would be nice if you could point to such a file as an argument - and only take those as randomization sources - or create merge patches between all your favorites.

Once the basic functionality is complete I might see how hard it is to port to Python and add a GUI.

The code base is only quickly thrown together, but its somewhat organized into separate modules and functions. Btw. with such a TypeScript project it would be possible to create a https://www.electronjs.org/ app out of it. Would be a nice learning project, but creating UIs is quite time consuming.

[Fannon]

Ok, I got around and added an interactive CLI. If you just start it without arguments:

Code: Select all

npx u-he-preset-randomizer

It will guide you through all the necessary choices, including auto-complete selection of your presets.

[AtomOfScent]

Cool! Yes, I also thought about the "section" approach. Even nicer would be if the randomizer would know which section is really active in the preset and only use values from such active sections. Otherwise there's a high chance that the disabled sections just have init values or random / non musical stuff in it.

That's true. I suppose you could compare a section against the init values and use a different section/file for disabled parts but it's easy to just run the script again. Randomizers are like cheap slot machines, low investment and fun, with the potential to also be rewarding.

That's a nice idea! I couldn't find this Favorites.db.txt. Is this some export you made yourself? I do export my favorites from time to time by dragging (shift dragging?) them into dedicated .uhe-fav files. It would be nice if you could point to such a file as an argument - and only take those as randomization sources - or create merge patches between all your favorites.

Actually I just remembered that the file was from an earlier version before the new preset browser. I likely backed it up by adding .txt to the end of a copy as sometimes it would get overwritten.

I think everything is in the main presets database now which is too bad as the Favourites.db files were relatively small and easy to parse.

The code base is only quickly thrown together, but its somewhat organized into separate modules and functions. Btw. with such a TypeScript project it would be possible to create a https://www.electronjs.org/ app out of it. Would be a nice learning project, but creating UIs is quite time consuming.

It's all a learning project for me and since I already know how to [get coding assistants to] create basic Python GUIs it might be better to try something new and see how far I can get with Grimoire.

Ok, I got around and added an interactive CLI. If you just start it without arguments:

Code: Select all

npx u-he-preset-randomizer

It will guide you through all the necessary choices, including auto-complete selection of your presets.

Interactive CLI is much more user friendly.
Now I just need to see if I can get node.js running. I think I messed it up in the past.

[Fannon]

Randomizers are like cheap slot machines, low investment and fun, with the potential to also be rewarding.

Thats true Maybe its not worth the trouble if there is no good, generic way to figure this out.
I've just tried fully random presets with Bazille and that will result in totally wild things, as even the cable pathing is randomized. Many presets there won't be viable at all, but that's the price to pay for so much variance in results.

Btw. I also don't know what do do with the binary part of the u-he preset files. I just drop it and do not even try to re-create it. Not entirely sure what's in there. I'm a little afraid that in some u-he synths it's used to store more complicated parts of a patch like custom osc curves - especially now with Zebra 3.

[AtomOfScent]

I got it running! I haven't tested any of the results yet, but you've done an awesome job with this.

Regarding the CLI, since Zebra, ZebraHZ and Zebralette3 have similar names I wonder if it might be easier to make the synth choice a numbered list (vs. typing Zebra* to choose)?
Support for ACE would be great too. Podolski and TripleCheese are the other free U-He synths, but may not be worth including.

A few other thoughts/ideas:
1) When merging I don't always know what to pick, or might only have the initial preset in mind. If I'm choosing randomly, I may as well have the script do it for me.
Perhaps entering * or ? as a selection could make the script pick one. Even better if that could be used in conjunction with the auto-complete.

For example: piano * ENTER
piano narrows the list to everything with that in the name, and * picks a random one from the filtered list.

2) Running the script within a specific preset subfolder would limit the merging file selection to that location and auto detect the synth.

i.e.
C:\Users\Username\Documents\u-he\Diva.data\Presets\Diva\Luftrum 9
The script would know it's making Diva presets and only use presets in that location.

3) Merging presets of the same type is likely to give the most usable results. Being able to filter the selection criteria by providing a prefix would be a simple way to do this.

i.e.
PAD or PD to merge pad sounds into new ones.
When a prefix is provided it would also make sense to add it to the output file names.

A more complex option is merging using the preset categories like Pads:Evolving or Pads:Analogue, which would allow more specificity and include presets that don't have a category prefix in the filename. The most efficient way would probably be an option to build a very simplified .txt or .csv 'database' storing each filename with it's categories (or decipher the U-He one lol.)

A more future-proofed approach would be including the full metadata block to support detailed criteria.

i.e.
-Merge 4 random presets in category X+Y with character A+B
-Merge 3 random presets in category Z containing " " in the description.
-Merge 5 random presets by author 'Howard Scarr' with features poly.

Code: Select all

/*
PD Larch.h2p
Author: 'The Unfinished'
Description: 'Lush and lo-fi detuned pad.'
Categories: 'Pads:Analogue, Pads:Strings, Pads:Synth'
Features: 'Poly, Modulated, Soft Attack, Slow Release'
Character: 'Soft, Phat, Synthetic, Vintage'
*/

4) I'm wondering a bit about organization. I doubt it would take long before ending up with a giant pile of presets and retroactive file organization isn't as fun as making more presets. I don't know what the solution is, but maybe an option for the output to go into a named sub-folder in RANDOM, or a dated sub-folder like 24-05-05?

Using a different prefix or sub-folder for merged vs random presets could also help differentiate, as would the option for custom prefixes like RND2 as they would sort/group by prefix, otherwise the sorting will be totally random based on the randomized filenames. For similar reasons when randomizing a single preset I think the random part of the name should be last.

*EDIT* Limited testing so far but the results of merging are better than I expected.
Still a lot of variation, but higher success rate. I've also been deleting useless results as I audition them and moving each batch of merged presets into sub-folders and saving the command in a text file in case I want to re-run it later.

[Fannon]

Hey AtomOfScent!

Thanks! I like all of your suggestions!

Just quickly:
* I've quickly add support to detect ACE and Podolsky and TripleCheese. Haven't tested it, yet.
* 1) That's a cool idea and should be easy to implement!
* 2) Also nice. I already do a "glob pattern match" when reading the presets, so I could allow the user to override it. Currently its "**/*", but you could also do something like "My Folder/**/*" or "**/PD *"
* 3) Yeah, I looked into the u-he database, it's SQLIte and easy to read. But i had troubled understanding their preset tagging. However, my randomizer also parses the metadata and could use that for further selection. All I'm worried about is to make the interface / use too complicated - so not yet sure how to best add such features.
* 4) Yes, I've also thought about that and came up with similar ideas. Subfolders for the different randomization modes may be the first thing to do. For randimizing a particular preset, I kept the original name in there, too - but at the end. Maybe its better to have a sub-folder for original preset that was randomized.

[AtomOfScent]

Glad to hear that!
I'm just about to audition a bunch of new presets, but can test the new synths after.
I've only tried with Zebralette3 so far since there's not many available presets.

A sub-folder for the original preset seems like the best idea.

When I was making a Python script I didn't have the first clue how to add a basic GUI so I asked the coding GPT which recommended Tkinter and it was surprisingly easy. I just did it one step at a time.

If Electron is a PITA, I wonder if a Python script with a GUI could be used as a front-end for all the settings etc. and have that execute the main script for the actual processing? If so, I could take a stab at that.

CustomTkinter looks a bit less "Hello World-ish"

*EDIT* Something like this would work in Python:

Code: Select all

subprocess.run(["ts-node", "app.ts", f"--var1 {var1}", f"--var2 {var2}", f"--var3 {var3}"])

[gonzomaster]

Hello Fannon, I love the merging function. I tested it in Diva and with Zebralette. It works fine. I sent you a few suggestions as PM. Thanks a lot for this fine tool.