I’ve run into an issue where I’m getting “” returned for the MIDI input and output port names. Interestingly, this seems to occur about 50% of the time after another button on the GUI is clicked. To elaborate, I start the program, click any button on the GUI, then select the MIDI I/O ports and “” is shown for the port names. This occurs even if the handler for the button being clicked is empty. If I start the program and immediately select the MIDI I/O ports it work 100% of the time.
From what I understand, “” is returned when the name of the port can’t be determined, however, I’m not sure what would cause that to happen under these circumstances. Any thoughts as to what might be going on?
You’re definitely on the wrong trail if you think clicking the mouse is somehow affecting on the midi devices - there no way that could be related. Maybe your drivers can only have one instance of a device open simultaneously, and you’re trying to sometimes open more than one?
Actually, I’m noticing the in my list of midi devices too, less than 50% of the time and Im not seeing a correlation with buttons and such. Although I open only one MidiOut device at a time , Im wondering if might be the result of me using a subclass of MidiOutput (InternalSynthPort ) whose singleton instance has a sendMessageNow() to route messages to an internal synth (Apple’s DLSMusicDevice) eg:
Output to the internals synth has been quite reliable but as the previous poster commented, once in a while the devices returned by juce::MidiOutput::getDevices() in my output menu have in place of the “IAC Driver Bus 1” that should be there. It seemed from the documentation that one should be able to subclass MidiOutput but now I suspect I’m going about this the wrong way: I create my internal port instance one time and it always appears in the 0th position of my midi out menu and the normal juce::getDevices() are listed above it . I want users to be able choose between the juce::MidiOut devices and the always-available internal synth.) Any hints at what I’m doing wrong would be appreciated! Perhaps the right way would be to make a name appear in the menu but to not acutually use a MidiOutput to connect to it (?)
best,
Rick Taube
Assoc. Prof. Composition/Theory
Chair, Composition/Theory Division
School of Music
University of Illinois at Urbana-Champaign
Net: taube@illinois.edu
Fax: 1 217 244 7767
Vox: 1 217 244 2684
Not really sure what could be going on there… It’d be worth having a quick step-through of the code in CoreMidiHelpers::findDevices(), because that’s the only place where the “” string appears. Looks to me like the OS would have to be stonewalling the requests for midi devices for it to end up with that error, but I don’t know what might make it do that. Stepping through might provide a clue.
OK to make things simple I removed my code that created a subclass of MidiOutput to see if subclassing is the problem. So now only devices returned by juce::MidiOutput::getDevices() are ever opened and only one is open at a time.
I still get the listing apearing in the getDevices() array from time to time in place of “IAC Driver Bus 1”, and I cant find any obvious trigger for it happening. Once the appears, the true name never comes back, although if I look at busses in other apps (SimpleSynth for example) the name “IAC Driver Bus 1” sill appears in their device menu (but that does not mean much…)
Im stumped, im only using devices created by juce::MidiOutput::OpenDevice() and only one is open at any given time. This code was rock solid for years, and im not sure what is causing the issue.
apologies but I’ve only had moments over the past 5 days to work on the app and what time Ive had I’ve been pruning code back to try to locate what is triggering the problem. At this point im not opening any midi output devices and im not loading a midi plugin. all that’s happening now is that the command manager/menubar is calling MidiOutput::getDevices() to populate a device submenu
I know that juce::MidiOuput::findDevices usually detects Apple’s “IAC Application Bus 1” and that when it fails MidiOutput::findDevices does have a non-null MIDIEndpointRef, but that ref has an empty name which then gets set to “”
Furthermore, when happens this message is printed in my syslog.d after about a .5 sec lag:
so apparently something is triggering the MIDISever to crash and restart (!?)
Also, other apps – such as SimpleSynth and Juce Demo – continue to show the name “IAC Application Bus 1” after appears in the menay and although its still in my app. One last things: it seems that if other devices are available (For example SimpleSynth’s Input port) then I cant trigger the problem to happen (i cant really sure about this yet, but ive started the app dozens of times without producing .)
I’ll try to figure out how to step through findDevices() in Xcode – that’ll probably take me a day or two since I usually work in the terminal and my gdb chops are pretty weak.
thanks,
Rick Taube
Assoc. Prof. Composition/Theory
Chair, Composition/Theory Division
School of Music
University of Illinois at Urbana-Champaign
Net: taube@illinois.edu
Fax: 1 217 244 7767
Vox: 1 217 244 2684
Jules I am able to trigger the midi out device in the juce demo, so its either my machine or its simply not the way to do things. Its somewhat random but it seems to involve swapping between applications. Basically if you call MidiOutput::getDevices under menu filling code (ie, as if you were going to fill menu items with avaliable output devices) or commandInfo code and then alternate clicking between the juce demo app and other apps and then mousing on the “Demo” menu item back in the demo app it might happen for you. I have the Mac menu style selected, i dont know if this is the issue or not. the error does not seem to happen if you have more than the “IAC Applicatino Bus 1” available as an output device, or if you actually open an output device. im not really sure if thats true because its intermittent. Once the error happens the Looking in the Output devices combo box in the Demo’s Audio Setting pane will list the device in place of the IAC applicaiton bus.
// This method is used when something needs to find out the details about one of the commands
// that this object can perform..
void getCommandInfo (CommandID commandID, ApplicationCommandInfo& result)
{
const String generalCategory ("General");
const String demosCategory ("Demos");
// PRINT ERROR
StringArray devs = MidiOutput::getDevices();
if(devs.contains("<error>"))
std::cout << "MidiOutput::getDevices() contains <error>\n";
im trying keep my output device submenu current and avoid modal dialogs with lists of devices to open things. Ive also tried updating a device menu list manually through a “Look for new devices” command but that did stop the problem from eventually happening either.
Is there some way you could trace through getConnectedEndpointName() when it happens, and see where it fails? Or add some debug logging to it to see what happens? There’s an OSErr in there too, which might contain a value that would give a clue about the problem.
But it does sound like a CoreMidi bug to me - there’s nothing I can see in the code that looks in at all dodgy.
