definitions are very much optional…
so I (personally) think adding extra settings/functionality to them is not a good idea.
that said, Id say it be fine, for a definition to be able to set the current ‘default’ setting, as this already exists in the UI.
however, this does not solve the underling issue…
imagine your synth allows all parameters to be set via CC.
now one day you have programmed a preset on your synth… (and not saved it )
the default (or your reset value) you have set on the hapax will NOT be what you want it to be, basically you’ll hit STOP, and suddenly all your synths values will change.
thats why I say, it can only really work when you have recorded automation, since then (by definition) you have already started overriding the synths preset value.
so yeah, there is no perfect solution here… (*)
and you have to be very careful, that the hapax doesn’t start sending out spurious cc messages on stop, which will upset a LOT of users
(*) unless you have full bi-directional midi, but even that has issues
this is why this topic is one to talk to Squarp about, they are very familiar with these kind of ‘side effects’ and compromises due to all the experience/feedback they have from the pyramid etc.
(as I say though, I think possibly, an exception for cc74/sustain could be made… as its one of the few CCs that actually has a reasonably well defined meaning - that said, my general suggestion does also work for CC74/sustain too… as you’ll be recording it , so it can then default to zero.)