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

[gonzomaster]

A short addition… I like your tool because it is so simple; you should not complicate things if not necessary

[Fannon]

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}"])

Yes, what you propose would work. Allthough I'm afraid that just having a UI to trigger the CLI with the right arguments may not be so helpful that it's worth having another program to download. If you build an UI, it would really start making sense once it comes with a preset browser and allows you to select presets to merge / randomize there, maybe with filtering and search. That would indeed be very nice, but it's also something rather challenging.

[Fannon]

Update: With version 0.6.0, a few of the suggestions have been implemented.

Random preset location uses now subfolders as suggested by AtomOfScent
Use '?' to select a random preset from selection. (also AtomOfScents idea)
Use '*' to select all presets in a selection.
Before loading the library, you can customize the glob pattern which presets are loaded. By default it takes everything, but now you can control this if you know how to use glob patterns with wildcards. (E.g. "**/PD *" will only load presets that start with "PD ", while "My Folder/**" will load only load presets that are within that folder. This works nicely together with the "*" select when merging presets.

I hope this isn't making things to complicated. There is now one more interactive step, but you can just press ENTER if you don't want to change your pre-selection of presets.

[glokraw]

Thanks for sharing a valuable tool and capability! In a large preset folder, I put the original U-he randomizer script at the start, middle, and end of the preset list, so I don't have to scroll to click it and generate the new sound. It would be great if your new utility could operate in some similar way. Could your tool, with various command options, be disguised as .h2p files?
Cheers

[Fannon]

Thanks for sharing a valuable tool and capability! In a large preset folder, I put the original U-he randomizer script at the start, middle, and end of the preset list, so I don't have to scroll to click it and generate the new sound. It would be great if your new utility could operate in some similar way. Could your tool, with various command options, be disguised as .h2p files?
Cheers

Sorry, that won't work. I would be surprised if u-he synth would allow some .h2p scripts to call external tools from inside the plugin. Also, if you want to merge multiple plugins, you need to make a selection of more than one preset.
This CLI tool and the h2p randomizing script will also give you different results, because their approach how to randomize things is quite different!

[Chris-S]

Hi,
how does the tool handle the binary section of h2p patches?

[Fannon]

Hi,
how does the tool handle the binary section of h2p patches?

Honestly, it doesn't. I just ignore this so far and just drop it entirely from the generated presets. But what I wanted to do is to at least try to keep it for randomized presets, or randomly pick a binary section for merged / fully random presets. Need to test this first, because I really don't know if this could put a preset into a messed up state.

I'd like to understand how this binary section could be parsed and serialized again, but I haven't found anything that would explain it. Does anyone here know more?

[Chris-S]

All I know is that there are some dependencies between the ascii and the binary part. My repro2hive converter is adding one of two binary blocks depending on the wavetable usage.

[Fannon]

All I know is that there are some dependencies between the ascii and the binary part. My repro2hive converter is adding one of two binary blocks depending on the wavetable usage.

That's what I was afraid of - and why I didn't put it in. So far, it looks like it's not a problem if its missing. But I'm really not sure what happens if you just drop in a binary blog but change the parameters part of the patch.

Do you have a link to your converter, or could you PM me with a link / code if that's OK for you? Or did I understand you right and you just have two, fixed binary blobs that you know set the wavetable the way you need it?

[Fannon]

Ok, I have decided to enable keeping the binary part of a preset (or picking a random one). Since I cannot really tell how well this really works, it's optional and needs to be enabled by passing --binary. Its now available with version 0.6.2 in case someone wants to try it out (feedback welcome!)

Code: Select all

npx u-he-preset-randomizer@latest --binary

[Chris-S]

My tool is not yet released. The binary part is just copied from the init patch. For WT-using patches the binary is copied from a modified init patch.

[AtomOfScent]

Yes, what you propose would work. Allthough I'm afraid that just having a UI to trigger the CLI with the right arguments may not be so helpful that it's worth having another program to download. If you build an UI, it would really start making sense once it comes with a preset browser and allows you to select presets to merge / randomize there, maybe with filtering and search. That would indeed be very nice, but it's also something rather challenging.

Yes,
At the moment I'm modifying the commands in a txt file and pasting it in (replacing preset names etc.) which works pretty well. It's easier now that I'm more used to it. It's a great script.
Hopefully it serves as a proof of concept and u-he builds something similar into the preset browser.

I'm trying to think of another way to make the CLI more user-friendly. Maybe using batch files which take certain info from the folder they are run from + certain info in the batch file, then it only needs to ask for a few required missing parameters when running.

i.e.

Code: Select all

npx u-he-preset-randomizer@latest --synth [from *.data folder]  --amount 8 --merge "=[currentfolder]/PD ?.h2p" --merge "=[currentfolder]/PD ?.h2p" --merge "=[currentfolder]/PD ?.h2p" --merge "=[currentfolder]/[user selection]"

Running a .bat file with something like this in a Diva preset folder would know it's Diva, create 8 presets, merge 3 random "PD " (pad) presets from the current bank (subfolder) and ask the user to make a selection from the presets in the current folder.

Code: Select all

npx u-he-preset-randomizer@latest --synth [from *.data folder] --amount 8 --preset "[currentfolder]/PD ?.h2p" --random 15

This would generate 8 presets with 15% randomization for a random pad preset in the current directory with no input. "/PD *.h2p" would ask the user to pick from a list of pad presets in the current folder.

That way the user could create a set of batch files and run them from any preset (sub)folder for any synth to create different types of presets with minimal input. [ ] parts are just to get the idea across.


A couple other thoughts after more usage:

1) There are a few parameters I think should always be excluded like Output, voice mode, global transpose, (values other than of -12, 0 +12), finetune etc. Maybe it could even be possible to exclude specific sections #cm=ARP or parameters Trsp= (ignoring if not found.) I doubt you'd want to add extra steps to the CLI, but it wouldn't be an issue with a .bat method, or the script could possibly be called in a simple or advanced mode (extra steps). The randomize.h2p script might give ideas on what best to exclude.

