Utility method for MidiMessage

General JUCE discussion
1

something like

bool isRPN();      /* or maybe isPartOfRPN(); */
bool inNRPN();    /* or maybe isPartOfNRPN(); */

and something like for MidiMessage static methods

rpnEvent (const int channel, const int controllerType, const int value) throw ()
nrpnEvent (const int channel, const int controllerType, const int value) throw ()

BUT this has to return a MidiBuffer, cause RPN and NRPN are acutally 4 messages.

here is how i make RPN

		MidiBuffer midiBuf;
	
		BitArray ctrlrNumber; /* this is the controller number 1-16383 */
		BitArray ctrlrValue;    /* controller value same range */
			
		int ctrlrNumberLsb = ctrlrNumber.getBitRangeAsInt (0,6);
		int ctrlrNumberMsb = ctrlrNumber.getBitRangeAsInt (7,13);
			
		int ctrlrValueLsb = ctrlrValue.getBitRangeAsInt (0,6);
		int ctrlrValueMsb = ctrlrValue.getBitRangeAsInt (7,13);
	
		int firstByte = 0xb0;
	
		MidiMessage msg (firstByte, 99, ctrlrNumberLsb);
		midiBuf.addEvent (msg,0);
	
		msg = MidiMessage(firstByte, 98, ctrlrNumberMsb);
		midiBuf.addEvent (msg,1);

		msg = MidiMessage(firstByte, 6, ctrlrValueLsb);
		midiBuf.addEvent (msg,2);
	
		msg = MidiMessage(firstByte, 38, ctrlrValueMsb);
		midiBuf.addEvent (msg,3);

here is how i make NRPN

		MidiBuffer midiBuf;
	
		BitArray ctrlrNumber; /* this is the controller number 1-16383 */
		BitArray ctrlrValue;    /* controller value same range */
		
		int ctrlrNumberLsb = ctrlrNumber.getBitRangeAsInt (0,6);
		int ctrlrNumberMsb = ctrlrNumber.getBitRangeAsInt (7,13);
		
		int ctrlrValueLsb = ctrlrValue.getBitRangeAsInt (0,6);
		int ctrlrValueMsb = ctrlrValue.getBitRangeAsInt (7,13);
	
		int firstByte = 0xb0;
	
		MidiMessage msg (firstByte, 101, ctrlrNumberLsb);
		midiBuf.addEvent (msg,0);
	
		msg = MidiMessage(firstByte, 100, ctrlrNumberMsb);
		midiBuf.addEvent (msg,1);

		msg = MidiMessage(firstByte, 6, ctrlrValueLsb);
		midiBuf.addEvent (msg,2);

		msg = MidiMessage(firstByte, 38, ctrlrValueMsb);
		midiBuf.addEvent (msg,3);
2

Yeah, not sure if that’s the right approach to parsing them, it’s more a case of scanning a midi stream and picking them up as they go by. Not really sure what would be a good set of methods to work with them…

3

yeah in a continues midi stream when searching for them you need to scan, but creating them is fairly simple. anyway i thought that would be a nice thing to complete juce’s midi implementation

4

Really old thread, but it looks like none of this made it into the code base?

Bruce

5

Can’t remember. Are you sure it’s not there with a different name?

6

No, I don’t see it anywhere. If you recall, they are odd messages, as they consist of a number of other standard messages in a defined sequence. Since the pieces of a full message could span two callbacks, I think decoding probably has to be done in the receiver.

As long as everyone is smart enough to steer clear of using the ‘special’ Control Change numbers, then just using some flags should be workable.

Do you recall what happens if callbacks end up splitting a long message? Does the rest of the message come almost immediately, or is there polling or buffering in the way?

Bruce

7

I really don’t know or remember… Atom started this thread, maybe he can shed some light?

8

There is no utility for MULTI messages in the MidiMessage class i checked.
So far i had no problems with NRPNs in terms of queueing by the driver, but sometimes realtime messages get between a NRPN message (midi clock etc.) so you need to check for those.