Ok, I knew I had to also update some libpd stuff, but didn't want to do it right away and test things first. I was able to compile and test, and now I see the libpd test is failng :)

I'm not comforable in messing with the libpd functions but I can try

I was gonna ask @danomatika to give me some warnings and guidance anyway

libpd relies on the outmode_noteon and inmidi_noteon functions, so changing their function arguments breaks libpd's current usage.

It essentially

• implements outmidi_noteon here
• allows setting a custom noteon "hook" aka user-provided function which is passed messages from libpd's outmidi_noteon
• the libpd_noteon function passes messages into pd's inmidi_noteon function

All of these functions rely on the current number and type of arguments, hence the build errors.

Without reading in detail, do I assume the MPE protocol requires making a distinction between noteon vel 0 and noteoff? If so, and built-in support is required, then I would recommend an internal noteoff message and move the type filtering logic into the [noteon] and/or add a [noteoff] object.

Also, libpd_noteonhook and libpd_noteon have not changed since the project was originally released, circa 2010. Changing them now involves lots of pain to both projects and the various language wrappers which use them. It's not impossible technically but not a likable change a specific feature addition...

If so, and built-in support is required, then I would recommend an internal noteoff message and move the type filtering logic into the [noteon] and/or add a [noteoff] object.

I am doing some logic in both [noteon] and [noteoff] objects, but I guess I know what you mean, adding a new internal message, right?

And with such a new message we can prevent all the pain in the ass and issues with libpd, right? Please shed me some more light, give me some hints and clues, and I'll try to head into the right direction