|
|
Post by ehauri on Dec 29, 2014 14:00:28 GMT
Thanks nic for this great suite of apps. In my quest to sync/slave all things to MidiBus, I'm going systematically through my various apps starting with drums.
DM1 is responding to start/stop and tempo, but for the life of me I can't see tempo information on the MidiBus monitor? Do you know of a way to do this through MidiBridge?
On a related note, does the MidiBus SDK provide for correcting latency differences among apps that might respond to MidiBus transport but start at slightly different times?
iOS 7.1.2 iPad2 MidiBus 1.1 MidiBridge 1.59
|
|
nic
Soapbox Supremo 
Troublemaker
Press any key to continue
Posts: 2,011
|
Post by nic on Dec 29, 2014 14:34:57 GMT
Hi ehauri, Not 100% sure I follow. You are driving DM1 with MidiBus but you are not seeing the MidiBus clock statistics (including tempo) in the Monitor pane of the MidiBus app? If you want to monitor the MidiBus clock itself then as long as the MidiBus port is enabled in both the Transport and Monitor sections, it should show. In terms of your second question, no the SDK doesn't specifically cover sync input at all - how to implement that has to be done by the developer since it has to integrate with whatever audio engine they are using. I do have examples on a way of ensuring that an app will sync properly to incoming clock by modelling the app so that its audio is driven by the app's internal MidiBus generated clock. On a practical level, MidiBridge can cater for latency issues by using the +D flag in the Stream Byter to delay events going to outputs to the lowest common denominator. Do you mean this? I can give you some examples to play with. Regards, Nic. |
|
|
|
Post by ehauri on Dec 29, 2014 18:02:24 GMT
Not 100% sure I follow. You are driving DM1 with MidiBus but you are not seeing the MidiBus clock statistics (including tempo) in the Monitor pane of the MidiBus app? Correct - even using just DM1's transport and with DM1 note & tempo going to MidiBus, I can't see any clock stats for DM1 in the MidiBus monitor (0 events). In terms of your second question, no the SDK doesn't specifically cover sync input at all - how to implement that has to be done by the developer since it has to integrate with whatever audio engine they are using. I do have examples on a way of ensuring that an app will sync properly to incoming clock by modelling the app so that its audio is driven by the app's internal MidiBus generated clock.Right, I assume (without having tested this yet) that apps using the MidiBus SDK will be perfectly in sync with MidiBus. But my question was more general, i.e. applying also to other sync-able apps that don't necessarily use your SDK. On a practical level, MidiBridge can cater for latency issues by using the +D flag in the Stream Byter to delay events going to outputs to the lowest common denominator. Do you mean this? I can give you some examples to play with.Correct - my thought was that each app's start-delay could be different, and that this could be corrected with Stream Byter in exactly the way you've suggested. Thanks for the offer for examples, I will hit you up later if/when I get that far. |
|
|
|
Post by ehauri on Dec 29, 2014 18:06:47 GMT
Using MidiVision I can see all the midi messages that DM1 is sending, I can't figure out why the clock stats aren't showing up in MidiBus monitor.
|
|
nic
Soapbox Supremo
Troublemaker
Press any key to continue
Posts: 2,011
|
Post by nic on Dec 29, 2014 20:25:40 GMT
Oh, I wouldn't expect to necessarily see any clock info *from* DM-1, since it is syncing to the MidiBus clock, so it shouldn't be sending clock out as well.
If it is sending clock, then amongst the messages in MidiVision you would see purple coloured events with little clock icons next to them with names like Start, Stop, Continue and Clock.
Be careful though that these are not the MidiBus events. To be sure use the 'Enable Inputs' button in Settings and ensure that *only* DM-1 is selected and the others are not.
Regards, Nic.
|
|
|
|
Post by ehauri on Dec 29, 2014 21:18:08 GMT
OK let me be more specific: (1) With DM1 receiving clock from MidiBus, and not sending anything, no clock info is displayed on the MidiBus Monitor (0 events) - as I would expect since DM1 is not sending anything. MidiBus's own clock looks great. (2) With DM1's midi-in disabled (i.e. MidiBus clock no longer being received by DM1 and transport disabled as well), and DM1 midi-out sending clock to MidiBus, still no clock info on the Monitor (0 events). Why?  |
|
|
|
Post by ehauri on Dec 29, 2014 21:28:36 GMT
And it appears I was mistaken about the events I was seeing on MidiVision. With only DM1 and MidiVision running, when I have DM1 as the only enabled input (Settings -> Enable/Disable Inputs) there is nothing even though DM1 is set to send clock to MidiVision. So I guess this is why nothing is showing up in the MidiBus monitor... But....when I enable MidiVision's input along with DM1 (Settings -> Enable/Disable Inputs), or even with MidiVision's input enabled and DM1's disabled, then I DO see clock events and note on/off when DM1 is running and set to send notes and clock to MidiVision. Can you explain what is going on there? I guess I don't understand the signal flow in MidiVision in this case. |
|
nic
Soapbox Supremo
Troublemaker
Press any key to continue
Posts: 2,011
|
Post by nic on Dec 29, 2014 21:31:45 GMT
Hi ehauri, Being specific is perfect! My guess is that DM-1's own virtual out is problematic. Can you try this: Run up MidiVision (with DM-1 running) and under 'Settings' hit the 'Enable Inputs' button and configure it so that the only input being listened to is DM-1 and nothing else. Now do your scenario (2) test and take a look at the events. Do you see any purple clock events? I'll try your scenario 2 myself also (tomorrow) and see if I can spot the problem. Regards, Nic. |
|
|
|
Post by ehauri on Dec 29, 2014 22:30:40 GMT
I just did it again, no clock or note messages received by MidiVision (as per my last post). Just the "DM1 is enabled" message.
DM1 does, however, manage (somehow) to trigger sounds and make tempo changes in Sampletank3 using its midi-out. I cannot understand why there are no corresponding midi messages appearing in MidiVision (also none in MidiFlow).
|
|
nic
Soapbox Supremo
Troublemaker
Press any key to continue
Posts: 2,011
|
Post by nic on Dec 30, 2014 17:07:33 GMT
Hi ehauri, OK, I ran up DM1 and had a play around. From what I can tell, DM1's own virtual output is non-functional (and from memory it's own virtual input is too). I get no action at all from it. If I select MidiVision as destination for tempo in DM1 it shows a correct event sequence for a clock at the MidiVision input. If I now tell DM1 to send tempo to MidiBus, it picks it up in MidiBus' Monitor pane with a 3.5% variation (compared to 0.0% for MidiBus' own clock) which is what I would expect. In this scenario the MidiBus clock is not running so the Monitor pane is just seeing what DM1 is sending to it directly. OK, so why does it trigger SampleTank? I'm not sure, but if you were sending tempo from DM1 to MidiVision and MidiVision's MIDI thru is set to on, then I would expect SampleTank to receive it. I don't think you can send tempo directly to SampleTank since SampleTank's own virtual input is not functional (at least in the latest version). From what I can gather, the only way SampleTank would see DM1's clock signal was if something else was receiving it directly and retransmitting it. Like I said this could be MidiVision or it could be MidiBridge if you were sending clock to it directly from DM1 and then routing that out to MidiBridge's own virtual input. Or maybe it is another app reflecting somewhere. Try terminating every app using the task manager except DM1 and SampleTank and see if it still triggers. I don't think it will, but if it does, then I am stumped! Regards, Nic. |
|
|
|
Post by ehauri on Dec 30, 2014 22:00:04 GMT
If I select MidiVision as destination for tempo in DM1 it shows a correct event sequence for a clock at the MidiVision input.(1) Yes I see this too, as well as note on/off events, as long as MidiVision's own input is enabled. If not, then I don't see anything. So am I correct that MidiVision is monitoring only the INPUTS of various apps, and not the outputs? If I now tell DM1 to send tempo to MidiBus, it picks it up in MidiBus' Monitor pane with a 3.5% variation (compared to 0.0% for MidiBus' own clock) which is what I would expect. In this scenario the MidiBus clock is not running so the Monitor pane is just seeing what DM1 is sending to it directly.(2) On MidiBus's monitor, I see events and DM1's tempo on the lane labelled "MidiBus" and I see nothing at DM1's lane (0 events). So - just to make sure I'm thinking about this correctly - MidiBus's monitor is looking at the inputs, and not the output? (if so, then the header at the top of MidiBus's monitor page "MIDI Sources" is confusing me because in this case DM1 is the midi source and so I expect to see events on the lane labelled "DM1") Try terminating every app using the task manager except DM1 and SampleTank and see if it still triggers. I don't think it will, but if it does, then I am stumped!(3) It does trigger Sampletank - as expected based on #1 above. Am I just thinking wrong about the signal flow implied by MidiVision and MidiBus's monitor page? If they are both monitoring the INPUTS of the various open apps (and not the SOURCES) then it all might make sense......except.....well, I'll let you answer first. |
|
|
|
Post by ehauri on Dec 30, 2014 23:04:54 GMT
Clearly, I do not understand what I am looking at (input or output) on the Monitor panel of MidiBus. Can you explain this in detail?
This text about the Monitor Panel from the MidiBus manual is confusing:
"incoming clock received on this source will be monitored"
Destinations "receive" incoming clock, not Sources. Where exactly in the signal chain is the Monitor panel measuring the clock?
|
|
nic
Soapbox Supremo
Troublemaker
Press any key to continue
Posts: 2,011
|
Post by nic on Dec 30, 2014 23:18:40 GMT
Hi ehauri, (1) MidiVision monitors CoreMIDI sources of other apps/devices as well as it's own destination - the meanings of which swap around depending upon whose point of view it is. From MidiVision's point of view an input is either another app or device's source or its own destination. From DM1's point of view, when you choose MidiVision to send to, DM1 writes to MidiVision's destination which of course MidiVision monitors as an input. It's a little tricky since source/destination differ in meaning depending on the point of view. (2) Yes, MidiBus is working the same way. DM1 is writing to MidiBus' destination (from DM1 POV) and MidiBus sees the events coming in on it's own virtual input (source from MidiBus POV). If DM1 correctly wrote to it's own output (which is a source from MidiBus POV) then you would see stats on the DM1 source, but since that is broken you see nothing. (3) SampleTank insists on reacting to every source in the system except its own. In some releases SampleTank has listened to it's own virtual port but it certainly doesn't in the most up to date release. This is why I always recommend if you want to get events into SampleTank then you just need to route the events to any output in MidiBridge except SampleTank. I can't for the life of me understand why SampleTank sees DM1 events since it cannot see what DM1 is sending to the MidiBus virtual port (which actually shouldn't exist if MidiBus is properly terminated anyway) and DM1 does not write to its own virtual port. In the scenario where you have terminated all apps except DM1 and SampleTank you should see only only SampleTank in DM1's output list - does that tally? If there are no other apps (or devices) running then it should be impossible for DM1 to ever drive SampleTank unless something else is shunting the events between them. Or maybe DM1 does write to its own output in certain cases but I think this is unlikely. From what I know of these two apps your scenario just should not work, but obviously it is. If I have some time tomorrow maybe I can download the two apps and see if I get the same result as you. I think the confusion arises because source and destination differ in meaning depending upon whose point of view you are naming them. Hopefully the above explains that. I still get confused myself and have to think carefully! Regards, Nic. |
|
|
|
Post by ehauri on Dec 31, 2014 0:10:55 GMT
I tend to think of this from a hardware perspective, where each piece of gear has physical ports (IN, OUT, THRU) connected via cables. Electrons are flowing in only one direction along each cable, so from that perspective the only POV is the human one. Each IN is an IN, each OUT is an OUT, THRU mirrors IN, and there is no confusion about it.
How can MidiVision have a destination? Surely it can mirror its own input (and Midi Thru when enabled) but there is no way that I can see to select something for MidiVision to send midi messages TO - if the output of MidiVision is not connected to anything, there is no destination. If you mean that Midi Thru essentially results in MidiVision having itself as a destination, then that is the only way I can comprehend your #1 above.
So regarding #2, if the only connection is DM1 sending midi to MidiBus (using DM1's transport & tempo, not received from MidiBus), where should I look for the DM1 clock stats? On the lane labelled "MidiBus" or the lane labelled "DM1"?
In this setup:
MidiBus set to 200 BPM
DM1 midi-in (disabled)
DM1 midi-out (sending to MidiBus)
using DM1's transport and DM1's tempo @100 BPM
....on the MidiBus Monitor panel I get nothing on the "DM1" lane, and I get 100 BPM clock stats on the "MidiBus" lane. DM1 data appearing on the "MidiBus" lane does not make sense to me (unless MidiBus is monitoring both IN and OUT).
|
|
nic
Soapbox Supremo
Troublemaker
Press any key to continue
Posts: 2,011
|
Post by nic on Dec 31, 2014 18:59:46 GMT
Hi ehauri, Yes, it is not quite the same metaphor as the physical world, hence Apple use the source/destination terms. The issue is that a source can be a destination and vice versa depending upon the point of view. Ultimately they are just 'endpoints' between two apps or devices. Assuming each app has one source and one destination, then if you were to look at that app as a hardware unit externally, then that app's destination would be marked as MIDI IN since that is where you send events and it's source would be MIDI OUT since that is where events come from. If you look from the inside of the app then it's external destination (MIDI IN) is internally it's source and it's external source (MIDI OUT) is internally it's destination. MidiVision thus does have its own external destination which other apps can write to. When 'thru mode' is on then MidiVision will echo whatever it receives from it's external destination to it's external source. It will also echo what it receives from any device or counterparty app's external source to the corresponding external destination. MidiVision only does thru - it cannot route from any arbitrary MIDI IN to MIDI OUT like MidiBridge. When DM1 is setup to send tempo to MidiBus (ie. from it's point of view), then it is writing to MidiBus' external destination (MidiBus MIDI IN) so you will see the stats in the MidiBus lane and not the DM1 lane. If DM1 wrote to it's own internal destination (which it doesn't) then you would see the stats (also) in the DM1 lane in MidiBus. In your final setup, this is what is happening. MidiBus is not sending any clock at all so the MidiBus bpm is of no relevance and DM1 is writing to MidiBus' external destination directly. MidiBus *is* monitoring it's own MIDI IN (internal source) *and* the MIDI OUT of all other devices/apps (external sources) - in other words, it is monitoring all sources from it's point of view! The nub is that source/destination swap roles for that app's own virtual ports inside that app. Regards, Nic. |
|
