MIDI Out Bug? Note Number offset observed

[jjdeprisco]

I’m working with an external hardware MIDI project and have noticed a variance in how Touchdesigner treats MIDI note assignment.

First, keep in mind that this project does not use TDAbleton, and I do not want to use it for this purpose.

My project uses 12 notes, C2 to G3. I have confirmed through three other methods (MIDI Monitor, VCV Rack, and Ableton) that those are indeed the notes I am using.

Those notes correspond to MIDI note values 36, 38, 40, 41, 43, 45, 47, 48, 50, 52, 53, 55 per multiple available reference charts.

See Note chart

However, when I tried to set this very same project up using Touchdesigner as the note generator, I found a 13 value offset in how the note numbers were assigned. Through trial and error, I was able to determine that the notes that were previously starting with 36, etc… have now shifted to C2 at 49 (see below chart).

Sure, this can be hidden under the hood. I can still get the project to work. But I’d prefer to understand where this offset originates. What’s more, rather than being an offset of 12 (perhaps because of some quirk of how Middle C is assigned in TD), this is an odd offset of 13!?!

Been working with MIDI since the early 90s… so I’m really curious where this offset is being introduced so I can understand it if it pops up anywhere else. Haven’t seen anything like this before.

[jjdeprisco]

Further, I’ve been able to show the offset in real time from the MIDI input. So Touchdesigner is definitely applying this offset somewhere:

Touchdesigner MIDI Offset

Occurs on both PC and Mac builds 2021.15800

[rob]

Can you send us your toe file? (to support@derivative.ca)
Nothing intentionally offsetting things by a value of +13 in our code.
Very odd case.
Thanks

[jjdeprisco]

Sure. I will send you the same TOE from the video above.

MIDIOffset.toe (3.5 KB)

[rob]

It looks okay on my end.
Instead of the MIDI In CHOP, can you use the MIDI Event DAT ?
(be sure to turn on the Bytes Column on the Received Events page).

Is your chart in hex or decimal? TD uses decimal values for the channel names, but the Bytes column on the MIDI Event DAT will show hex values so we can compare.

Thanks.

[jjdeprisco]

Sure. The MIDI Event CHOP shows same thing. C2 still incorrectly becomes 49.

This is pure TD, without anything else in the build. No other components. I am not using any conversion tables. I’ve shown this to be the case with both an Arturia Keystep as well as a KORG Triton Extreme.

MIDIOffset.toe (3.9 KB)

[rob]

Well TD doesn’t actually have any code that offsets the ‘30’ that you see above, nor does it work with english note names (eg C2).

‘90 30 xx’ and ‘80 30 xx’ really does correspond to index 48 (or 49 base 1).
Can you confirm what hex bytes are being sent?

In my test cases with your toe file, I send a message of ‘80 31 41’ for example, and those are the same bytes that are received.

Thanks,
Rob

[jjdeprisco]

It sounds like you are saying I need a way to read HEX off of the controllers here. I don’t know how to do that yet. The MIDI monitor app that I have doesn’t appear to offer that option, but I can check.

The bottom line is that C2 is a MIDI standard name that multiple programs/controllers are recognizing properly here. OK, maybe TD looks at HEX and not the industry standard name and standard MIDI numbering. But regardless, I would expect the hex to be translated properly.

I’ll see if I can find a hex reader and post another update later.

[jjdeprisco]

According to MIDI View, I get the same HEX values:

However, that doesn’t solve anything. Every other DAW and application I have used will see the C2 as MIDI Note 36 - not 48… not 49. So I still think this is a significant mismatch in how TD interprets MIDI values.

As previously noted, C2 through G3 should be mapping to a MIDI note value of 36, 38, 40, 41, 43, 45, 47, 48, 50, 52, 53, 55 per multiple available MIDI reference charts.

See Note chart

Other charts exist. A Google search will give you many.

I didn’t make up the charts. They are what they are. This has nothing to do with what I am trying to build. This is about the mismatch between the MIDI standard and how TD is manipulating the incoming data (and therefore, the output as well). It’s also not controller manufacturer specific - the issues here can be shown with an Arturia controller and an older KORG Triton Extreme controller.

Further, I pointed an Ableton project - which uses C2 - G3 - at MIDI View. It has the same type of output, and MIDI View confirms these are indeed notes between the C2-G3 range (MIDI Notes 36 - 55 per above).

