Apply CUE option to input change

josh

The more I spend time experimenting with GTL, the more it feels crucial to me that ultra-fast switching between loops and settings is possible, and that the switching of settings is precisely timed.

I‘m not an experienced looper, but it seems that „traditional“ looping with foot pedals often works like the following:

- Record a loop
- Let the recorded loop play while preparing the next to-be-recorded loop (change input, clock setting, effects, etc.) — I‘m gonna call this a „filler“ playback for now

This repeats again and again and again, and it makes performances very repetitive and thus boring, as performances seem to be double as long as they are interesting.

The advantage of a 2-dimensional, scrollable touch screen and freely configurable keyboard (and midi) bindings over traditional looper pedals, combined with CUEing those configuration changes, is that the preparations for recording the next loop can be done within fractions of a second, usually while recording a loop, and thus removing the need for those „filler“ playbacks between recordings.

GTL already provides all the basic framework to make this possible. But the fact that changing inputs cannot be CUEd, makes it literally impossible to effectively record one loop with e.g. a guitar and instantly record another loop with e.g. the microphone. So still a „filler“ playback is needed between them.

Instead of making CUEing available to input change, another (and IMHO better) option would be to let each loop be assigned a dedicated input in advance (before recording a loop with it). This would be similar to applying AUv3 effects (which ought to be possible already in newer versions of GTL, AFAIK).

After playing around with GTL for some days now, I see a huge potential in it, compared to traditional foot pedals. Playing fast-paced and complex songs like „Road Trippin“ by RHCP seems realistic to a one-man-band, playing different instruments like guitar, bass, strings (using a guitar, maybe even a small midi piano, and AUv3 effects, e.g. Tonebridge) and singing in harmony with yourself (for repeating parts of a song).

Keep up the good work, Jack! You‘re creating something really special here with GTL! :-)

Jack

A good argument Josh, I agree the best aproach would be to assign specific inputs to individual loops. This would require a complex input mixer/router and the appropriate UI for managing it. It’s a big job, I’d love to see it incorporated in the future.

josh

I‘m glad that I seem to understand things correctly and that you get my point, Jack.

I see that such a feature is a massive effort. Maybe adding support for CUE when changing input would be a good interim solution?

I don‘t really see why it would make any sense to change the input during recording of a single loop anyway. Maybe changing input would always be applied only on recording the next loop, regardless of CUE being on or off?

josh

Or let me rephrase this last bit:

When recording a loop, its input remains the one that was set when recording started. Changing the input while recording a loop would set the system setting (and be applied to the next recorded loop), but NOT the input of the currently recorded one.

Would this break any existing behavior or workflows of users?

Jack

It’s a nice idea but I don’t think it will be possible to make this work reliably enough. Timing the switching of inputs is not an easy solution either, direct routing of input channels to loops is the way to go in my opinion. It’s on the to do list, hopefully I will be able to make it happen this century...

josh

I‘m sure you know best what‘s possible and what‘s not. I‘m looking forward to the clean implementation some time in the future then... :-)

I played around a little bit more, and I found that my idea of recording both channels (guitar and mic) into the same loop, then panning hard left (or right, depending on whether the loop should play the guitar or the mic) would work pretty well. I would then do this for *every* loop, so input would never need to change anymore; this way, recording a guitar loop, immediately followed by a mic loop, wouldn‘t be an issue anymore.

For this to work though (as I don‘t have a device with a midi knob for panning), the „Set pan to X“ keyboard binding is necessary. It would also be essential that the pan could be set already when CUEing a loop, so I can bind it to the same keyboard key like CUEing the next recording. Otherwise I would have to do it manually after the recording has started already, with an additional keyboard key. This leads to the question whether all loop settings should be editable already before recording anyway (like AUv3 settings seem to be)?

One side-effect of recording both channels, then panning hard left (or right), compared to recording only one of the channels, is that it will be played back also panned hard left (or right), instead of centered (as it happens when recording MONO). For busking with a small amplifier, the difference doesn‘t seem to be relevant though.

Jack

I’ve been thinking about adding the ability to set volume, pan, effects before a loop is recorded. Not in the next update but soon hopefully.

Have you considered muting the mic or guitar before you record? For example, use a switchable microphone. It’s unlikely you would need to mute the guitar as there would be little spill over but a tuner pedal would do the job if you needed to.

josh

that would be very useful in many respects, like adding some filters in advance (e.g. a hi pass for a picking pattern and a low pass for a bass line) which would enhance sound quality immensely in a live context. sure, auv3 could do that already, but i like the idea of having some basic tools available by GTL itself.

i have a mutable microphone. didn’t think about this yet. still, it would be a poor man‘s workaround, and pretty finicky. but thanks for mentioning, it might come in handy some day.

josh

I played around a bit more with it. Apparently, while it's not yet possible to apply any volume or panning before recording a loop, it's available as soon as a recording is CUEd. This is good news, as it allows to create a MIDI binding like:

(Assuming CUE is toggled on, input is set to 1+2, and the clock is set to the wanted length)

For q:

Go to loop 1
Record
Pan hard left (mic)

And for Shift+q:

The same, but pan hard right (guitar)

And for Alt+q:

The same, but without panning (recording both mic and guitar)

For, w, Shift+w, Alt+w, e, Shift+e, Alt+e, r, and Shift+r, Alt+r, similar bindings (for loop 2, 3, and 4) could be defined.

So for me to make fast and reliable switching between inputs possible, only the "Set pan to X" binding for keyboard needs to be added. Sure, a "real" routing would be even better, but the explained workaround would bridge the gap until then.

Combined with bindings for jumping between groups (~ for master, 1 to X for group 1 to X), with only a few keystrokes I could switch incredibly fast between groups, loops, and inputs.

josh

it’s great that i can change inputs using keyboard bindings.

although when recording one loop (guitar) then immediately following recording another loop (microphone) it’s very crucial to switch input perfectly between the two. otherwise there may be artefacts.

alas, it would be cool to have the CUE option for this too.