bodde:
I guess I belong to the loop tweaker group! So now you can only use other resolutions besides OCTAVES after you have recorded the initial loop (?). It would be better I think if the resolution state could be saved on the preset. Cause now when want say SMOOTH each time you have to first record the loop and then change the resolution to SMOOTH. When you empty the loop you have to do it all over again.
I'll give this (saving the resolution) another think, I didn't think it was possible at first, given the design constraints, probably for some good reason that I knew about then (when I was in the thick of it), that I've since forgotten. If it comes to me, I might put it in an update, but it probably won't be anytime too soon.
bodde:
One other thing: when recording a tempo loop of 8 beats say with two chords from each 4 beats (as an example) when I change to 1/2 speed after I recorded the loop it only loops the first chord (4 beats). When you change to 1/4 speed it only loops the first two beats. On all other loopers I have it loops the whole recorded loop and not half the loop when you go the 1/2 speed. Why is this? Does it have to do with the maximum loop time? Is it only behaving like this in tempo mode?
First of all, yes, this will ONLY occur in Tempo mode as long as you're not dubbing. If you dub in Tempo Mode, it will go the whole loop length at the slower speeds. (of course this is all in the help file too).
The reason for this had more to do with locking to MIDICLK than anything else. We figured the loop would be locking to a beat or MIDICLK that had a solid outside notion of downbeat and phrase length (in beats), and that this "ground truth" downbeat was agnostic to the speed of the loop. So, we wanted to make sure the original downbeat of the loop always stayed true. This was the only way to guarantee a beat-lock, because, if you set it to speeds that don't evenly divide the original length and the let the whole length play out the loop will get out of time quickly.
Of course, we didn't want the dubbing to be constrained by this Playing feature, so we allow it to dub through. I also figured dubbing was was the way to get the loop to go out of time if you actually wanted it to do that.
Since there is really no difference between Tempo Mode and MIDICLK following (Tempo Mode w/o MIDICLK just uses the internal MIDICLK) this carries over even when you're not slaving to MIDICLK. I honestly didn't have time to come up with a third mode, Tempo Mode using internal MIDICLK, that would do something different.
All that said, If there is enough support to make it do something different we will, of course, consider it. I can possibly imagine some compromise where we let it play through all the way on evenly divided loop lengths, but it all gets pretty complicated when you start making too many special exceptions.
