Saving MIDI CC assignments in user presets?

[David Healey]

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

Also note that the HISE_MIDI_AUTOMATION_IN_USER_PRESETS preprocessor I added is unlikely to get merged, per Christoph's responses earlier in this post.

Yes I'm hoping Christoph will find a solution that is mergable, although I don't see why yours shouldn't be.

[dannytaurus]

@David-Healey I think maybe the HISE_MIDI_AUTOMATION_IN_USER_PRESETS preprocessor is more mergeable than the HISE_MIDI_AUTOMATION_IN_PLUGIN_STATE?

The system might be built around a certain state that has repercussions when it changes.

For the USER_PRESET one, on preset save the MidiAutomation state manager is skipped, so the preset file gets no MidiAutomation node at all and on preset load the MidiAutomation restore step is skipped entirely, so nothing is overwritten in the UI.

The mappings are still persisted in the DAW session chunk and embedded plugin data.

So maybe that change to the preset format - the missing MidiAutomation node - could cause some issues?

[dannytaurus]

In hindsight, I think adding the HISE_MIDI_AUTOMATION_IN_PLUGIN_STATE preprocessor in the same PR as HISE_MIDI_AUTOMATION_IN_USER_PRESETS was a mistake.

I don't think I'll ever use it, since USER_PRESETS and some simple save/load MidiMappings.json in script gets me exactly what I need.

The PLUGIN_STATE is more complex and messes with the state of the plugin instance, which I think is Christoph's main objection.

[David Healey]

@dannytaurus I'm getting a bit overloaded here following what each part does.

I want everything to be in an external file (midi/macros/mpe). If the file doesn't exist then create it based on the values stored in the preset.

When the plugin loads, the daw session loads, the user changes preset, I want the same values from the external file to be used.

Which combination of your preprocessor definitions should I be using to achieve this?

[dannytaurus]

@David-Healey Sounds like you might want the truly global behaviour that I ultimately decided against.

If you enable both preprocessors (by setting them to 0 since 1 is default and current behaviour) :

HISE_MIDI_AUTOMATION_IN_USER_PRESETS=0
HISE_MIDI_AUTOMATION_IN_PLUGIN_STATE=0

then NO mappings will be saved per-preset, NO mappings will be loaded from a saved DAW session state, and NO mappings will be loaded when the user changes presets.

Every preset saved by the user will have zero mappings.
Every instance of the plugin freshly loaded in a new DAW will have zero mappings.
Every instance of the plugin loaded from a saved DAW session will have zero mappings.
Every additional instance of the plugin loaded into a DAW will have zero mappings.

Then all you have to do is wire up your global mappings file to the plugin-load and preset-load callbacks.

I decided against this approach because:

1. This will overwrite a user's saved custom mappings with global when a saved DAW session is reloaded
2. When loading a fresh instance of the plugin, the global mappings will load, which might not be what the user wants
3. When changing presets, the global mappings will be loaded, which might not be what the user wants.

My take on those situations is:

1. Load whatever mappings are in the saved DAW session because that's how the user saved them
2. If the user wants to load mappings in a new instance of the plugin, it's just one "Load Default Mappings" button press
3. When changing presets, I want whatever mappings are already there to stay there and not switch to the global ones.

I hope all that makes sense. I was genuinely trying to answer as briefly as possible, but there's a lot going on!

[dannytaurus]

@David-Healey By the way - you might have to extend my PR to include macros and MPE in the saved data. I'm only accounting for MIDI CC mappings because I haven't down any thing with macros or MPE in my plugins yet.

[David Healey]

@dannytaurus Aha I don't think that will help me then. The saving/loading I can do already, and I like having the fallback in the preset. The issue I have is that the updateCallbacks trigger multiple times and overwrite the data I've saved. I'll keep trying.

[dannytaurus]

@David-Healey Yeah, that's why I wanted a solution that didn't involve any plugin/preset callbacks at all.

Just wanted zero mappings saved in the presets, and a nice clean MidiMappings.js save/load script.

[David Healey]

@dannytaurus I decided to see what Claude would do with the problem. It's a massive commit so I'm not going to rely on it, but I'll leave it here as it might be a starting point for Christoph - or who knows, maybe it's perfect!

https://github.com/davidhealey/HISE/commit/adc0826307163d1e8781d8b024a2090233dfe0c9

[Christoph Hart]

Worked on this today:

https://github.com/christophhart/HISE/commit/528ccf712722db6bb213470e40a0b4cb47f9775b

I didn't use any preprocessors but a dynamic API call - there's no need for this to be a compile-time setting.

You can define for each of macros, midi & mpe assignments whether they should be stored externally, in the user preset or in the plugin state.

Docs:

https://github.com/christoph-hart/hise_api_generator/blob/271ca2d159ce26e9077ec7638b1f41ea68ba2f3d/enrichment/phase4/auto/UserPresetHandler/setStateManagerProperties.md

[David Healey]

@Christoph-Hart Oh nice, I'm going to dig into it this evening and try it out. Thanks!

[David Healey]

@Christoph-Hart For expansions will it use one external xml file per expansion?

[Christoph Hart]

@David-Healey you can specify the file in the onInit callback so for rhapsody it should work if the developer keeps it tidy