to Intua: Midi Clock & Evidence that its broken in BM2
Ok peeps here it is, I have been on a rant about slaving BM2 to a DAW for a long time now I can present some hard facts proving that its broken/not working/sloppy/jittery in BM2
Intua: you can choose to ignore this but I am a paying customer and your product is broken, only now I have evidence to prove it is BM2 thats broken and not anything else.
Here is the eveidence, feel free to test it yourself.
STEP 1:
lets establish & agree that slaving an iOS using Midi Clock works and can be very TIGHT with superlow jitter
DAW: Pro Tools 10 HD
iOS APP: StepPolyArp 2.0.2
Connection: Network connection via Ad-Hoc Wifi: IT WILL NOT WORK USING WIFI OVER ROUTER, it will be sloppy
Pro Tools sends Midi Beat clock to iPad using the Mac Midi Network, in Pro Tools i have adjusted for latency, -256 samples, it is not jitter, it is a steady latency which needs to be compensated for and Pro Tools has a entry box to allow to do this
Hit play in Pro Tools starts PolyStepArp, I have a 16th note pattern playing and recording that pattern back via Midi (again same ad-hoc network) to Pro Tools onto a Midi track
After you hit play the first note will be delayed, that is normal with midi clock. Everything thereafter is VERY tight: I mean the jitter i can see is 6 samples at most at tempo 90. Thats better than lots of hardware sequencers including some MPC's in the market
I have spent 2 full hours using and testing PolyStepArp, it looks steady and consistent. I do not see and randomness which is great.
OK NOW OVER TO STEP 2:
Same test using BM: please note that I will only focus on midi. BM2 will not be used to playback Audio, testing the Audio output just makes the result worse. My view is that midi has to be fixed and then audio measured.
So setup midi to recive midi clock from adhoc wifi network in BM2, adjust the latency compensation to around -860 in pro tools
create a 16th pattern in BM2, loop and setup midi to send via Network out
record network out midi to Pro Tools on a track, same method as in PolyStepArp
RESULT:
The jitter is between 100-150 samples, no consistency at all, hit play the notes will be 100 samples behind of the pro tools grid, hit play again the notes will be 50 samples ahead the pro tools midi grid.
Test this with a metronome/or 16th hat you will hear the same result, the reason why i chose midi is to keep the test in line with what works with polysteparp on iOS. that way no blame can be put on the ad-hoc network latency or the iOS midi implementation or anything else in fact.
I really think its time for action Intua, this result is very poor and I am sure you guys have know this already. Only difference now is that there is a reliable way of proving that that STEADY midi clock slaving is possible on iOS. (Thanks PolyStepArp Dev)
PLEASE NOTE:
iRiG Midi will not produce a jitter free performance even with PolyStepArp
a Routed Wifi Network will not produce a jitter free performance
ONLY Ad-HOC network did the job during the tests I have performed
the good news is that its possible: so please INTUA, take action and get this fixed once and for all, it can be done.
Thank you for listening.
Intua: you can choose to ignore this but I am a paying customer and your product is broken, only now I have evidence to prove it is BM2 thats broken and not anything else.
Here is the eveidence, feel free to test it yourself.
STEP 1:
lets establish & agree that slaving an iOS using Midi Clock works and can be very TIGHT with superlow jitter
DAW: Pro Tools 10 HD
iOS APP: StepPolyArp 2.0.2
Connection: Network connection via Ad-Hoc Wifi: IT WILL NOT WORK USING WIFI OVER ROUTER, it will be sloppy
Pro Tools sends Midi Beat clock to iPad using the Mac Midi Network, in Pro Tools i have adjusted for latency, -256 samples, it is not jitter, it is a steady latency which needs to be compensated for and Pro Tools has a entry box to allow to do this
Hit play in Pro Tools starts PolyStepArp, I have a 16th note pattern playing and recording that pattern back via Midi (again same ad-hoc network) to Pro Tools onto a Midi track
After you hit play the first note will be delayed, that is normal with midi clock. Everything thereafter is VERY tight: I mean the jitter i can see is 6 samples at most at tempo 90. Thats better than lots of hardware sequencers including some MPC's in the market
I have spent 2 full hours using and testing PolyStepArp, it looks steady and consistent. I do not see and randomness which is great.
OK NOW OVER TO STEP 2:
Same test using BM: please note that I will only focus on midi. BM2 will not be used to playback Audio, testing the Audio output just makes the result worse. My view is that midi has to be fixed and then audio measured.
So setup midi to recive midi clock from adhoc wifi network in BM2, adjust the latency compensation to around -860 in pro tools
create a 16th pattern in BM2, loop and setup midi to send via Network out
record network out midi to Pro Tools on a track, same method as in PolyStepArp
RESULT:
The jitter is between 100-150 samples, no consistency at all, hit play the notes will be 100 samples behind of the pro tools grid, hit play again the notes will be 50 samples ahead the pro tools midi grid.
Test this with a metronome/or 16th hat you will hear the same result, the reason why i chose midi is to keep the test in line with what works with polysteparp on iOS. that way no blame can be put on the ad-hoc network latency or the iOS midi implementation or anything else in fact.
I really think its time for action Intua, this result is very poor and I am sure you guys have know this already. Only difference now is that there is a reliable way of proving that that STEADY midi clock slaving is possible on iOS. (Thanks PolyStepArp Dev)
PLEASE NOTE:
iRiG Midi will not produce a jitter free performance even with PolyStepArp
a Routed Wifi Network will not produce a jitter free performance
ONLY Ad-HOC network did the job during the tests I have performed
the good news is that its possible: so please INTUA, take action and get this fixed once and for all, it can be done.
Thank you for listening.
Comments
Second, using only two apps to test this is hardly scientific. Using the "control" app in the second test just doesn't seem right. independent tests with numerous different apps and how they perform generating internal audio is the only way to find out if BM2 is the only culprit.
Third, aren't there just too many variables trying to run solid clock over a network connection? Most serious users are still going to want a wired connection for best results.
Do the other major iOS workstations perform any better?
Again, I don't dispute what you've presented here.
I disagree with you, there is no need to get more scientific than this & and there is no need to look at any more apps.
1. see example of iOS app, as above, where midi clock works, real life example.
2. evidence that BM2 doesnt work with, feel free to show me what I did wrong-in case I did!
3. no big variables with ad-hoc midi network, I am running a plain ipad 2 with connection to a osx 10.6.8, no jailbreak etc
4. yes cable connection would be great, but that introduces another variable, ie. irig midi with polysteparp produces jitter whereas ah-hoc network does not, Its proven to work and hence less variables
5. we are not talking any other ios workstations, we are talking BM2 <!-- s:) --><img src="{SMILIES_PATH}/icon_e_smile.gif" alt=":)" title="Smile" /><!-- s:) -->, frankly don't care about the others BM2 is good and just a matter of fixing this so I the dragon can be unleashed
The facts are there you can choose to ignore them, fine
In your first post, you claimed BM2 was broken and not "anything else". You've only tested one other app.
I agree that the clocking needs work, but your test is just not scientific enough to claim that the midi clock is "broken".
I have measured BM2's midi clock slave performance at least 10 times in the last 8 months, its only now I can prove that iOS and midi clock CAN be tight and steady. Please don't do me like that unless you can contribute anything to get this resolved.
i think this is the real conclusion here, and its an important one!
All I get with my akai EIE (midi din) is drift after about 1:30, and the slaves gradually start dragging behind as time goes on. Maybe your ad hoc method is the way to go. It's a shame that I can't get my hardware to clock for more than a couple of minutes via hard connections.
The akai mpd32- nothing I've tried can get this thing to send a steady clock on its own. Clocked from protools it's fine. Otherwise note repeat is all over the place!
EDIT:
ok, after finding the most relavent thread on this subject, i found this:
"Have a MPC4000 connected to Pro tools as a slave and it supertight. I am using a sync gen box innerclocksystems.com which provides a sample accurate midi clock thats driven by a Plugin from the DAW
I have 10 samples max jitter on the MPC4000 slaved to Sync Gen box/Pro tools
Slaving beatmaker2 to the same sync gen box gives me really sloppy timing. I have used iRig Midi on the pad and connected Sync gen Midi to iRig Midi on ipad"
this was all you had to say! and what that thread tells us is that it is an ios buffer handling issue, not necesarily a specific BM2 issue. Sunrizer went down to 128 samples for buffer size, can we do the same with BM2??
Intua????
Man i appreciate your engagement, but please keep things simple
Audio is out of the equation, I am clocking BM2 from PT Daw over Ad-Hoc network. (MIDI)
the result is a 16th note midi track going back into PT DAW again over Ad-Hoc network (MIDI)
The midi notes recorded back have a jitter of 100-150 samples, this has got nothing to do with Audio.
I agree that Audio may be an issue on top of it but lets fix midi first before attacking issue #2 which may be a non issue. To finish this off: Audio Buffer should not matter as its fixed and can be compensated for.
Lets stay on topic please: This is simple midi timing thats busted and not working as it should.
I think we can all agree by now that Beatmaker is basically a huge feature list, however, in practice, none of the features work reliably and correctly.
Thanks for getting involved.
try the following and see if you get a good result:
Setup an Ad-Hoc midi network between your two iOS Devices
UsePolyStepArp on one and something that can record midi on the other iOS device
hit a note it will generate a 16th pattern, playback and listen & look at the notes on a grid
The only variable will be the midi record, I am confident that adhoc network and polystep are stolid for midi timing. Once you trigger an audio signal funny thing will start happening, I think we need some ios tech guys to really get to the bottom of this.
Our MIDI clock implementation is quite simple and needs improvement, as jitter is just ignored, which obviously affect the results. I'll get back into our code and implement what is missing.
On side "dev" note, MIDI clocks is I think one of the most illogical thing I've seen in this protocol; but it *is* possible to get OK results with them -- no doubt!
Thanks for reporting the issue,
Cheers !
Mathieu.
Thank you for the dedication, I know you guys can crack the nut on this.
Please try to get midi straight first, PolyStepArp is a great example that midi can have superlow jitter, we are talking 2-3 samples which is better than my MPC4000. In fact better than the internal clock of my MPC4000, yes strange but true.
The objective should be to get Midi Clock from a DAW like Pro Tools via Ad-Hoc Wifi network to drive BM2 and output a midi 16th note repeat to a DAW and get jitter under 5ms. That is the foundation for getting the midi sequenced audio to be tight. Audio is problem #2. Fixing midi will be able to eliminate one half of the issue and will give you a good founddation.
Right now the midi jitters really bad so it will have an affect on audio subsequently.
Fingers cross and I will be testing. If you need anything message or email me.
Thank you for listening!