2) Another thing I noticed when merging is what seem to be duplicates. This would make sense if using chunks as there would be a limited # of combinations. An easy way to avoid this could be a randomize % for additional variety. --merge with --random 10 would add 10% randomization to the parameters post merge. Another way could be increasing the # of chunks depending on the # of presets being created.

3) As randomized presets are already in sub dirs and include the preset name adding RND might be unnecessary, but it's more of a personal preference thing. Also after I delete the duds I move them into other folders (by type or bank) since there might only be a few in each folder, so having the randomized part of the name after would keep them grouped/sorted by the original preset.

4) When creating random presets a mode by that creates by type could be a really useful middle ground. This could operate like a hidden merge mode using common prefixes. Type PAD could merge 4-5 random presets starting with PAD or PD and add an additional 5-15% randomization. Type BASS could be BS , BASS , BA , BL , etc.

5) With Diva I get the following every time which is likely specific to my system, but as I can't do anything about it I don't know if it's useful to show.

Code: Select all

/1RN Unexpected duplicated header + key for: MAIN/
/2RN Unexpected duplicated header + key for: MAIN/
/1RN Unexpected duplicated header + key for: MAIN/
/2RN Unexpected duplicated header + key for: MAIN/
/1RN Unexpected duplicated header + key for: MAIN/
/2RN Unexpected duplicated header + key for: MAIN/
/1RN Unexpected duplicated header + key for: MAIN/
/2RN Unexpected duplicated header + key for: MAIN/
/1RN Unexpected duplicated header + key for: MAIN/
/2RN Unexpected duplicated header + key for: MAIN/
/1RN Unexpected duplicated header + key for: MAIN/
/2RN Unexpected duplicated header + key for: MAIN/
/1RN Unexpected duplicated header + key for: MAIN/
/2RN Unexpected duplicated header + key for: MAIN/
/1RN Unexpected duplicated header + key for: MAIN/
/2RN Unexpected duplicated header + key for: MAIN/
/1RN Unexpected duplicated header + key for: MAIN/
/2RN Unexpected duplicated header + key for: MAIN/

