On Sun, 28 Feb 2016 16:05:55 +0000
Harry van Haaren <harryhaaren(a)gmail.com> wrote:
On Sun, Feb 28, 2016 at 12:19 PM, Johannes Kroll
<j-kroll(a)gmx.de> 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.)