anyere Therefore i have to send the clock midi message (decimal 248, hex 0xF8) but so far I havent seen any realtime capabilities in the midi library.
You can use send any midi message with
int Midi::writeOutput(midi_byte_t* bytes, unsigned int length), as it takes raw bytes, whereas
int Midi::writeMessage(midi_byte_t statusCode, midi_byte_t channel, midi_byte_t dataByte), is designed for channel messages.
In terms of receiving sysrealtime, that is implemented, although a bit hacky at the moment. Again, if you receive raw bytes and parse them yourself, you'll be fine, however if you are using Bela's
MidiParser, this only handles
sysrealtime of all the System messages, and it does so pretending it is a channel message with no data bytes, so you'd have to re-assemble the original status byte, as exemplified here:
// currently Bela only handles sysrealtime, and it does so pretending it is a channel message with no data bytes, so we have to re-assemble the status byte
int channel = message.getChannel();
int status = message.getStatusByte();
int byte = channel | status;
anyere And since they are realtime messeges should I send them from the render thread or via a lower priority axillary task?
writeOutput can be done from the audio thread. It sends a message to a real-time safe queue which is then processed in another (non-realtime) thread (which runs the
writeOutputLoop() function). This approach is optimal to ensure that sending MIDI messages does not disrupt the audio, however, especially under heavy CPU load, it may result in outgoing MIDI messages to be a bit jittery, so it is worth giving it a try, and seeing if you achieve good enough results.
lokki if in the end you want to control hardware devices you might be better off sending the clock info out via serial instead of usb.
That by itself would not guarantee lower jitter, unless the whole implementation for writing to the serial port would also be Xenomai-safe, and my guess would be that it is not worth the hassle.