I have been successfully using MIDI files attached to recordings to trigger my
Pigtronix Infinity Looper. I am trying to do the same thing, but with Quantiloop. It is responding to Preset changes in my Midi Preset for a song, getting tempo data, but CC's from the running Midi file are not working. They are still passing to other devices...my loop switcher is changing presets as expected, so I do know that the file is running in the background. I have the correct channel selected for Quantiloop, and I have customized the CC's to be same as the commands I used for the Infinity.
Is there something I am missing as far as accomplishing this task between the two apps?
So Quantiloop responds to messages from a MIDI preset, and other devices respond to messages from a MIDI file, but Quantiloop doesn't respond to messages from a MIDI file -- is that right?
That is correct. And I have confirmed that I have used the same Midi Channel for Quantiloop that I had assigned for my Infinity Looper, and assigned the CC messages to idential functikns. Quantiloop is also receiving tempo data from Bandhelper. As a check, I may turn tempo off and see what happens. The Midi File has a tempo as well....wonder if it would be "seen" by Quantiloop.
This is the one thing standing in my way from a really optimal looper solution. The use of the MIDI file with the Infinity looper is amazing. I get to play guitar (using a click track of course), and the loops are triggered perfectly every time. Much less stress and can focus on my performance. But that looper is somewhat limiting with only 2 channels and there are some issues with that looper that I have learned to accept. Quantiloop, if I can get it working, would provide incredible control.
While playing the MIDI file, you can click the MIDI icon in the top toolbar to open the MIDI Status window, then look in the Activity Log to see the data being sent. Does that show that the data is being sent to all ports?
Not sure what I did, but working now. I am having to tweak the way the commands work, but shows promise.
So it is working now....with issues. The midi changes for my guitar pedals happen like they always have and reliably. With Quantiloops it is hit or miss, especially early midi changes, like recording the first track.
In Bandhelper, it is sending Midi Clock data and Tempo is set per song. In Quantiloop I have the tempo set to be controlled by Bandhelper and that comes through. But j run into these issues that are intermittent and make me uncomfortable looping live. Another odd behavior in the Bandhelper app that I get intermittently is that the Recording won't play. I have Recording 1 as a backing track with the Midi file attached, and this has worked almost flawlessly with my Infinity hardware looper. With Quantiloop, instead of the normal count in timer under the recording icon I will get something that reads like -44000:00 (I can screen shot that when I get home), and the recording won't start. Have to click on a couple of songs to get it working again.
And a last thing I see: I have struggled with an inherent offset between the running Midi file and the Mp3 backing track, despite the track being created in a sequencer with same tempo and putting the Midi CCs in the right positions (the right measure position). So I generally have to either adjust the Midi file temporally or the mp3 track. I have found the Midi file seems to run in pretty good synch with Bandhelper's Tempo, so lately I have focused on adjusting the mp3. To do this I run the audible tempo from Bandhelper concurrently with my mp3 track (normal the audible tempo is off). I then tweak the sequenced track until the tempo and track waveforms line up. For some reason this is causing Bandhelper to crash. Usually I can get enough beats to serve my purpose, but wondered if this is fixable as well.
Sent from my SM-G965U using Tapatalk
Quote from: go2ldook on October 26, 2019, 08:51:24 AM
<snip> I have struggled with an inherent offset between the running Midi file and the Mp3 backing track, despite the track being created in a sequencer with same tempo and putting the Midi CCs in the right positions (the right measure position). So I generally have to either adjust the Midi file temporally or the mp3 track. <snip>
Yes, this is correct. I ran a lot of tests on this to conclude the events from a MIDI SMF file precede the audio Recording events by about 215 msecs
(corrected: had it reversed in original post!). (There is also an anomaly for an event at the very start of the song where the delta is about 182 msecs.) I use the MIDI (SMF) file to control lights. After entering lighting events in a track on my DAW corresponding to backing track events (e.g. on exact measures, etc.), as a final step I have to shift the entire lighting MIDI file by a fixed amount of msecs so lighting changes will look 'in the pocket' with the audio.
I would implore Arlo that if he does anything to change this delta, please also add a global parameter that allows us to enter our own offset adjustment between audio and SMF, so I don't have to re-adjust many dozens of SMF files. :D (Of course it could also be due to something in iOS audio/midi libraries that BandHelper has little control over, and thus Apple could do something to change it... I hold my breath whenever testing new iOS releases to make sure relative latencies don't change!)
According to my measurements, using waveform analysis to line up a click with a triggered midi note, the issue is further complicated by the fact that the offset varies according to tempo. I created a tempo table in Excel to help me deal with this and try to predict the offset.
Sent from my SM-G965U using Tapatalk
Quote from: go2ldook on October 27, 2019, 06:17:00 AM
According to my measurements, using waveform analysis to line up a click with a triggered midi note, the issue is further complicated by the fact that the offset varies according to tempo. I created a tempo table in Excel to help me deal with this and try to predict the offset.
Sent from my SM-G965U using Tapatalk
Similar here... I delay the MIDI lighting track by 100msecs, but for each song I have to calculate what that is in terms of the DAW's native 'tics', and so I have my spreadsheet: plug in BPM and 100 msecs target, get tics to shift. :)
My waveform analysis showed the absolute delta msecs between the Recording and SMF events was fixed, regardless of the song BPM. I don't use native BH timing for anything (tics, clock, etc.). So I only need to fuss over getting that fixed Recording/SMF delta handled for each song.
BTW, even though the absolute delta is 215 msecs, I delay the lighting MIDI track by only 100 msecs... that's because in my system there are lots of other downstream paths that add their own latency to both the audio (not so much) and lights (more, going to a second iPad running the separate lighting app, then DMX over Wi-Fi, plus consideration of physical lighting turn-on time). So in the end I came to the 100 msec figure by trial and error, implying all that downstream lighting stuff adds about 115 msecs relative to audio.
I was also surprised at how sensitive my eyes+ears are to relatively small delays in lights versus sound... just dozens of msecs can make it look like the lighting guy is drunk. I know studies have shown that for audio 10 to 20 msecs is too much slop; maybe lighting / sound sync is similar. (I remain puzzled at how light shows can be made to look tightly synchronized at the back of large venues given the big difference between sound and light propogation speeds. ???)
This is interesting. If MIDI file is delayed, and the amount of the delay varies according to tempo, that can only be a factor of the MIDI player, since an audio player has no concept of the tempo of the file it's playing (it just blindly repeats the series of amplitude changes in the file). Furthermore, the delay must occur after the MIDI player starts playing, rather than being a delay required to start playing, which also wouldn't be affected by tempo. If the delay for a given song is consistent across performances, that would also suggest the delay is part of what the player is doing on purpose, rather than a delay caused by a hardware resource constraint, which would probably vary from one day to the next. If the delay were found to be consistent between older and newer devices, that would further support this explanation.
Have you tried turning on Settings > Audio & MIDI > Low-Latency Recordings? (That would also affect the MIDI player.)
Could you try measuring from when you start the playback to when the first MIDI message is sent, with or without a recording playing, and see if the absence of a recording changes anything? (If you use the low-latency setting, and your recording picks up the sound of your finger hitting the screen, you could use that to measure from. Playback starts on touch down instead of touch up with the low-latency setting.)
Quote
I remain puzzled at how light shows can be made to look tightly synchronized at the back of large venues given the big difference between sound and light propogation speeds
That is a good question. I just did a web search and found one explanation, in the Sep 30, 2016 answer on this page:
https://www.quora.com/Do-bands-playing-in-big-arenas-use-their-own-speakers-or-the-PA-system
Quote from: arlo on November 08, 2019, 04:18:33 PM
If MIDI file is delayed, and the amount of the delay varies according to tempo, that can only be a factor of the MIDI player...
To clarify, the delay does NOT vary by tempo in my system. The MIDI always precedes audio playback
(order corrected) by 215msecs regardless of song tempo. Likewise, I must always delay the MIDI file by a net (additional) 100msecs, regardless of the song tempo. What does vary is how that 100msecs translates to some number of 'tics' within the DAW, since those tics are dependent on BPM; but that's just conversion math and not a absolute variable delay.
Quote from: arlo on November 08, 2019, 04:18:33 PM
Have you tried turning on Settings > Audio & MIDI > Low-Latency Recordings? (That would also affect the MIDI player.)
I've never tried the Low-Latency Recordings setting... will check that out. What does that do under the hood?
(Even if it helps, I probably won't use it since I don't want to edit about 60 MIDI files. :P Moreover, even if it results in perfect sync of MIDI and audio from the iPad running BandHelper, I still have downstream lighting delays that have nothing to do with BandHelper that will probably need to be addressed with some relative delay.)
Quote from: arlo on November 08, 2019, 04:18:33 PM
That is a good question. I just did a web search and found one explanation, in the Sep 30, 2016 answer on this page:
https://www.quora.com/Do-bands-playing-in-big-arenas-use-their-own-speakers-or-the-PA-system
Interesting article about synchronizing the lights and sound... I had always assumed the multiple speaker systems in a large venue were synchronized by delaying the signal to 'back of house' speakers, so that the output of those back peakers would match the (delayed) sound of the front stage speakers; and which would not help with the light/sound sync in the rear of the venue. The cited article seems to say all speakers are 'real-time' and the speakers in the back just 'overwhelm' the sound from the front; though that would address the light/sound sync, I'm skeptical that's what's done... will do some more searching!
I'm glad to hear the delay doesn't vary by tempo -- that simplifies things!
What I'm seeing is that it does indeed take a while (tens or hundreds of milliseconds) for the recording to start playing, while the SMF playback starts faster, so the two play out of sync. I'm seeing the same problem when playing a recording at the same time as the tempo. I made a recording of a 90 bpm click and am starting that simultaneously with the built-in tempo at 90 bpm, and the offset is easy to hear.
I think the best next step is to try speeding up the recording playback. I realize this will mess up the offsets you have set up, but I think it's better in the long run to have these items play in sync by default. Then if we need to add a setting to intentionally delay the recording, to account for delays in the MIDI chain, I could do that.
Quote from: arlo on November 14, 2019, 01:53:03 AM
I'm glad to hear the delay doesn't vary by tempo -- that simplifies things!
What I'm seeing is that it does indeed take a while (tens or hundreds of milliseconds) for the recording to start playing, while the SMF playback starts faster, so the two play out of sync. I'm seeing the same problem when playing a recording at the same time as the tempo. I made a recording of a 90 bpm click and am starting that simultaneously with the built-in tempo at 90 bpm, and the offset is easy to hear.
Looking back at my testing around July 2018, that's also what I saw (
in contrast to my incorrect reversed description earlier in this thread which I'll edit to correct): MIDI events are played about 215 msecs before corresponding audio events.
(In the example image below the top channel is the audio file (Recording) and the bottom is the corresponding MIDI event (SMF file) playing a low latency synth. These events line up in the DAW, but played from BH you can see about 214 msecs delta.)
Quote from: arlo on November 14, 2019, 01:53:03 AM
I think the best next step is to try speeding up the recording playback. I realize this will mess up the offsets you have set up, but I think it's better in the long run to have these items play in sync by default. Then if we need to add a setting to intentionally delay the recording, to account for delays in the MIDI chain, I could do that.
That would probably be best for your overall user community (particularly those that use this feature in the future). For me it will still mean converting about 70 MIDI files in my DAW, then reattaching them to recordings, etc. etc. :P But I could get excited about it if you also added a msec-accurate (or at least 10s msec accurate) optional +/- adjustment to relative Recording/SMF timing with (preferably) global effect. As mentioned above, I will still need to add a relative (and constant) offset between SMF and Recording to account for non-BH related downstream latencies for lighting control. (For a 'corrected' BandHelper that eliminated the current 215 msec delta, instead of delaying
MIDI by 100msecs, I'd need to delay the
Recording (relative to SMF) by about 115msecs.) But not requiring the PIA of applying these micro delays to the MIDI tracks within the DAW and instead just setting one value in BH... great!
One other consideration might be how a 'correction' would affect Recording playback timing relative to already implemented Automation events. Changing things a few hundred msecs might not affect things like manually recorded lyrics scrolling synchronization enough to matter, but it could get somewhat bothersome for other kinds of more precise Automation events such as fx patch changes for some customers.
(Also, I'd observed a slightly different kind of offset issue for the very beginning of a Recording / SMF; as you do analysis I recommend you focus on events after the first second or so file to not get fooled by some special cases at file start.)
Good point about the automation tracks. I guess I shouldn't improve the recording playback latency without also offering tools to bring both automation tracks and SMF files back into alignment. (I don't think that's needed for recording+tempo setups because there's no way to delay the tempo playback.)
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. 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. 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?
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.
Quote from: arlo on November 14, 2019, 04:33:14 PM
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.
Quote from: arlo on November 14, 2019, 04:33:14 PM
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.
Quote from: arlo on November 14, 2019, 04:33:14 PM
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 ;D)
Quote from: arlo on November 14, 2019, 04:33:14 PM
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!
QuoteI 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.
Quote(Safest from my "I don't have to write the code" end-user perspective: a plus/minus relative adjustment setting ;D)
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.
Quote from: arlo on November 15, 2019, 12:42:20 AM
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 ;))
Quote from: arlo on November 15, 2019, 12:42:20 AM
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)
Quote
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.
Quote from: arlo on November 15, 2019, 12:30:31 PM
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 :D
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.
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.
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!
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!
QuoteArlo 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.
QuoteBandhelper 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.
QuoteMy 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.
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