Midi files not working with Quantiloop

[Ahiru]

Okay, I figured out that the delay was coming from the pitch shift functionality, even when it's not in use for a given recording. I reworked the audio player to leave the pitch shift functionality out of the flow unless a recording needs it, and that decreased the delay of the recording relative to the tempo clicks from about 110 ms (on an iPad 2 with iOS 12) to something I couldn't hear or see in a DAW waveform display.

Clarifying in case we're calculating delays against a slightly different reference:  The 215 msecs I saw was comparing an event in a Recording file to the sounding of an event (specifically a MIDI note-on) in the corresponding SMF file.  In the DAW file that generated both the Recording and SMF, these two events (audio event and MIDI note on) occur at exactly the same time.  When played back from the DAW (driving an audio system directly and a simple external MIDI sound module, neither with significant latency), they sound at at the same time, as expected.  When the Recording plus attached SMF is played from BH on an iPad with iOS 12 (into an iConnectivity Audio2+ driving an audio system as well as driving the MIDI sound module), I get the 215 msecs delta.  To measure the difference I arranged the tests so the final analog audio was on L and MIDI was on R of a stereo mix, then recorded this final mix so it was easy to measure the delta within a utility like Audacity.  (None of these tests had anything to do with lighting (yet); they were just to characterize the absolute delta between audio and MIDI as emitted from the iPad.)

I add this detail since I'm not sure if by 'tempo clicks' you are refering to MIDI events within an SMF file attached to the Recording, or something generated directly by BH outside the SMF file and which might therefore have different latencies.

If I play a recording along with a MIDI file and watch the MIDI data in an external monitor, that is also noticeably more accurate, although that's not as good of a test as playing a real song through a real lighting system.

Ahiru, I wonder how comparable my numbers are to yours, due to different hardware.

Indeed there's a difference 110 vs 215, more than I would have expected.  Looking purely at audio and MIDI (ignoring all the downstream lighting stuff), I'd expect there to be some difference from system to system, e.g., impact of the iConnectivity interface vs some other iOS interface, but only by a few msecs.  (At the time I did some additional tests that convinced me the iConnectivity was not adding deltas between incoming audio vs MIDI.)  FYI, I found the same results on an old iPad Air and on a newer iPad Pro, the later on both iOS 12 and 13, so I don't think that's made any difference in the deltas.

So I'm back to wondering if the 'tempo tics' you are measuring against is the same is my 'MIDI note-on events within the SMF file', so we're comparing apples and apples.

If they were comparable, this change would mean that your audio would still play about 100 ms after the MIDI, and you would still need some delays in your MIDI files. With a more complex MIDI system than I have, I would expect the MIDI to end up behind, not ahead, of the audio. In that case I think the simplest solution would be a "delay audio" setting that delays the playback of recordings or tempo clicks to allow better syncing with downstream MIDI equipment. A setting to delay the MIDI playback could also be possible, but it seems less likely that someone would have to adjust in that direction. What do you think? What iPad are you measuring this with?

I think you're right (I'd need a 'delay audio' setting), with a caveat:  If your change resulted in no Recording/SMF relative delay at all, then I think I'd indeed need to delay audio (Recording) by 115 msecs.  However, if your change resulted in a reduction of the delay by 110 msecs and I still see a net 215 - 110 = 105 msec delta, then I'd need to delay the MIDI (SMF) by 10 msecs.  So hard to say for sure without reconciling why I measure 215 msecs where you measure 110 msecs.  (Safest from my "I don't have to write the code" end-user perspective: a plus/minus relative adjustment setting )

For automation tracks, I have a wish list item to select multiple events and offset them by a given amount, so that should enable readjusting in either direction as needed.

Sounds good.

BTW, thanks so much for digging into this... I know it's arcane, but the real-world benefits of performing with a Recording backing track with the full power of a tightly synchronized SMF (MIDI file) are just fantastic!

[arlo]

I add this detail since I'm not sure if by 'tempo clicks' you are refering to MIDI events within an SMF file attached to the Recording, or something generated directly by BH outside the SMF file and which might therefore have different latencies.

I'm measuring the difference between a recording and BandHelper's built-in tempo clicks because it's easy to see and hear whether those are in sync. I can say fairly certainly that the recording is now starting up about 100 ms faster than before. But I wouldn't expect your SMF playback to be another 100 ms faster than that. The code for playing the MIDI is pretty similar to the code for playing recordings and tempos, so I'd expect them all to be pretty much in sync now that the pitch shift delay is removed. Anyway, I think it would work to add the audio delay function and you can at least use it to add 100 ms of delay back in to realign everything the way it was, then we can see if it's possible to go a step further and do away with the delays you've added to your MIDI files.