Again, knowing this is a mismatch, one can work around it. But the mismatch should not exist in the first place.

[jjdeprisco]

Here’s the root of the confusion…

The table I referenced - which is far from a “standard” summarizes the MIDI note numbers as defined in the MIDI standard and matched to the Middle C (note number 60) as C4.

If you work your way back from their C4 of 60, that brings you to the C2 of 36 that I referenced above. That’s find in their world, but isn’t compatible with TD.

That changes everything. TD uses a different value for Middle C, which changes the way C2 will be referenced/calculated

So if anything, some additional documentation on this point would be helpful on the TD site. What is being used as middle C in your programming?

[rob]

So, in this case its sending ‘90 30 64’ and TD in fact receives ‘90 30 64’

Your MidiView shows ‘Channel’ and ‘Value’ and ‘Hex’, is there an option to turn on index?

To be honest, confused why you consider C2 to be note 36 in your setup , since it is in fact sending ‘90 30 64’ , and 30 = index 48 out of 127, not index 36 out of 127.

So TD seems to be doing what I’d expect it to do.

[jjdeprisco]

Rob,

As noted in my last post, the 36 was a red herring because of the chart I was referencing. It was not clear that the “standard” MIDI notes shown there are far from “standard”.

But I would still be curious to know what Touchdesigner is using as the value of middle C (in MIDI Note number terms). Probably 60 from what I’ve gathered so far.

Middle C

But at this point it’s moot. This was still instructive though.

[rob]

Hi, to be clear, TD has no concept of middle C.
The index is simply the index passed in the actual midi message, which only consists of numeric values. The midi messages do not contain any information on labels.
I think it would be more accurate to say your application describes C2 as ‘note 48’ which TD labels ‘n48’. Does that make sense?

[jjdeprisco]

Yes, and no. This is not about “my program”.

Ableton is not “my program”. Likewise Arturia and Korg controllers are not using “my program”. It’s about specifications used by manufacturers/developers outside of my control.

In most cases, per the MIDI Specification (which TD appears to follow based on this discussion)

As noted in the link provided above:

Middle C is MIDI Note Number 60.

This can be C3 or C4, or even C2 or C5. There is no defined standard or convention. The MIDI standard only says that the note number 60 is a C, it does not say of which octave.

Ref.: Complete MIDI 1.0 Detailed Specification :

Each note is assigned a numeric value, which is transmitted with any Note-On/Off message. Middle C has a reference value of 60. This is the middle C of an 88 note piano-style keyboard though it need not be physically located in the center of a keyboard.

It’s been my experience that designers outside of the music software realm do not understand how critical it is to document these sorts of things, and how important it is to attempt to follow some sort of standard.

What got me confused at the outset was that:

a) the chart I was using was based on C4 being 60. In the end, we learned that TD is treating C3 as 60.

b) TD also adds an option for 0 vs 1 based counting, so that’s how we get the confusing problem of C2 = 49 (48 + 1).

That’s all explainable now, but only after deep consideration, further testing, and discussion and not because it was immediately obvious from the documentation. So while not a true “bug” this did show the lack of documentation.

[snaut]

Hi @jjdeprisco,

this conversation piqued my curiosity espcially also how to communicate this better in the documentation. Is the main issue that the One Based Index parameter is enabled by default resulting in the one-off enumeration of midi notes?

As you write, Midi does not have a concept of designating octaves - it only describes middle c as having the note index 60. Assigning a note name or frequency is independently up to the midi generating or evaluating application/hardware.
Similarily TouchDesigner does not ascribe a note name to midi note indices but concerns itself with the raw data only. It is up to the user to interpret the value. I can see how that can lead to confusion, illustrated by using Virtual Midi Piano Keyboard and Midi View together:

Not sure how clear that is in this image but I’m hitting C4 on the piano and MidiView reports it as C3. While VPMK has a preference (“Central Octave Naming”) for the middle C, MidiView is hardcoded to C3.

So I’m unsure what to document here, we don’t assign context to midi data and hence have no ascribed note name of middle c - would that have been an already helpful statement in the docs?

Perhaps also pointing to a text like Curtis Road’s “Computer Music Tutorial” that gives a bit background via our Midi article on the docs could be beneficial:

