Lately I have developed a need to use a looper in a live situation with a drummer. Now obviously any simple looper cannot play to the drummer so it’s either the drummer playing to the looper or both playing to some fixed tempo.
What to Sync and Where?
In principle the drummer could play to the looper if two requirements are met. First, he must hear the looper well. This can be achieved fairly easily with proper sound reinforcement. Second, there must be something to play to, meaning that the sparser the loop the greater the demands that are set to the drummer’s internal time keeping. This is clearly doable but may prove to be a little bit difficult.
On the other hand, having a looper in the game in the first place already implies a fixed tempo. Thus it is really no sacrifice, instead of trying to follow the looper, to accept an external click with guaranteed information density (steady notes or even a complete percussion section) and easier audibility (percussive notes in place of some fuzz bass). This transfers the sync issue to the looper being able to follow the external tempo.
There are loopers that can be synced to MIDI clock, which sounds like a nice solution – and costs $$$. However, I happen to already own a looper without the sync capability, the Digitech JamMan, which otherwise is pretty nice albeit old and discontinued. So, instead of rushing to a store, I’ll first investigate this avenue.
The JamMan
First a few words about how the JamMan operates. Assuming the current loop, as shown in the numeric display, is empty, pressing the Rec/Play/Overdub switch immediately starts recording whatever is being fed into the inputs. Another press stops the recording and the JamMan goes to play mode and starts playing the recorded piece of audio from the beginning, in a continuous loop. The length of the loop is automatically determined to be the time from the first press to the second one. Further presses toggle overdub and play modes as long as the loop is playing. In overdub mode the input signal is added to the recorded content until play mode is selected again – even over duration of several loops. Finally, the latest overdub can be undone by holding the Rec/Play/Overdub switch.
Manual Sync?
First test, start a drum machine whacking out a constant beat and try to sync the looper to that. After a small number of attempts it became painfully clear that even though (I think) I have pretty good timing, it is practically impossible to kick the switch so accurately that the loop could remain in sync over more than just a few iterations. This is of course due to the fact that whatever discrepancy there is in the length of the loop compared to the real length of the drum machine cycle, that discrepancy is added to the total error each time the loop passes. Assuming for example a timing error of 10 milliseconds, we get to 100 ms after 10 loops, which is more than a demisemiquaver (eh… don’t you just love these note duration names) i.e. a 32nd note at 120 BPM and very much audible – it’s a delay at that time.
Other Ideas?
Scrap the JamMan? Not yet. It can hold 99 loops. Whenever you select a loop and there is something stored already, the first Play/Rec/Overdub press does not start recording but, instead, starts playback because the recording part has already been done. The loops are stored on a Compact Flash card as mono wav files and the duration of the loop is determined by the length of the file. Yay, suddenly we have a sample accurate means to get the loop length to match to that of the drum machine – as long as the drum machine really plays in the tempo it claims.
So, apparently if I preload a wav file prepared to match the tempo and time signature of the drum machine, my loop should remain in sync as long as the discrepancy of the two unrelated sample clocks allows, and that should be way better that manually (eh… pedally?) kicking the recording in and out.
I first built a little sample wav file in an audio editor to test the theory and, indeed, the 8-bar loop at 95 BPM ran in sync to the drum machine for good five or six minutes before it started to show signs of being off. Now, your exact mileage may vary – there could be differences in the accuracy of the clocks of different hardware and software solutions – but in general this works for a lot longer than humanly possible, and typically for long enough.
Application
Once the concept was verified, I programmed a little utility called LoopBaseCreator (https://github.com/jjrSoft/LoopBaseCreator) to create an empty wav file of given number of bars at given tempo and time signature and even threw in a possibility to change the reference beat duration since e.g. in cut common time it is usually a half note instead of a quarter. The file name by default contains these parameters and they are also written inside the file in a comment chunk (in a future version I should change this to an ID3 tag to the operating system too would be able to show the information).
The JamMan expects the CF card to have subdirectories LOOP01 through LOOP99, corresponding to the loops available. Some folders may be missing if nothing has been stored for that loop. Each folder contains the loop audio wav file, always named loop.wav, and an XML file carrying some attributes for the loop (which are not needed in this application). For the time being the wav file generated with LoopBaseCreator needs to be manually copied to the JamMan’s CF card (just attach JamMan to your computer with a USB cable and it is shown as an external drive) to a suitable loop directory and renamed. I have also been creating a text file named the same as the loop’s original name to help later determining what the loop file contains. The JamMan does not seem to mind having such files floating around in the file system. Probably I should extend the application’s functionality a bit to handle copoying the loops to the JamMan too.
Complications
So, here’s a working trick to run JamMan in sync to an external click without actual syncing for a reasonably long amount of time.
This trick, however, causes minor issues with starting recording and restarting the loop. Recording now requires two presses: first play and then overdub. Since these presses cannot be simultaneous, this means that if you want to start recording, say, from the beginning of a bar, you will have to start play sometime before that. The length of the loop will match but the actual loop will start and end early and the overdub wraps around the end of the loop to the beginning as shown in the picture by the sine wave crescendo. The whole point naturally becomes moot if you can afford the loop to run its full course before hitting overdub but that would be practical only with very short loops.
As long as the loop is running, this does not matter at all because the loop wraps seamlessly and everything is peachy. Stopping, however, is a little limited. The JamMan has two stop modes: stop immediately and play until the end of the loop and stop. The latter mode obviously now stops before the end of the bar, which is probably not what you want. However, you can always just use the immediate stop mode and there’s no major problem.
Restarting is a bit more problematic. Play always starts from the beginning of the wav file. To align the overdubbed loop to the click, you need to start play at the same relative positition it was done in the beginning before overdubbing. For example if you originally started playback on beat 4 and kicked to overdub mode on beat 1, you will need to restart play on beat 4 again and on beat 1 your overdub will play nicely just where it was supposed to. While your timing accuracy kicking the Record/Play/Overdub button will not be any better than what was discussed earlier, the major difference is that the error does not accumulate since the loop length is correct anyway, and thus it is likely that you can do well enough.
There is also an extra complication: when you kick on the playback on beat 4, the playback indeed starts right there and then – from the wrapped end part of the overdub. If this is not desirable, you could add a signal splitter before the looper and and A/B switch after it. This way you could kill the looper signal during the loop tail or – perhaps even better – just leave the loop running and just switch it out of the audible chain. The splitter could be a real signal splitter or a pedal with dual outputs, like stereo or dry/effected. Especially in the latter case that would limit the usability of that pedal though.
Post Scriptum
25-Oct-2018
After trying out the system in a rehearsal, yes, it works. But the ability to keep in sync is very much dependent on which device you are trying to sync to. An old Boss DR-770 could not stay in decent sync probably even two minutes. An Android phone fared much better, pretty much like my test lab results above. So indeed, the mileage may vary.
There are other drawbacks too. Switching to another loop is pretty problematic especially with a syncing scheme like above. Some hardware loopers can eat MIDI clock , which should solve the syncing issue at least partially and that would probably also enable switching loops. Such more advanced loopers do come equipped with a fairly hefty price tag though.
Also, a hardware looper is not able to handle MIDI tracks so (virtual) synths are pretty much out of the game (well, you could always run the synths as audio).
I’ve been dipping into Ableton Live and it is a much better fit for my purposes. Loops always start on beat, automatically, and you can record another loop and come back to the previous one, all in sync. Actually the loops become separate for each instrumental part so you can drop stuff out and back in. MIDI and virtual synths are supported along with audio. With a pad grid device like Novation Launchpad or Ableton Push controlling the loops become fairly easy. You can even automate building the loop if you want to stick to a (partially) predetermined song structure – just swap instruments and continue playing.