On Sun, 28 Feb 2016 16:05:55 +0000
Harry van Haaren <harryhaaren@email-addr-hidden> wrote:
> On Sun, Feb 28, 2016 at 12:19 PM, Johannes Kroll <j-kroll@email-addr-hidden> 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@email-addr-hidden
http://lists.linuxaudio.org/listinfo/linux-audio-user
Received on Mon Feb 29 16:15:01 2016
This archive was generated by hypermail 2.1.8 : Mon Feb 29 2016 - 16:15:02 EET