Saving MIDI CC assignments in user presets?

[ustk]

@David-Healey Apparently macro yes, but MPE
Here's the automation data object:

[
  {
    "Controller": 6,
    "Channel": -1,
    "Processor": "Interface",
    "MacroIndex": -1,
    "Start": 0.0,
    "End": 1.0,
    "FullStart": 0.0,
    "FullEnd": 1.0,
    "Skew": 3.106283926937945,
    "Interval": 0.0,
    "Converter": "37.nT6K8CBGgC..VEFa0U1Pu4lckIGckIG.ADPXiQWZ1UF.ADf...",
    "Attribute": "HiBoostBWKnb",
    "Inverted": false
  }
]

[ustk]

@David-Healey Just tested with my seaboard and yes, it works for MPE that have been MIDI learnt (Since it's just MIDI in the end...)

[dannytaurus]

@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]

@dannytaurus If by inactive you mean hidden UI, then Midi is still reaching them

[dannytaurus]

@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]

@dannytaurus Oh yes absolutely, active in the sense of "armed track", then 100% yes

[dannytaurus]

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

[ustk]

@dannytaurus The honour of badness is mine

[David Healey]

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

So the working solution is

I think there's more to it, at least if you're saving/loading it from a file.

setUpdateCallback is triggered before on init and setPreCallback is only triggered when loading a preset.

So we need it to be that when we make a change to automation we save the the object to a file.
Then at init we load that object from the file using setAutomationDataFromObject
And during preload we pass the object into preset data.

[ustk]

@David-Healey Absolutely, then the mah.setUpdateCallback allows you to easily write the file, that's why I said "or just rewrite what you already saved" in the post above

[David Healey]

@ustk Yeah I've got it working now. I've set it to fall back to the preset's automation if the one loaded from the file is empty. That way I can setup my "defaults" in the preset file.

[ustk]

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

That way I can setup my "defaults" in the preset file.

Clever!

[ustk]

@David-Healey Till today I wasn't aware of this setEnableUserPresetPreprocessing, this will save me from other situations where I was tinkering with the pre/post save/load in order to keep parameters persistent...
I'll keep that in mind now!

[Christoph Hart]

the Midi CC settings are part of the data model of a user preset that is saved in the DAW project, otherwise it would loose the connections when you reload a DAW project.

If you want to clear the Midi assignments when browsing user presets, you can easily just clear it in the post load callback and guard it behind the !uph.isInternalPresetLoad() check.

And any Midi CC connection reacts the same way as note input, so if you have armed multiple tracks it will control multiple instances. Feature, not a bug.

[dannytaurus]

@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.

[Christoph Hart]

@dannytaurus HISE treats a user preset and a DAW state exactly the same - it reloads everything in the data model including the CC assignments.

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

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

I wouldn't start hacking around in the source code for this, the data model needs to stay consistent, this is just an UX problem while preset browsing that you can solve easily on the script level.

[dannytaurus]

@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.

[dannytaurus]

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

[dannytaurus]

@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.