As I debug the juce + traction engine code to figure out what might be going wrong here, I have made some discoveries and potentially a rabbit hole of problems that my brain currently is not capable of proposing a fix for.
Android Midi devices connect late, this is strange but ok… lets handle this scenario.
I added a timer to check when midi devices are ready and enable the midi devices and register the owning component as the midicallback listener.
Now when this happens, I get the midi messages routed all the way to my android app and everything seems to be working ok, till I try to get the midi notes to actually play back when I am in a Oscillator (FourOSC) or Custom Step Sequencer.
The midi events are coming through but they are not converted and sent to the synthesiser to actually play the sounds.
Whist I was debugging this with many break points all over the code, there were a couple occasions where the midi input would play, but I still don’t know what I managed to do to allow that to happen.
This to me indicates that there is some sort of timing issue.
If there is something that I can debug and put breakpoints in my app that will help me diagnose this further I would appreciate the help getting this information so I can stop pulling my hair out.
Thank you in advance!
I’m not quite sure what the problem is here? Engine is designed for MIDI input to come and go as devices get plugged in etc. Once they’re available to the OS you should just need to call
te::DeviceManager::rescanMidiDeviceList (false), then you can get the
InputDeviceInstance for a specific
te::EditPlaybackContext::getInputFor (InputDevice*) and then assign it to a Track?
Have you looked at the Demos for this? E.g. the MidiRecording demo?
@dave96 Thank you for the reply!
So yeah, I did try the te::DeviceManager::rescanMidiDeviceList (false) to make sure the devices get opened and added to the respective callback handlers.
I ran into a problem doing that though. We have a MidiCommandManager that manages some custom midi commands and our app needs to handle these in custom ways. I stop receiving callbacks here because once the device is opened the midi handler now routes messages directly to the midi input devices’ handleIncomingMidiMessages but the AudioDeviceManager is left out of this.
I have infact looked at the MidiRecordingDemo and had questions about the code in createTracksAndAssignInputs
What is the correct way to reassign these as midi devices change during execution of the process.
The call in the MidiRecording demo to createTracksAndAssignInputs is called on init of the demo but not really when devices change.
Also is there a callback in the engine right now to know when the devices are available to the OS? Or are we going to have to do the scan and find differences of current devices?
I have tried to reinitialize my inputs on my tracks but I think I see the core problems,
Once a mididevice is open the callback handler in tracktion engine sets the device to use the PhysicalMidiInputDevice::handleIncomingMidiMessage, this is correct, but the problem which I am currently running into is that the juce::AudioDeviceManager is left out of these callbacks and any other subsystem listening to these messages are completely ignored.
The juce_android_midi forwards these midi messaged to the MidiDataContatinator which only sends it to the PhysicaMidiInputDevice and not back to the AudioDeviceManager. Hope this makes sense.
How do I now go about getting the midi message routed back to the audio device manager or to a custom manager that wants to process midi messages in a different way