I need to generate MIDI events and send the via a hardware MIDI Device (not to the host) as fast as possible everytime a parameter is changed in the AudioProcessor. Now i created a seperate MIDI Thread for that, that copies events from my classes on events and sends them out (like the MidiOut class does), and it works however it’s not as accurate as i’d wanted. Is it a bad idea to generate the same events in the AudioThread, actually using MidiOutput::sendMessageNow() in that thread, will it cause a lot of problems with hosts ? I know that MIDI is a serial interface and thus not very fast, but does the OS buffer those messages and does not wait for the messages to actually be sent on the wire ?
Also i wanted to ask if allocating a midi messages via new/malloc in the audio thread is a bad idea, i know that memory allocations there will cause problems but
- theese are small amounts of memory (a midi message is usually not bigger then 12bytes)
- i’m not doing ANY audio processing in the thread
Another aspect of this is, i have 3 sources of events that generate MIDI messages each come from a different thread (a MIDI Input event, the HOST changing the parameter, the GUI when something gets changed by the user) i was wondering if someone has and idea how to process those 3 event source, do i create 3 threads for each source and share the MIDI OUTPUT device between them, or is one thread that talks to those 3 sources (with locking) better.
Is locking needed when one thread only reads an integer and one only writes it ? (the audio thread set’s the value of a int and the GUI thread only reads it in handleAsyncUpdate()) do i need to do ScopedReadLock and ScopedWriteLock when that int is accessed by those threads ?