![]() Void getCommandInfo (CommandID commandID, ApplicationCommandInfo& result)Ĭonst String generalCategory ("General") ![]() This method is used when something needs to find out the details about one of the commands 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. im not really sure if thats true because its intermittent. 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. I have the Mac menu style selected, i dont know if this is the issue or not. 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. Its somewhat random but it seems to involve swapping between applications. 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. 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. 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. So apparently something is triggering the MIDISever to crash and restart (!?)Īlso, 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. 5 sec lag: Jul 22 15:46:34 Ricks-MacBook-Pro.local MIDIServer: MIDIServer starting arch=x86_64 ![]() 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 “”įurthermore, when happens this message is printed in my syslog.d after about a. all that’s happening now is that the command manager/menubar is calling MidiOutput::getDevices() to populate a device submenu At this point im not opening any midi output devices and im not loading a midi plugin. University of Illinois at Urbana-ChampaignĪpologies 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. 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 (?) 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. 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. Void InternalSynthPort::sendMessageNow(const juce::MidiMessage &message)ĪudioManager::getInstance()->sendMessageToPluginGraph(message) 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: 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.
0 Comments
Leave a Reply. |