|
|
Post by ehauri on Jan 8, 2015 2:26:55 GMT
Why can't I see any MIDI messages from the new sequencer ProMidi? I can see only clock messages in MidiVision, no transport (start/stop) and - most curious to me - no note on/off. But it very definitely is triggering Sampletank and Nave.
Is it possible that the note on/off is taking a path not observable by MidiVision? I am curious about the signal flow here.
|
|
|
|
Post by ehauri on Jan 8, 2015 2:43:58 GMT
I can see the note (and CC) messages coming from Nave to MidiVision's input (when enabled), but I am really curious as to why I can't see the data stream between ProMidi and Nave.
|
|
nic
Soapbox Supremo 
Troublemaker
Press any key to continue
Posts: 2,011
|
Post by nic on Jan 8, 2015 10:58:19 GMT
Hi ehauri, You need to consider two scenarios here, assuming that ProMidi can send to either it's own virtual output or another app's virtual input. If ProMidi is addressing Nave's virtual port (ie. you setup ProMidi to send its events to Nave directly) then MidiVision will not see those events, since that communication is effectively private between ProMidi and Nave. If you change the setup to that ProMidi sends events to it's own virtual output and then you configure Nave to receive events from ProMidi (ie. the reverse of the above) then MidiVision will be able to see the events since they are being published to ProMidi's virtual out. The latter is preferable IMHO (indeed the MidiBus SDK sets this up by default) but depends on the controlling app's virtual MIDI out to be functional (I assume ProMidi's would be) and that in the sound generator/receiver app that it offers the ability to select other app's virtual MIDI outs to react to. In an ideal World, all controller apps would only ever need to send to their own virtual MIDI out (and network/physical) ports and receiver apps would only ever need to listen to other app's virtual (and network/physical) ports - or vice-versa. CoreMIDI doesn't restrict this so many apps offer a hybrid which results in more than one way to interconnect. As long as you understand the two scenarios and each app's implementation then you can decide yourself which method to use. Regards, Nic. |
|
|
|
Post by ehauri on Jan 8, 2015 14:30:15 GMT
Thanks Nic - that explanation makes it pretty clear what is going on.
In ProMidi and Nave (and nearly all other apps I have experience with), the user is allowed to choose who to send MIDI to and who to receive MIDI from. For example, in ProMidi the MIDI-In choices are "Network" and "Nave" and same for MIDI-Out. No more than that. Whether this happens via virtual out/in or via "peer to peer" connections (for lack of a better word) is almost never made known to the user, it is rare for an app to give you a choice to connect to their own virtual ports. So MIDI messages from some apps will appear in MidiVision, and messages from some apps won't - and the user is sitting there scratching his head and wondering why.
Do you think there is a way to set up some combination of MidiBridge, MidiBus and MidiVision so that all messages passed to/from CoreMIDI can be seen?
|
|
nic
Soapbox Supremo
Troublemaker
Press any key to continue
Posts: 2,011
|
Post by nic on Jan 8, 2015 14:41:25 GMT
Hi ehauri, Yes, with flexibility comes confusion! CoreMIDI doesn't have any facility (under iOS) to 'snoop' on private 'peer to peer' connections, unfortunately. In order to monitor all MIDI goings on the rule of thumb is to make sure all controller apps are transmitting on their own virtual MIDI out *or* (if the app permits multiple selections) selecting MidiVision as a destination as well as the thing you want to control. Personally, I route everything into MidiBridge where possible and then use that to select which outputs the events go to. That way if I want to monitor things then I just connect what I want to monitor (on left) to MidiVision (on right) and everything that is connected will show up. Regards, Nic. |
|
