@Christoph-Hart said in Saving MIDI CC assignments in user presets?:

If you want to distinguish between the two, you need this method:

https://docs.hise.audio/scripting/scripting-api/userpresethandler/index.html#isinternalpresetload

Personally, I don't need to distinguish between a DAW session reload and a preset load. I just want no MIDI CC data saved to, or loaded from, user presets.

@Christoph-Hart I don't really want lies in my user preset data. Might be confusing to anyone who read/edits the XML

@ustk From what Claude says, this is minimally useful for my situation.

Although you can preprocess the preset data before loading it, you still have to set all the values to something, meaning you can't just say "don't overwrite the existing CC assignments". I suppose you could read the current assignments, then preprocess to replace the preset assignments with the current ones. Phew!

But as I replied to David earlier, that leads to there being lies on disk.

@Christoph-Hart said in Saving MIDI CC assignments in user presets?:

the Midi CC settings are part of the data model of a user preset that is saved in the DAW project

Are you referring here to the saved DAW session, or the saved user preset? Or both?

Saving as part of the DAW session is cool, I just don't want them saved in the user presets.

@ustk Yes, 'active' is too ambiguous a word to have used in the first place. My bad.

@ustk A DAW will only route incoming live controller messages to the active or record-armed track(s), surely?

So if I have 3 different synths all set to respond to mod wheel > filter, then only the active one will respond when I turn the mod wheel, right?

Regardless of whether the synth UI is visible or hidden. It's based on active tracks, right?

The other 2 'unselected', 'inactive', 'not record-armed' synths won't respond to live controller data

Otherwise there would be chaos! Unless that's what you wanted, and armed ALL tracks for record!

@ustk said in Saving MIDI CC assignments in user presets?:

I'd prefer not in my case, because if you load multiple instances of the plugin, they'll all react to the same CC...

That's a very interesting point!

EDIT: actually, maybe it's fine. The DAW will only send MIDI CC to the active plugin, right?

@ustk Not sure. To be honest, I just want all the 'CC data in presets' code out of my fork.

Might just drop the preprocessor and remove it all directly.

I can't see a situation where I would ever want CC data in the presets. So a preprocessor is only useful for backwards compatibility, which I don't have any of

@David-Healey Apparently not.

There are 3 HISE restore points that run after onInit, so it still needs handling.

From Claude:

Fresh instance in a DAW: FrontendProcessor::restorePlugin runs compileAllScripts() (your onInit applies the file) and then restores the
MidiAutomation node from the embedded project state (FrontEndProcessor.cpp:458). The export always writes that node — even when empty, exportAsValueTree adds it unconditionally — so a fresh instance immediately clears the mappings you just loaded. Your file-load is defeated before the user ever touches the plugin.

Reopening a session: the host calls setStateInformation at some point after instantiation (host-dependent timing), and FrontEndProcessor.cpp:576 restores the session's stale mapping copy over whatever onInit applied.

In the editor: every project load stashes the project XML's <MidiAutomation/> and applies it after script compilation (MainController.cpp:562/577)
— same wipe while you're developing.

@David-Healey Maybe, yes.

@David-Healey Claude also found another case to consider - plugin launch.

Looking at it now.

@David-Healey said in Saving MIDI CC assignments in user presets?:

Save the preset - the CC mappings save with the preset, so maybe do a post save callback to remove the data

You don't need to do anything here because you're already loading the CCs from the file.

That's true, but if you leave the CC mappings in the preset file then it becomes lies on disk.

Likely to be confusing to someone looking at the preset XML.

Agree on the AppConfig.h, Claude forced it into the commit, I'll remove it.

@David-Healey Unless you prevent saving/loading the CC data to presets, you're always doing more than you should have to.

Without the preprocessor:

1. Launch the plugin - load the CC mappings from separate file
2. Load a preset - in post load callback you need to reassign CC mappings because they're overwritten by the load
3. Assign some CC mappings - automatically save the new mappings to separate file here
4. Save the preset - the CC mappings save with the preset, so maybe do a post save callback to remove the data
5. Load the next preset, etc.

With the preprocessor:

1. Launch the plugin - load the CC mappings from separate file
2. Load a preset - nothing to do
3. Assign some CC mappings - automatically save the new mappings to separate file here
4. Save the preset - nothing to do
5. Load the next preset, etc.

@David-Healey Scripting the saving and loading of MIDI CC assignments to a separate file is one step, but you also have to fight the saving and loading of the data in the presets.

Claude came up with a (hacky) way to script around it but in the end I felt like a PR with a new preprocessor was better.

https://github.com/christophhart/HISE/pull/995

(I know there are already too many preprocessors, but this is mainly just for me, only upstreaming in case anyone else wants it.)

So now I just turn this off (HISE_MIDI_AUTOMATION_IN_USER_PRESETS=0) and then I don't have to fight anything in script.

HISE saves MIDI CC assignments in the .preset when a user saves.

This seems contrary to a lot of other synths I've used.

Feels like normally, I would set up some MIDI CCs on various knobs, then browse through presets and those CC assignments would stick across preset loads.

This allows me to [1] set up a consistent 'performance' system, like mod wheel to filter cutoff, knob1 to filter res, etc, for all presets and [2] play through presets and have any existing CC automation produce predictable results.

HISE saving MIDI CC assignments to the preset data means that, after setting up a bunch of CC assignments for one preset, when I load a new preset they will either [1] all disappear if the new preset has no saved assignments, or [2] change to different assignments.

If anything, I'd prefer to have MIDI CC assignments saved globally, separate from the preset data, so they persist across not only presets but instances of the plugin.

What do you all do about this?

@David-Healey In a conversation with ChatGPT today, it said to me

Your mockup surprised me—I expected to dislike it. I don't.

AI is getting cheekier!

@Sifres A dedicated Meter Builder' would be cool.

@soundsync It should also support dynamic sizes. Some plugins have keyboards you can show/hide, which change the plugin height.

@ustk @Lurch Don't forget @Christoph-Hart has stripped a bunch of stuff from the version of JUCE 8 customised for HISE.

So unless things have changed, the graphics stuff you're looking forward to might not be available to you, even when JUCE 8 is working smoothly with HISE.

https://forum.hise.audio/post/115594

@lalalandsynth Very nice! Are you using Blender? Do you deliver source files for 3D work?