Re: Looper developer looking for opinions on some interface questions

[Michael Tyson <michael@atastypixel.com>]

Thanks, Per!

> If I understand your concept of "count-in" it is equal to what Ableton
> Live and the pioneering looper EDP calls Quantization? I.e.
> quantization of the execution of a command, not quantization of audio
> playback.

That's it, yep!

>> As loopers, what do you think is a reasonable approach to begin 
>count-in, and specify an auto-end length?
> 
> I'd prefer a different general approach; Not specifying an auto-end
> length for the first loop you create, but rather setting the loop
> point on the fly by the second tap.

> 
> Any chance for additional features like "instantly multiply/divide
> loop length" by a factor of 2 o 3?


Ah, that's my mistake, I forgot to mention some basics - there's so much 
in my head at the moment, it's hard to figure out what needs to be 
mentioned =)

The main detail I missed was that tracks don't all have to be the same 
length - they're quantized (integer multiples, or power-of-two fractions) 
against the master loop length, which is set by the initial recording.

Put another way, the first recording sets the master loop length (and if 
you set the BPM beforehand, that loop length will be 'quantized' to 
multiples of bars at that BPM).    Subsequent recordings on new tracks 
will be quantized to integer multiples of that original loop length 
(including 3, 5, etc), or power-of-two fractions (1/2, 1/4, 1/8, etc).  
So, you set up the main loop length with the first recording, but then 
after that, subsequent recordings are automatically quantised to 
whatever's closest.

So, a diagram of an example:

Main loop length, set with 1st recording: 
[================================]
Next recording on another track (Quantized to 2 * main loop length)
[================================================================]
New recording on a third track (Quantized to 1/2 main loop length)
[================]
Overdub recording on third track - Kept at same length
[================]


The "count in" (or command quantization) feature would thus link the punch 
in time to the start of the next "master" loop.  The auto punch-out would 
link the punch out to the end of the following master loop - the 
alternative is that the recording just keeps on going until you stop it 
manually, at which point the loop length will be quantised to however many 
multiples of the master loop you recorded for.

The exception is if you're overdubbing onto an existing track, of course, 
in which case the recording will wrap to the track's length.

Forgive the floundering about with the language - I'm quite new to the 
looping world, and my terminology is no doubt entirely wrong =)



> 
> 
>> One option I'm considering is tapping with 2 fingers, anywhere on the 
>track, to come in at the start of the next loop.
>> 
> 
> That's great idea!
> 
>> From there, there are two options: Either auto-punch out at the end of 
>the loop (1 loop cycle), or just keep on overdubbing until tapped to 
>finish.  Is one better than another?
> 
> Both are common and useful looping actions. If I had to chose one of
> them I would definitely chose "keep on overdubbing until tapped to
> finish". The result of "auto-punch out at the end" can be reached
> anyway by tapping any time before the loop point.
> 
> The situation I can imagine where "auto-punch out at the end " would
> be almost "a must" is when working with extremely short loop length to
> achieve a glitchy sounding texture.


Excellent, that's good to know - that's the default, then.


> 
>> I'm thinking about being able to specify how long you want to record 
>for, as well, maybe via successive taps - so, for example, if one tap 
>could start at the next loop, and keep recording until you tap to stop, 
>then *two* taps tells the app to come in at the next loop, and then 
>record for one loop.  If you tap 3 times, then that means come in at the 
>next loop, then record for *two* loops, and so on.
>> 
>> What do you think?  Does that work?  Is it viable, in a performance 
>environment?
> 
> To me it sounds too complicated. I would prefer simply setting loop
> length on the fly as you close the first loop by setting its loop
> point -  and have Loopy adapt to the set loop length for the rest of
> the session.
> 


I'd be interested to hear your thoughts on this again in light of the 
extra description of how loops are setup (and the fact that loops can be 
different lengths to each other).  I love the simplicity of having just 
one loop length for the auto punch-out - so that it works like a simpler, 
single-loop-length looper - but I'd really like to find a sensible way to 
provide advanced users with the ability to set up lengths that are 
multiples of the master for the auto punch-out, if it's feasible.

Thanks again, it's great to have some new eyes on this stuff =)

Michael