MidiInput buffer overflow

jassertfalse; // midi buffer overflow! You might need to increase the size..

this happens on windows, with a lot of NRPN messaes (Alesis Micron), how can i increase that size in my code, is MidiConstants somehow available through some interface ?

That’s pretty old code - I think I need to beef it up a bit to use a MidiBuffer instead of a fixed-size buffer.

well i hard coded a bigger buffer, but it would be nice to have this as a setting in the MidiInput class.

Also a request, all (or most) modern midi enabled hardware uses NRPN/RPN messages, it would be nice to have support for this in MidiBuffer and MidiMessage classes, i created my own MidiMessageEx class that handles this, and has a special collect() method to capture theese messages (it’s 4 or 2 messages depending on running status). It’s simple and very useful, i’m expecting more midi implementations with theese messages in the future, cause they give a bigger resolution.

I’ve recoded this now, so there shouldn’t be a limit any more, but I don’t have any midi gear set up to test it, so would appreciate if you could give it a spin!

no problem, will test it this afternoon.

looks better, didn’t hit that assertion once and i was going crazy on the knobs.

how about that NRPN/RPN thingy, think you can squeeze something in ?

I don’t really have time to research it… Can you give me a detailed description of what it needs to do?

There are 4 types:
RPNs (less common) - http://www.blitter.com/~russtopia/MIDI/~jglatt/tech/midispec/rpn.htm
NRPNs (more common) - http://www.blitter.com/~russtopia/MIDI/~jglatt/tech/midispec/nrpn.htm
both also exist in RUNNING STATE, but this state depends on previous NRPN/RPN messages received/sent, in running state you send 2 messages that just set the value, the controller number is taken from the previous message, this way sending a lot of changes for the same NRPN/RPN number takes less data on the wire.

There is a 3rd type that i foumd used by Korg and some Novation synths, it’s actually 3 messages but it’s really rare.

Also for sysex messages there is a lot of bit/byte mangling, perhaps there could be a few methods to directly access/change byte values in a message, without using getRawData from the MidiMessage.

Those NRPN/RPN messages are always sent/received in the same order, 0x65,0x64,0x26,0x06 and those 4CCs create one NRPN message, with 14 bit number and 14 bit value (high resolution midi). I guess it would be nice to have those in midi message class and perhaps a simple getMidiBuffer() method for retrieving one instance of MidiBuffer with 4 messages if the MidiMessage is holding a NRPN/RPN message.

All new DSI synths (Mopho, Tetra, Prophet08) use NRPNs, also Alesis ION/Micron, AKAI Miniak.

Moog/MFB uses a variation of this, they actually arbitary CC pairs with different numbers to achieve the same thing (different company different idea).

I’ve been implementing all this in my ctrlr project, this is how much i got so far: http://code.google.com/p/ctrlr/source/browse/#svn/trunk/Ctrlrs

Ok. There’s already a MidiMessage::controllerEvent method that you could use to create the 0xb0 messages, but I’m not really sure what would be a good way of dealing with these multiple message sequences… Do you think it’d be better to have a method in the MidiMessage class that initialises several MidiMessage objects, or maybe a method for the MidiBuffer class to add a series of these things to the buffer?

well it depends really, i think it would be better to have this inside MidiMessage in terms of object programming and manipulatig that object. Also the getControllerNumber() and other methods should do exactly that but on the whole NRPN message.

What i use is here

i know it’s not good code but it works for now. It’s a work in progress, with every new synth/device i change that class to fit some other situations.

Yeah… Hmm. It’s a tricky one.

It feels like you’re cramming too much into that class - maybe there should be a bunch of classes, e.g. one called NRPNMidiMessage that wraps a MidiBuffer and is specifically for handling and recognising that particular kind of message?

Well i need one clas, cause i have a layer of modulators that need to send/receive all kinds of messages.

The tricky stuff is the input, you need to catch those 4 messages and put them together. I think the MidiMessage class is OK for this, i’d just add more set…() methods (set controller number, value) instead of static members.

Also why not MidiBuffer - well, I tried using the MidiMessageCollector class, but it’s not possible in my case, i’m not using any audio, and the whole class depends on samplerate settings, and i’m doing pure midi stuff. So i had to create my own collector class and my own MidiMessageEx class, and believe it or not it’s just 4 types of messages in that class NRPN/RPN[NRPNRunning/RPNRunning]/SysEx/CCPair the rest is handled by MidiMessage witch is simply the first element of the container.

I don’t have this much experience as you so i’ll go for anything you propose, there is not a lot of those multi messages so i guess each can have it’s own class.

Sorry, I’ve been juggling 10 other things and haven’t had time to think about this…

I do think a better design would be to break the task down into smaller classes. If there were simple classes like I suggested that could create and recognise each different types of message, those might be something I could add to the library, and you could keep your MidiMessageEx class, but replace all of its innards with calls to those classes, rather than dealing with the raw data directly. Afraid I’m too busy to write the classes for you right now, but will work with you if you want to have a go at starting them off!

Whenever you have some time, i’m working on this project fulltime right now anyway, i’ll try to write something for the NRPN using your MidiMessage/MidiBuffer class as a template.

I’ve been doing some work with the MidiInput, and i notices i’m not getting all the data in my SysEx messages, i need a 264byte message, JUCE gives me maximum 256 (looks like maybe to 128buffers or one 256byte buffer), but there is 8 bytes more to complete the message, and they don’t appear on the input, i have a DBG statement:

void EdoMidiDeviceManager::handleIncomingMidiMessage (MidiInput* source, const MidiMessage& message)
	DBG (T("EdoMidiDeviceManager::handleIncomingMidiMessage: size=")+String(message.getRawDataSize()));

and i keep getting

EdoMidiDeviceManager::handleIncomingMidiMessage: size=256

when midi-ox shows 264 for the same message.

The win32 code receives data in 256 byte blocks, but I don’t think I ever added logic to join the blocks together if a long message had been split across multiple blocks…

that’s very weird, a complete sysex starts with F7 and ends with F0 so anything in between that’s not a 3byte standard message is part of this sysex, plus i think windows makes this calls so that it’s obvious when it’s a partial sysex and when it’s a midi message of other kind.

It’s necessary for a good working midi implementation.

I agree! Just never got around to it. Strange that nobody else spotted it until now! I did implement some logic to do it on the mac, so I guess I could copy that.

well this is the part of the music world that noone seems to care about and for me is a godsend for all those music boxes that have no knobs or sliders, just a bunch of plastic crappy buttons, that make you wanna kill yourself when going through all the menus, sub menus, sub-sub menus.

I had to cope with that problem and I did post it to the forum some weeks ago…
Jules , you may remember when I’ve ask about the missing implementation of partial sysex messages in Windows.
I wrote my own code to get arround the problem but would like to see a proper implementation.