More fun with MIDI

[Doc Joe]

Hi again folks. The NDLR controller is coming along well.

However, I have tricky situation. There are times when the NDLR module generates many MIDI event in rapid succession. For example, when I wish to reset the NDRL to a known state, I need to send out 10 different MIDI events. I am currently spending these by using the AddMessage() function of the MIDI output jack. However, when executives in rapid succession, the first events are not sent, while the most recent one fires.

From the MIDI Lite example, I suspect I need to construct an array and process all at once. However, I am not sure where in the code I need to then processes this array, and how to do it.

Any help would be appreciated.

Cheers,
Joe

[Doc Joe]

Here's videos of the modules in action:
Overview of the module design - https://youtu.be/fdZu5tW1woQ
Testing in Voltage - https://youtu.be/d-1Q1lia-Jg

[ColinP]

This sounds odd. I use VoltageMidiJack::AddMessage() to send multiple MIDI messages per call of ProcessSample() in several Adroit modules and haven't encountered any problems so far. The use of the word "add" rather than "send" also strongly implies that the method is adding the messages to a queue.

It's bad practice to have arbitrary size limits in data structures, so even if you are sending hundreds of messages at once I would be surprised if the API couldn't cope.

The MIDI Light sample code is handling MIDI input and yes to do that one needs to handle each event in the input queue one by one, but for output you should be able to just make multiple calls to AddMessage().

[Doc Joe]

Thanks Colin,

I thought as much as this. The AddMessage property certainly looks to be adding a midi event (ShortMessage) to an array within the midi jack component. You've confirmed my suspicions that the midi signals are sent and cleared during the ProcessSample() phase, even though I am not explicitly adding the midi events within that process.

Here is my code...

// ----------- custom functions

// send midi signals
public void SendMidi( int mcode, int mrange)
{
try {
myMsg.setMessage( ShortMessage.CONTROL_CHANGE, midi_channel, mcode, mrange);
midiOutputJack.AddMessage( myMsg);

}
catch (InvalidMidiDataException e)
{
// report the error to a textLabel on the control
// ConsolLabel.SetText( e.toString() );
}
//
}

// protect against bad values
public int MinMaxProtection( int mrange, int mmin, int mmax)
{
int mreturn = mrange;
if (mrange < mmin ) { mreturn = mmin;}
if (mrange > mmax ) { mreturn = mmax;}
return mreturn;
}



// track toggles
public void PadOn( boolean bIsOn )
{
if (bIsOn)
{ SendMidi( 85, 64); }
else
{ SendMidi( 85, 1) ; }
}
public void DroneOn( boolean bIsOn)
{
if (bIsOn)
{ SendMidi( 86, 64); }
else
{ SendMidi( 86, 1) ; }
}
public void Motif1On( boolean bIsOn )
{
if (bIsOn)
{ SendMidi( 87, 64); }
else
{ SendMidi( 87, 1) ; }
}
public void Motif2On( boolean bIsOn)
{
if (bIsOn)
{ SendMidi( 88, 64); }
else
{ SendMidi( 88, 1) ; }
}



// in this code, only the Motif1On(flase); midi signal is sent. <<<<< THE PROBLEM

public void Reinit()
{
padToggleSwitch.SetValue(0); PadOn(false);
droneToggleSwitch.SetValue(0); DroneOn(false);
mot1ToggleSwitch.SetValue(0); Motif1On(false);
mot2ToggleSwitch.SetValue(0); Motif1On(false);

}

[ColinP]

In the code you posted there's a double call of Motif1On(false) right at the end which I'm guessing is not what you intended.

That might be worth investigating, but the thing that draws my attention is the use of VoltageToggle::SetValue().

One important thing to note about this is that not only will it disengage the toggle switch, it will also add a Button_Changed event into the event queue feeding Notify().

This might not be something you anticipated so check your handling of Button_Changed in Notify(). It needs to check doubleValue and only activate any button press operations if it's 1.0.

Your bug could be caused, not by MIDI messages going missing, but by your code accidentally sending extra CC messages to turn back on what you have just turned off. If you see what I mean.

[Doc Joe]

Solved!

Turns out I had made a rookie mistake regarding how arrays are handled in Java.

I was using a public ShortMessage varible to set all of the midi events. The array was storing a pointer to this variable, not new copies each time the SetMidi was called. Doh! Thus, when the mini output was actually processes, it was sending the same data repeatedly.

The solution was simple: create a new ShortMessage variable within the try function, and associate that to the AddMessage() function.

Solved! Yah. My life got better.

A big thank you to the folks who helped out.

Best regards,
Joe

[Doc Joe]

Ooooh... one more thing. The maximum number of midi events that can be added to the array is 10.
Checking with the folks at Cherry Audio - Is that correct?