that was my point... I was offering to add it... and wanted to check to see if the approach had worked ok.
(i.e. no point in me adding it, if it didnt work very we'll, e.g. unacceptable latency )
Im not quite sure I understand what you mean there...
we only currently allow one 'connection' for each type... device, din and usb host.
the limitations i see are only in the host implementations and are:
a) we don't support USB hubs... so that means its obviously impossible to connect multiple usb midi devices.
b) we don't expose the name of the device/port connected.... rather just call it usb_host , port 1, usb_host port 2.
usb hub, is probably quite a lot of work, but definitely on the 'wish list'.
as for the usb mid spec exposing multiple devices, yes, it does this via what Ive called 'ports' but in the spec are referred to as cables. (up to 15, I only show 4... to keep it simple). I used this for Push and also a 2 cable usb to DIN cable I have.
I added these connection/ports to all midi output objects, originally I added them to the input as well, but johannes correctly pointed out, this could lead to user confusion if they were set incorrectly and also really cluttered the patcher, so I moved the connection/port filtering to the subpatch level, this kind of makes sense, as its where we tend to put voices. (for polyphony)
or do you mean something else?
sysex output , is actually 'supported' but only in the C api, and its unlikely to change since producing sysex in the patcher would be cumbersome, especially without allocating large buffers. there are some limitations on the 'speed' this can be sent, so that again we dont have to allocate an enormous buffer.
(i.e. it works for normal sysex, but wont probably work for downloading samples etc to device)
sysex input, again, we could add to the input side in C, but process in the patcher is probably not realistic, the problem is, potentially the incoming data could be enormous, too big for us to realistically reserve space for.. what makes it worst, is you dont know how many bytes are expected... so you have to process byte by byte, which is why I think its only realistic to do this in C, and not the patcher.
I guess initially Id like to have support for small control type sysex messages... as these are pretty common.
(also better support for NRPN/RPN would be cool, though you can actually process these already with cc and 14 bit cc objects)