(Safest from my "I don't have to write the code" end-user perspective: a plus/minus relative adjustment setting )

Unfortunately it's not that easy because making the audio earlier really means making the MIDI later, and I'd prefer not to mess with the MIDI timing. Only delaying the audio would be relatively easy.

[Ahiru]

I'm measuring the difference between a recording and BandHelper's built-in tempo clicks because it's easy to see and hear whether those are in sync. I can say fairly certainly that the recording is now starting up about 100 ms faster than before. But I wouldn't expect your SMF playback to be another 100 ms faster than that. The code for playing the MIDI is pretty similar to the code for playing recordings and tempos, so I'd expect them all to be pretty much in sync now that the pitch shift delay is removed. Anyway, I think it would work to add the audio delay function and you can at least use it to add 100 ms of delay back in to realign everything the way it was, then we can see if it's possible to go a step further and do away with the delays you've added to your MIDI files.

OK, when you release the new version I can repeat my previous tests to measure the net delay against events in SMF playback.  (I will still keep my wager on SMF playback differing from built-in tempo clicks for whatever obscure reason )

Unfortunately it's not that easy because making the audio earlier really means making the MIDI later, and I'd prefer not to mess with the MIDI timing. Only delaying the audio would be relatively easy.

Understood... if I'm lucky and the delay I need to add for lights nets out to zero, or some additional audio delay, then I'll be golden going foward (after modifying all my existing MIDI files to remove their current delay).  If I find I still need to delay MIDI, I suppose I can just keep doing what I'm already doing with individual MIDI files, but just changing the amount of MIDI delay; not great, but no worse than today (other than I'll need to modify all the existing ones to work with the new version).

A practical matter:  Is it relatively easy to roll back BH to a previous version on iOS if I need to go back and forth between the older and new version while in the process of converting all my existing MIDI files?  (Let me know if that topic is better via a ticket)

[arlo]

A practical matter:  Is it relatively easy to roll back BH to a previous version on iOS if I need to go back and forth between the older and new version while in the process of converting all my existing MIDI files?

No, it's practically impossible, and it's also not easy to send you a beta version to test with. But if you have two iPads with similar performance, you could update the app on one and not the other.

[Ahiru]

No, it's practically impossible, and it's also not easy to send you a beta version to test with. But if you have two iPads with similar performance, you could update the app on one and not the other.

OK, understood.  Then I think I'll handle migration with:
1. Update to new version, but don't change any existing MIDI files (leave built-in 100msec delays as is)
2. Determine what global audio delay I now need with the new version and using the existing MIDI files.

(This lets me keep playing with all existing files, even though both MIDI and audio are delayed.  In a sense it kind of 'puts the new version back where the old version was' with respect to audio delays.)

3. Test with the new version to determine what audio delay is needed if the MIDI files are updated to have no delay.
4. Convert MIDI files to have no delay (which will be many days of work), saving them 'offline' until all done.
5. In one massive effort, update all Recordings to attach the updated MIDI files, and change the global audio delay to whatever it now needs to be.

(Now going forward, it is simpler... new songs require no delay for MIDI; very nice!)

If for some reason in step 3 I calculate I still need a net delay to MIDI instead of audio, I'll just stop there since there's no benefit to all the rework, and keep begging for a MIDI delay param as a sister to the audio delay param

BTW for your new 'audio delay' param, I'd like to lobby for a global value (rather than something you have to set for every song or recording), so it's easy to manage any changes that might be needed if an overall system shifts a bit in latencies due to equipment, OS, signal paths, or whatever.

[arlo]

That sounds good, but please check in with me after step 3, before doing many days of work, just to make sure we're on the same page at that point.

And yes, the audio delay will be a global setting, on the Settings > Audio & MIDI page. This will be included in the next update in the first half of next week.

[Ahiru]

Thanks Arlo!
You as a responsive developer and your software that so aptly achieves it's real-world utility are both in a class by itself!

[go2ldook]

So, glad to see my points at least brought up some discussion, because all of this will be useful for anyone who is trying to do time related work like looping to a backing track.

