[feature] Implement the note on/off "extra byte" for microtuning

[jamshark70]

VST MIDI transmission supports a fourth byte, which for note on/off is interpreted as cents (up to +/- 127).

Would it be possible to pass this through to [notein]? May require changes in the Pd layer I suppose.

Use case: Microtuning without hacks. (Fascinating how the industry conspires to make microtuning difficult -- open-source tools should be cooler than that.)

[dromer]

This would be fully incompatible with Pd, maybe a new object should be created to facilitate this?

I don't know any software that supports this, though ..

[porres]

a proposal to add features to [notein] should be made to vanilla's repository

for [else/note.in] you can go to ELSE's repository

[jamshark70]

This would be fully incompatible with Pd, ... I don't know any software that supports this, though

It's irrelevant when the MIDI is coming in through a normal MIDI transport.

PlugData is in the unique position of being a general-purpose audio environment that runs in a DAW -- so extensions to the standard MIDI transport then become relevant.

Of non-support: Plogue's VST2 sforzando player does support this and it's truly fantastic to have, e.g., a piano with syntonic comma adjustments for the harmony. But nobody else will adopt it if everyone just says "nobody supports this" lol

a proposal to add features to [notein] should be made to vanilla's repository

Of course... probably need to raise it on the dev mailing list as it's not a "bug" per se (and I'd expect pushback).

[dromer]

@jamshark70 this is about notes, not transport information ("transport" typically refers to clock/start/stop etc.)

Breaking compatibility with PD is unwanted, so again: we need a new object for this, or as @porres pointed out direct requests for extending the vanilla objects upstream.

Btw which DAWs supply this kind of MIDI information to plugins?

[jamshark70]

this is about notes, not transport information ("transport" typically refers to clock/start/stop etc.)

The data have to get from somewhere to somewhere else. This can be labeled as a data transport. Sorry if my choice of word was confusing. I thought what I meant was clear enough.

Breaking compatibility with PD is unwanted, so again: we need a new object for this, or as @porres pointed out direct requests for extending the vanilla objects upstream.

Which basically means the request could easily just be dead in the water: PlugData says "we won't break compatibility with vanilla"; the Pd side will say "we're not getting VST-specific info in vanilla so we won't do anything either," at least at first.

I do agree that plugdata shouldn't just invent stuff, but insisting that vanilla do it first I think is likely to kill off this idea.

Btw which DAWs supply this kind of MIDI information to plugins?

DAWs, I don't know. Christof Ressi's vstplugin~ / VSTPlugin does (though running Pd inside SC would be an odd approach).

[dromer]

I do agree that plugdata shouldn't just invent stuff, but insisting that vanilla do it first I think is likely to kill off this idea.

Well we have an abstraction called [playhead] that is specific to the plugin context and uses a special receiver not available in PD. It's ok to add new things specific to the plugdata context, as long as existing objects do not break pd-vanilla. Hence I suggested creating a brand new object for a feature like this.

DAWs, I don't know. Christof Ressi's vstplugin~ / VSTPlugin does (though running Pd inside SC would be an odd approach).

Without being able to test such functionality this is such a niche feature that basically nobody can use, what is the point then? We need to be able to test this, so without a plugin host that can provide such data this is dead in the water anyway :shrug:

[porres]

Which basically means the request could easily just be dead in the water: PlugData says "we won't break compatibility with vanilla"; the Pd side will say "we're not getting VST-specific info in vanilla so we won't do anything either," at least at first.

you're missing the other option that was pointed by us

maybe we can have it in else/note.in

[jamshark70]

maybe we can have it in else/note.in

Sure, I can log it for that.

FWIW:

• VST2 has a char detune in VstMidiEvent (PDF link)
• VST3 has a float tuning in NoteOnEvent

If commercial software developers are too blinkered to notice, it doesn't change the fact that it's a good idea.

I guess I'll just log it in else, and close this one. (Extremely busy lately though, it might take awhile.)

[porres]

keep this open, it's a feature for plugdata

[timothyschoen]

maybe we can have it in else/note.in

Sure, I can log it for that.

FWIW:

* VST2 has a `char detune` in [VstMidiEvent](https://jvstwrapper.sourceforge.net/vst20spec.pdf) (PDF link)

* VST3 has a `float tuning` in [NoteOnEvent](https://steinbergmedia.github.io/vst3_doc/vstinterfaces/structSteinberg_1_1Vst_1_1NoteOnEvent.html)

If commercial software developers are too blinkered to notice, it doesn't change the fact that it's a good idea.

I guess I'll just log it in else, and close this one. (Extremely busy lately though, it might take awhile.)

There will also need to be some support for this on plugdata's side, since all MIDI IO from PD goes through plugdata/JUCE. Also, I wonder if inter-app MIDI (with Jack, CoreAudio and whatever Windows has) supports this as well?

[timothyschoen]

So far, looks like CoreAudio and AudioUnit don't support this, and it doesn't look like LV2 and CLAP do either?