On Sun, 28 Feb 2016 16:05:55 +0000 Harry van Haaren <harryhaaren@xxxxxxxxx> wrote: > On Sun, Feb 28, 2016 at 12:19 PM, Johannes Kroll <j-kroll@xxxxxx> wrote: > > 1) is what I would prefer, and probably easiest to implement. > > The issue with having direct control over the loop length is that > if the control is changing gradually (easy to happen if automated), > the loop will no longer line up with the beat properly. Which would be kind of the point of an un-synched mode. Desync would only happen when a user disables the Sync parameter. If a user changes the new BPM control gradually by hand or via automation, the loop will also no longer line up, and lose sync. By having control over BPM *and* sync on/off, there would be a wider range of possible Time values, while still having essentially as fine-grained, or coarse, control as one wishes. That's why I'd have preferred that. Maybe if you'd still want to implement the desync option... Anyway, it's your software, if you don't, I won't bother you anymore :p One things I noticed with the new code, pulled just now: The GUI BPM Control is 40 to 240 now (cool, thanks!) but the parameter is still 60..180. I think it's in masha.ttl. (Aside: One parameter is called Pass in the GUI, but Dry/Wet Mix in the parameter description. I think Pass fits better.) _______________________________________________ Linux-audio-user mailing list Linux-audio-user@xxxxxxxxxxxxxxxxxxxx http://lists.linuxaudio.org/listinfo/linux-audio-user