@David-Healey You can ask Claude to analyse your previous project styles once for all so it automatically applies it next time

So my solution is incomplete because it doesn't restore CC with session... Back to Chris solution...

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

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

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

Clever!

@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

@dannytaurus The honour of badness is mine

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

@Yannrog The first approach you can follow is this one, before going further with panels

https://www.youtube.com/watch?v=5PmEgPVsGvA

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

@smm-panel I'm so reassured by your honesty I think I'll just jump in, eyes closed!

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

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

@David-Healey @David-Healey So the working solution is

const var currentAutomationState = {"ChildId": "Controller", "Children": []};

const var mah = Engine.createMidiAutomationHandler();

mah.setUpdateCallback(function()
{
	currentAutomationState.Children = this.getAutomationDataObject();
});



const var uph = Engine.createUserPresetHandler();

uph.setEnableUserPresetPreprocessing(true, false);

uph.setPreCallback(function(presetData)
{
    presetData.MidiAutomation = currentAutomationState;
});

The automation state is saved in the instance but you can just save it in a file if you wish so.
I'd prefer not in my case, because if you load multiple instances of the plugin, they'll all react to the same CC...

@David-Healey Lol

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

@dannytaurus @David-Healey Can't the CC mapping simply be removed from the preset using the handler? Isn't the custom preset intended for this purpose in the first place? Never tried myself that being said...

Just checked and the answer is no, you can't manage what is written... But Claude came with a neat solution:

// (processBeforeLoading, unpackComplexData)
uph.setEnableUserPresetPreprocessing(true, false);

uph.setPreCallback(function(presetData)
{
    // presetData is a JS object; MidiAutomation is a top-level property.
    // Emptying it means applyJSON rebuilds an empty <MidiAutomation> node,
    // so the incoming preset never overwrites the current CC assignments.
    presetData.MidiAutomation = {}; // or just rewrite what you already saved
});

@dannytaurus @David-Healey Can't the CC mapping simply be removed from the preset using the handler? Isn't the custom preset intended for this purpose in the first place? Never tried myself that being said...

@observantsound It's true that the doc and the Matrix Modulation itself isn't reputed fully functional yet (but still it works for some of us who patched it) and PRs have been made.

But

I don't see matrixTargetId as a property in the interface property editor.

Only tells me you probably haven't compiled a recent develop branch, because there definitely is a property:

@dannytaurus Fabulous Fable!

@David-Healey Yeah I needed it for visual meaning in a label so Win users aren't lost

@David-Healey because I had this in the same script

const var PATH_SEPARATOR = Engine.getOS() == "OSX" ? "/" : "\\"; // last " is escaped

const var someStringWithHashtag = "#"; // the first " closes the above line, so # is in the wild...

and the parser sees the second \ as an escape for the next char, which is ", hence messing the double quotes count.
Ii is not seen as an error until the parser sees a # which instead of being taken as string, is taken as a preprocessor call.

@David-Healey Claude found it's a parsing issue with double backslash escape that de-sync the parsing:

const var PATH_SEPARATOR = Engine.getOS() == "OSX" ? "/" : "\\";

That "\\" is a perfectly valid HISEScript string (one escaped backslash). But HISE preprocesses every script through the SNEX preprocessor before the JS compiler sees it, and that preprocessor has a buggy string scanner (snex_jit_PreProcessor.cpp:594):

// it only treats a backslash as an escape when the NEXT char is the quote:
if (*start == '\\' && *(start + 1) == quoteChar) { start += 2; continue; }

Walking "\\": it reads the first \, then sees the second \ sitting right before the closing " and concludes the " is an escaped quote — so it keeps scanning past the end of the string, swallowing text until the next " somewhere later. From that point on, the preprocessor's idea of "inside a string / outside a string" is inverted for the rest of the file.

Why single quotes fix it, and why it's specific to this script:

• Line 4's trap flips quote-phase for everything after it. Approaching line 443, the preprocessor wrongly believes it's inside a string.
• With '#': the ' and # are just harmless characters inside that (phantom) string → no problem.
• With "#": the first " closes the phantom string → the preprocessor is now "outside" → it sees a bare #, which it treats as a preprocessor directive marker (#define/#if/…). It grabs #" + i;, fails to match a directive, blanks the block, and the mangled leftover reaches the JS tokenizer → its JSON-based string parser hits EOF mid-string → "Unexpected EOF in string constant".
• It's confined to this file because the preprocessor runs per-file, and this is the file that contains both the "\\" trap and a #.

I proved it: replacing line 4's "\\" with the equivalent "\u005C" (same backslash, but no \\ right before the quote) makes the "#" version compile with zero errors.

Fix options
Recommended — remove the landmine. Change line 4 to a form that doesn't put \\ against the closing quote, then # works anywhere (double-quoted included):

const var PATH_SEPARATOR = Engine.getOS() == "OSX" ? "/" : "\u005C"; // backslash; avoids preprocessor quote-desync