Aloha,
My FM7 softsynth is not allowing the plugin host demo to connect its midi connection after loading a filtergraph document. I start off with a new graph then add the fm7 and then add a connection between the graphs ‘midi input’ and the fm7. Then I save the file to disk.
When I reload the filtergraph the midi connection is not restored. When I trace into the code I see that the plugin is returning false from acceptsMidi(), thus the graph notices that it should not allow the connection. But when I re-add the connection the trace indicates the synth is now reporting true from acceptsMidi. So, the synth isn’t ready yet at the time the connections are being restored. I tried tracing around the vstplugin initialization for awhile but was unable as of this time to determine when acceptsMidi becomes true…All my other midi widgets connection themselves properly except the fm7.
Does anybody know how I might delay, or listen to the graph such that I give the plugins time to completely initialize? I suspect that the plugins are loading asynchronously to the gui yes? - Can anybody shed some light on this issue?
Thanks,
Kurt
Be aware that both the FM7 and B4 soft synths from native instruments are exhibiting the late notification of acceptsMidi() issue. Still unresolved. I have to do something about this. When I figure it out I’ll send another update.
Well…I’ve achieved the objective by hacking AudioProcessorGraph’s canConnect and removeIllegalConnection methods such that they examine the name of the ‘dest’ filter and when they detect one of the plugins I know exhibits this problem then I force it to ‘acceptMidi’.
If you look at those methods you’ll see where it calls ‘dest->processor->acceptsMidi()’. Wherever I saw that I substituted for a boolean ‘wantsMidi’ that I jammed into the correct state for one of the problematic soft synths. Thus I am forcing the connection even when one of the problem synths isn’t yet ready to acceptMidi. I suspect I’ll get bitten here in the future however for now at least my graphs reconnect when loaded.
If you too suffer from this problem I’d strongly suggest NOT modifying the implementation of acceptsMidi() by checking the processor name within due to the fact that acceptsMidi() is used by time critical operations deep down in the heart of audio rendering land. It would be a bad idea to slow it down.