“The usual MIDI pich range begins in the infrasonic octave with key numbers 0 to 12. This octave spans MIDI C0 or 8.17 Hz up to MIDI C1 or 16.35 Hz. Key 60 represents MIDI C5 or 261.63 Hz (MIDI middle C). In many music theory texts, middle C (261.63 HZ) is usually considered to be C4; thus the MIDI name for octaves is nonstandard. In any case, not all manufacturers confirm to the pitch-naming scheme of MIDI. Some companies call key 60 C3, C4, or C5.”

Best
Markus

[jjdeprisco]

Hey Markus,

Yes, I think a bit of all of the above.

1. Call out the +1 default. That for sure is confusing coming from a musical background.
2. Yes, call out that you “don’t assign context to midi data and hence have no ascribed note name of middle c”. But even so, we agree that TD is using the common convention that MIDI Note 60 is Middle C. So that should be clearly documented.
3. Yes, link to additional resources. Don’t link to the note chart I shared above thoigh, as that will just reinforce the confusion. Here’s another good overview:

David’s MIDI Spec

90 3C 40
Play middle C (note number 60, hexadecimal 3C) on channel 1 (the zero nibble of 90), at half the full velocity (velocity 64, hexadecimal 40).

4. I’d add to my wish list better documentation on the MIDI velocity syntax in TD. A couple more examples would be appreciated as the current blurb is somewhat vague.

My project started with wanting to generate MIDI with TD, without TDAbleton. I was not interested in sending MIDI to TD. But I knew which note range I wanted to use C2-G3 based on a previous Ableton project that was used to prototype the performance file. Live uses the C3 standard:

Ableton Live Discussion of MIDI Note Numbers

So that’s another wrinkle. My only mistake was trusting a chart that was not based on the correct reference range (C3 vs C4).

[rob]

@jjdeprisco

But even so, we agree that TD is using the common convention that MIDI Note 60 is Middle C. So that should be clearly documented.

To be clear, TD is not using that convention, so it cannot apply it anywhere.
It receives note 60, it calls it note 60, and sends note 60.
Whether the sending application informed the user in its own application, it was sending C2, C3, or C4, or even A or B is immaterial, the sending application still sent note 60, and TD received note 60.

To document that TD is using the convention that Middle C is note 60 would imply that TD would have some different behaviour if it were using the convention that Middle C is note 59 for example. It would not, as the behavior and output would be exactly the same in that case.

A TD convention would only be relevant if TD described note 60 as C2 or C3 for example somewhere in its interface. It makes no such description.

As Markus pointed out earlier, the conventions are only on apps that annotate the events with english note names, which TD does not.

Cheers

[jjdeprisco]

Rob,

I think this is one of those cases where text-based support just doesn’t cut it. I still don’t think you are getting what I am trying to say. I am not concerned with the documentation of what TD does on receiving MIDI notes.

From the start, I’ve been talking about TD MIDI Out CHOP. As in, notes generated purely inside of TD, not from anywhere else. We only took the detour to input to do the troubleshooting.

TD will output 90 3C as middle C (note number 60, hexadecimal 3C) that happens to correspond to MIDI note C4, which matters if you are interfacing with any outside device.

TD will output 90 30 (note number 48, hexadecimal 30). 48 happens to correspond to C3 (60 - 12 = 48).

This is corroborated by experiment on two systems (Mac and PC) and by the documentation I’ve linked to multiple times above.

With note numbers:

With note names:

[rob]

The thing to understand is ‘90 3C’ from TouchDesigner MIDI Out (or any other source) may be shown as C2 or C3 or C4 in MIDI View, with absolutely no change to what TouchDesigner is doing.
This is a local setting in MIDI View only.

There is no hypothetical setting in TouchDesigner, internal or user settable that controls how ‘90 3C’ would be displayed by MIDI View.

My issue is that documenting ‘TouchDesigner follows the convention that Middle C is note 60’ implies not following it would have a different effect, which is not the case.
What would be the difference?

[rob]

@jjdeprisco

TD will output 90 3C as middle C (note number 60, hexadecimal 3C) that happens to correspond to MIDI note C4, which matters if you are interfacing with any outside device.

I believe this is the source of the confusion.
The ‘C4’ interpretation is outside of TouchDesigner’s control.
In this case it is implemented by MIDIView.
It is just as feasible to use a version of MIDIView where the same ‘90 3C’ from TouchDesigner would be interpreted as C3 or C2.

This decision happens downstream from TouchDesigner.
There is nothing TouchDesigner can change in its output that would affect how ‘90 3C’ is interpreted.