[Fannon]

Update: I've now released v0.7.0 which includes --randomization support for merged presets and hopefully improves the CLI interaction a bit overall.

I'm trying to think of another way to make the CLI more user-friendly. Maybe using batch files which take certain info from the folder they are run from + certain info in the batch file, then it only needs to ask for a few required missing parameters when running.

That's an interesting idea! In general, I like having CLIs being context dependent like that. But in this case, it would be difficult, as the CLI relies on a synth detection. And with the --pattern feature, you should already be able to do some pre-selections as you can also narrow down on subfolders with that.

1) There are a few parameters I think should always be excluded like Output, voice mode, global transpose, (values other than of -12, 0 +12), finetune etc. Maybe it could even be possible to exclude specific sections #cm=ARP or parameters Trsp= (ignoring if not found.) I doubt you'd want to add extra steps to the CLI, but it wouldn't be an issue with a .bat method, or the script could possibly be called in a simple or advanced mode (extra steps). The randomize.h2p script might give ideas on what best to exclude.

Yes, agree. That would be really nice and could be introduced as a more stable randomization mode, that you can opt-in. Do you have a good list for such parameters? I haven't found any in the randomize.h2p script. I assume that the selection of parameters to keep stable (and how) may be synth dependent. So adding this is some work, where it would help to get feedback on which parameters to lock down.

2) Another thing I noticed when merging is what seem to be duplicates. This would make sense if using chunks as there would be a limited # of combinations. An easy way to avoid this could be a randomize % for additional variety. --merge with --random 10 would add 10% randomization to the parameters post merge. Another way could be increasing the # of chunks depending on the # of presets being created.

Yeah, you're right - merged presets are not random enough right now. I've now enabled --randomness for the merged presets as well, it defaults to 5% in that mode.

3) As randomized presets are already in sub dirs and include the preset name adding RND might be unnecessary, but it's more of a personal preference thing. Also after I delete the duds I move them into other folders (by type or bank) since there might only be a few in each folder, so having the randomized part of the name after would keep them grouped/sorted by the original preset.

Yes, I think this may be personal preference. I have a "RANDOM Keepers" folder, where I move the good ones

4) When creating random presets a mode by that creates by type could be a really useful middle ground. This could operate like a hidden merge mode using common prefixes. Type PAD could merge 4-5 random presets starting with PAD or PD and add an additional 5-15% randomization. Type BASS could be BS , BASS , BA , BL , etc.

I like the idea, but coming up with that list of similar prefixes would be difficult. Many presets do not follow such conventions at all. What you could do though is to use the u-he preset browser, use it to filter by tags (Categories). Then you could select and copy all those together into one folder, which you then select via --pattern.

5) With Diva I get the following every time which is likely specific to my system, but as I can't do anything about it I don't know if it's useful to show.

Code: Select all

/1RN Unexpected duplicated header + key for: MAIN/
/2RN Unexpected duplicated header + key for: MAIN/

Yeah, that's something unexpected I'm not getting on my side. I've updated the tool to also mention which preset is causing that issue. Can you try again with latest version and maybe send me one of the affected presets via PM?

[AtomOfScent]

Update: I've now released v0.7.0 which includes --randomization support for merged presets and hopefully improves the CLI interaction a bit overall.

The CLI is nicer.
I tried to do Repro, but could only get to to work for Repro-1, maybe separate entries for Repro-1 and Repro-5 are needed?

If still find this part a bit confusing (Glob newb}:

"**/*" will load all presets in all folders (default).
"Some Folder/**/*" will load all presets in Some Folder
"**/PD *" will load all presets starting with "PD ".

This might be easier (I could be misunderstanding how it works now):

"Some Folder/" [search all folders to find match(es)]
"PD *" [load all presets starting with "PD"]
"PD *" and "PAD *" [load all presets starting with "PD" AND "PAD"] would be cool too.

