Array Format for Sending CC Messages Using .send()

[ScottStick]

Hi Everyone!

I'm hoping someone may be able to confirm for me the correct array structure and content for sending CC messages using the

output.send(...)

method, rather than the

Output.channels[ ].sendControlChange(...)

method.
The software I'm working on receives data messages as 3-integer arrays, such as [176, 9, 64], to conform to [status byte, data byte 1, data byte 2]. The status byte 176 (10110000) represents 1011 - Control Change and 0000 - MIDI channel 1, given that MIDI 1.0 messages represent MIDI channels 1-16 as 0000-1111, i.e., 0-15. Therefore, first up, which is the correct syntax for sending the above array data as a CC message:

1. Output.send([176, 9, 64])
2. Output.send([177, 9, 64])
3. Output.send(176, 9, 64)
4. Output.send(177, 9, 64)
5. Output.send(176, [9, 64])
6. Output.send(177, [9, 64])?

Or is it something else that I haven't thought of yet? Whatever the correct format is, will it give me the same result as using

Output.channels[1].sendControlChange(9, 64)?

Sorry if I'm duplicating a question already asked and for the long-winded explanation. For the life of me, I couldn't find the detail I'm after on the website. Any and all help is hugely appreciated and gratefully received.

[djipco]

If you look at the documentation for the Output.send() method, you will see that it can accept, as its first argument, an array of numbers, a Uint8Array or a Message object. If we go with the array, the syntax would be something similar to this:

WebMidi.outputs[0].send([176, 9, 64]);

[ScottStick]

Thank you for responding so quickly and providing a succinct answer. Thanks, too, for the link to the documentation - brilliant!

[ScottStick]

My apologies, I'm still encountering some difficulty with the WebMidi.outputs.send function in my ReactJS app. I can create 2 WebMidi MIDI port objects by selecting them from a populated select box of all available input and output devices and triggering onselect events:

let inports = [];
let outports = [];
var inputs = midiAccess.inputs;
var outputs = midiAccess.outputs;
var midiDataArray = [];

inputs.forEach(port => {
 var inport = port.name;
 inports.push({ label: inport, value: inport });
});

outputs.forEach(port => {
 var outport = port.name;
 outports.push({ label: outport, value: outport });
});

const chooseMyInPort = event => {
 const index = inports.map(item => item.value).indexOf(event.target.value);
 const myInPort = WebMidi.inputs[index];
 mInPort.addListener('midimessage', 'all',
   e => {
     midiDataArray = e.data;  // [x, y, z]
     sendMidiDataArray(midiDataArray);
 });
};

const chooseMyOutPort = event => {
 const index = outports.map(item => item.value).indexOf(event.target.value);
 const myOutPort = WebMidi.outputs[index];
};

So far, so good. However, for some unknown reason, sending the midiDataArray array, despite being in the format [x, y, z] and all are valid integers, such as those in my previous example (x = 176, y = 9, z = 64), doesn't appear to work:

const sendMidiDataArray = dataArray => {
  if (dataArray.length !== 0 || dataArray !== null || dataArray !== undefined) {
    myOutPort.send(dataArray);
  } else {
    console.log('There's something wrong with the data array:', dataArray);
  }
};

myOutPort.send( ) does not send a MIDI message, does not trigger an error, does not break the code, nor do I get the console message. It doesn't do anything. Most likely, I'm missing something really obvious that I just can't see. If myOutPort = WebMidi.outputs[2] and midiDataArray = [176, 9, 64], for the sake of the argument, I don't understand why myOutPort.send(midiDataArray) does not work.

myInPort works as expected, but myOutPort doesn't. 😥

[djipco]

On line 3, is there a specific reason for using midiAccess.inputs instead of WebMidi.inputs? Those are not the same thing. The first most likely contains MIDIInput objects from the bare Web MIDI API while the latter contains actual WEBMIDI.js Input objects.

Unless you understand how the browser-bundled Web MIDI API relates to the WEBMIDI.js library, you are probably better off only using the objects from the library.

Did you check the Basics section of the documentation? That would be the best place to start.

P.S. As far as I can tell, the reason your code does not work is because of variable scoping. The constant myOutPort is not defined in the scope where it is used (unless we are missing parts of the code). By contrast, myInPort is being used in the same scope as the one its declared in and that's why it's working.

[ScottStick]

Hi Jean-Philippe,

Thanks again for your speedy reply. You were correct in suspecting there was missing code, so there's no scoping issues. I double checked and both ports are definitely WebMidi objects. The midiAccess.inputs code is a hangover from a previous version of the app. It's only function is to populate select boxes and get the indices of the selected ports, which are then used to create the WebMidi.inputs[index] and WebMidi.outputs[index] objects. I do agree, though, that it's sloppy and could cause confusion changing between the Web Midi and WEBMIDI.js paradigms. In fact, I'm specifically creating the new app version to replace its use of the Web MIDI API with your API.

Strangely enough, I swapped WEBMIDI.js flavours from IIFE to ESM using npm and importing WebMidi, and changed the midiAccess lines to WebMidi. As soon as I did, the myOutPort.send(dataArray) call executed the function as intended, as did other send methods (.sendSysex(), .sendTimecodeQuarterFrame(), .sendSongPosition(), etc.). Not having to keep looking up the various status byte numbers makes life soooo much easier.

In case you're interested, this gives you some background on what I'm using it for:
https://www.aes.org/e-lib/browse.cfm?elib=21110

Thanks for all your assistance.

Scott.

[djipco]

I'm glad you got it working.

I checked the provided link and your project seems quite promising. Seeing as you are an academic, you might be interested in a paper I wrote about WEBMIDI.js called: User-Friendly MIDI in the Web Browser. It was published by the NIME conference in 2022.