So i can’t use that data pointer directly. How can replace data in the MidiMessage now, do i need to use the static methods to re-create the MidiMessage ? A simple cast to (uint8 *) will suffice ?
It should never have been non-const, and you shouldn’t be poking around in there directly. If you can’t just create a new message and really do need some raw midi bytes to mess with, you should just use your own array for it.
Well maybe i can persuade you. I use MidiMessages in two ways, sending MIDI is obvious and using your static methods is OK then.
But receiving them is a different thing, especially realtime SysEx, i need to merge the “changed” bytes of the message to an already existing one MidiMessage i have
so i can later send it, update it etc. Also if i can’t access this memory i need to do more re-allocations and that’s time consuming. Maybe you could leave it not const or
give us a different way to access and change that memory. I promise i won’t break it.
Sorry, not convinced! The MidiMessage class isn’t designed to be a mutable byte array, and by allowing it to be poked around, the length that it thinks it has could become out-of-step with the length of its actual content.
If you have some kind of message hanging around that you’re merging incoming data into, the MidiMessage is the wrong thing to hold it - since this is your own custom blob, why not just put it in an array of bytes? You can still send it as a message when it’s ready by just passing your array to the MidiMessage constructor. I can’t stop you casting away the constness of the MidiMessage and hacking it, but that’s not how I’d do what you’re describing.