I'll test the merge randomization.

That's an interesting idea! In general, I like having CLIs being context dependent like that. But in this case, it would be difficult, as the CLI relies on a synth detection. And with the --pattern feature, you should already be able to do some pre-selections as you can also narrow down on subfolders with that.

If auto-detecting the synth by the current data folder is an issue it would be easy to just make .bat files for each synth (the user would want copies in each synths folder anyway). The main thing is whether the CLI requires the parameters in order.

i.e. for the following it would know that --preset is the only thing missing and ask for that when run.

Code: Select all

npx u-he-preset-randomizer@latest --synth Diva --amount 8 --random 20

It's just a matter of eliminating most steps when you mostly know what you want. There could be other ways of streamlining like templates. If there was a standard format users could stick them in a .txt file somewhere (*\Documents\u-he\preset randomizer tool\ ?)

Preset Random Pads
-Pick synth
[template format=] --merge 5 --"PAD ?" --amount 8 -- random 5
= merge 5 random presets starting with "PAD ?", create 8 presets, 5% added randomization

Preset Randomized Key
-Pick synth
[template format=] --amount 8 --preset "=Luftrum ?/KEY ?" --random 20
= create 8 variations of any preset starting with "KEY" in any folder starting with "Luftrum" with 20% randomization.

Just random brainstorming (not thought through.)

Yes, agree. That would be really nice and could be introduced as a more stable randomization mode, that you can opt-in. Do you have a good list for such parameters? I haven't found any in the randomize.h2p script. I assume that the selection of parameters to keep stable (and how) may be synth dependent. So adding this is some work, where it would help to get feedback on which parameters to lock down.

Here's the link with the original randomize.h2p scripts.

I attached my modifications which are basically the same, but allow choosing different randomize %s. In the original one there is an end block which if un-commented will randomize ALL parameters (usually giving worse results). Those are the FULL versions in my attachment.

If it's not useful, I could manually make a starting list of parameters that are probably best left alone (others are free to contribute.)

Yeah, you're right - merged presets are not random enough right now. I've now enabled --randomness for the merged presets as well, it defaults to 5% in that mode.

Perfect!

Yes, I think this may be personal preference. I have a "RANDOM Keepers" folder, where I move the good ones

I'll try moving the keepers then deleting the remaining from Windows Explorer and see if I prefer the workflow.

I like the idea, but coming up with that list of similar prefixes would be difficult. Many presets do not follow such conventions at all. What you could do though is to use the u-he preset browser, use it to filter by tags (Categories). Then you could select and copy all those together into one folder, which you then select via --pattern.

I would say most 3rd-party developers use some type of prefix scheme. I can take a closer look and make a a proper list when I get a chance. The idea of filter by category and copy into folders sounds good, I'd just want to keep them separate from my main preset folder. It would be great for favorites too so you could chose that folder and populate the list of choices with only your faves.

Yeah, that's something unexpected I'm not getting on my side. I've updated the tool to also mention which preset is causing that issue. Can you try again with latest version and maybe send me one of the affected presets via PM?

I get it with other synths too. I think it could be the randomize scripts I attached above as they are copies and I only changed the rand % so they might be seen as dupes...

[Fannon]

Update: I've now released 0.8.0, which includes a new --stable modifier for the randomization.

For fully random presets, it will randomize not per parameter, but per section (e.g. the entire OSC1 together). Only parameters with numeric non-binary assignments will be further randomized. Otherwise they stay consistent with the chosen base preset or a random starter preset. This should also keep mod source assignments stable.

This could already address some of the concerns mentioned here in the thread about parameters, that should not be randomized without care. It's however not locking down specific parameters, the approach is still very generic. Maybe this is sufficient and a good compromise? Would be interested in how well it works out for you here.

The "randomization modifiers" stable and binary can now be chosen in the interactive CLI as multi-select checkbox toggles. Both are optional and not enabled by default.