As an update to my original post, I have found that there is indeed about a 100 msec delay from bandhelper that Arlo has noted. The more I assessed waveforms and refined my technique for figuring this out, the more consistent that has been. I end up trimming around 160 msec from each track to get it to line up with the tempo...the additional 30ish msec is due to what gets tacked onto my files when rendered to mp3 in FL studio....so I have to remove 30 from the track I am editing, plus an additional 30 to account for the amount that the new render would tack on. Not clear why this occurs...I have inspected all the rendering settings, but another person in a music forum elsewhere had noted the same with their sequencer program, so I think this is native to mp3 rendering. I also find that once I get the tempo lined up between my track and the Bandhelper tempo (as evidenced by my loops being perfectly on time in Loopy HD, which is slave to Bandhelper's clock), that there is a slightly variable amount of MIDI shift I have to make in my MIDI file. it is ballpark around 40-50 msec, give or take. I trigger a MIDI sound event and check it compared to my tempo clicks and it comes in a tad early. A quick calculation allows me to convert that number of msec into "ticks" of offset in MidiEditor, and I am perfectly in line.

Of course, the negative here is that Arlo has now perfected Bandhelper, so I will need to go back and rework all this if I update! All good, better to have Bandhelper running smoothly. Arlo, I will have to see if I find a global msec time shift useful...I tend to line all of these up manually and sometimes I find some variation, but only by maybe 10-15 msec, so may just be my analysis that is flawed.

As an update to my set up, I switched from Quantiloop to Loopy HD. Thought Quantiloop looked like the best choice....I liked the look of the interface. Loopy looks like a kid's app, with its screen full of swirling circles. But Quantiloop was not playing well at ALL with my iPad Pro running Bandhelper. Loopy HD is incredibly stable, once I learned some tricks. The only early negative was it has to "learn" Midi commands, you cannot input CC numbers and associate commands with them initially. I had to create a training MIDI file with CC's 1-127 on the right MIDI channel for Loopy HD, and run that and get the commands in. Once you have done that, you can easily change what each of those commands does, so that is a one time set up. Obviously geared towards the average user who would have a footpedal to train, but I am using background MIDI files.

Anyway, a couple of other quirks I discovered is that putting your iPad in Airplane mode affects timing between apps, so I have done all of my set up in Airplane mode to promote stability in the system. I also found that Loopy HD really needs a full reset between songs. There is a reset command that erases all loops and clears the tempo. I programmed this into the end of each MIDI file, but was still running into a frustrating time drift as I ran through more than one song. What I speculate is that, even though I might reset LOOPY HD with a MIDI command, Bandhelper might still be sending Tempo at the end of the song, so the Tempo does not get reset, and creates some jitter of sorts when you go to the next song. My solution is a "null" song on my setlist called RESET LOOPY which contains no Tempo, just a MIDI preset with the command to reset Loopy. This works perfectly, and I now have a stable running system.

Loopy is now replacing my Pigtronix Infinity pedal as my looper. First gig is this weekend. I have yet to tap the full potential of this...Loopy can handle 12 loops on top of the overdubs. Pretty incredible. It has take some work and frustration with me ready to pull my hair out a few times, but this is by far the best looping solution out there...way better than any available hardware looper. I am using RME Babyface Pro as my iPad audio interface, and it works great. I use the associated app on my iPad to tweak levels from my two looping sources (guitar, and a separate channel of my guitar as bass after running it through a Whammy and EQ). I also use Audiobus to get my audio into Loopy HD. It has a MIDI function as well, but I was finding some issues using that to help with MIDI between Bandhelper and Loopy HD. I might go back and recheck that now that I understand more, but bottom line is that Bandhelper and LoopyHD talk MIDI just fine, and I see no advantage to Audiobus for the MIDI. One thing that definitely happened was I had it all set up wrong when I was using Audiobus, and my hardware pedals were getting 2 MIDI clock signals, which doubled their tempo. Bandhelper sending out MIDI Clock to the pedals and to Audiobus, but then Audiobus was basically sending, I guess, a parallel signal out to the pedals, doubling the tempo. Have to be very careful with your connections!

Anyway, a long-winded debriefing, but some of this may help someone! I may do a video tutorial on my set-up in the future as it is pretty interesting!

[arlo]

Arlo has now perfected Bandhelper, so I will need to go back and rework all this if I update

It's far from perfect I'm sure, but this should be a step in the right direction.

Bandhelper might still be sending Tempo at the end of the song

If you stop the tempo function in BandHelper, that sends a MIDI Stop message, and stops sending the beat clock messages. You should be able to confirm that's working by looking at the activity log built into BandHelper.

My solution is a "null" song on my setlist called RESET LOOPY which contains no Tempo, just a MIDI preset with the command to reset Loopy

Instead of adding this as a song in your set list, you could add the reset MIDI preset to your layout, and then it will be available while viewing any song.

[arlo]

Okay, the reduced delay when playing a recording, and the Settings > Audio & MIDI > Delay Audio setting to put it and more back in, are included in today's version 4.0.13 release:

http://www.bandhelper.com/support/release_notes.html