Hmmm. I looked at the BandHelper tutorials, and I see that it runs as an IAA, not AUv3. That means it has direct access to CoreMIDI. It can see all the connected MIDI devices. And so, what you do in MidiFire does not limit exactly what it can see, or what it sends. The key question is how is the BandHelper MIDI configured?
What ports does it use, what MIDI channels?
Is it configured to send MIDI Clock? What ports does it send to? Clock is tricky because it doesn't have a channel. So, if you send Clock out the UM1, it will be heard by everythng connected to that output.
Do you need MIDI Clock inside MidiFire? I remember that you were counting clocks to trigger lights.
What MIDI controller are you using? How is it connected?
If BandHelper offers Virtual MIDI ports, ones named BandHelper in the MidiFire input and output menus, they would be the best ones to use for communicating with the app. If you use them, they will be described differently inside BandHelper, maybe "Virtual Port", "MIDI Bridge", "BandHelper port", or some such. You would not use the ports named "MidiFire" in that case, because they are different.
Could you maybe post the BandHelper MIDI configuration screens so we can inderstand the best way to interface with the other parts?
Hi Dave this is a great start to understanding how the apps communicate together
It's more simple with the iPad I'm using in this case.
The iPad for this application is only needing program messages on ch1 to change songs on the song list in band helper for the drummer to view.
The master iPad and midi controller I use have it's own iOS device and um1 midi interface.
I will try sending you through some screen shots of menus in the remote control section of BandHelper. The input remote control midi port options are ALL, NETWORK, MIDIFIRE, UM1. And band helper is Ofcourse set to midi thru ON so midi clock can pass through on the um 1 input into band helper and out of band helper via the um1 - which will arrive at the drummers module JUST with midi clock only (No other midi messages) as I would like them blocked with midi fire
BandHelper on this particular iOS device and um1 is meant to be reading program changes from another iPad upstream due to band helper 'send midi' feature on song selection.
Due to other midi messages that are happening ever further upstream from the midi controller and Midifire conversion there are many messages being processed and flowing all the way down stream to the drum module and drummers iOS device with its own um1, BandHelper and Midifire options.
The whole reason I want all midi blocked to the drum module (last in the stream) is Bcs it's glitching and having issues which we cannot pin point. Roland unfortunately have been no help and I've read the manual cover to cover with no mention of the glitch we're having on the drum module. All very difficult to work out Bcs the drum module really shouldn't be receiving anything corrupt from the scrips I sent to you earlier.
Hope this helps shed more light on what im trying to achieve with the midi blocking going to the drum module Td20x
It sounds like you may not want this BandHelper to send anything at all. So, turn off its MIDI Out (don't enable MIDI Thru).
Then, configure MidiFire to receive from the port carrying the MIDI Clock, filter out everything but Clock, and send it to the output UM1.
In iOS, we don't have to treat MIDI as a daisy chain, the way wired MIDI works. We can implement parallel chains receiving from and sending to different ports. You can even merge and filter streams from different ports. I get the feeling you may be trying to force processing into a single line, and that's making the job more difficult.