Re: [Loopdub-devel] Synchronizing MIDI controls with LoopDub

[Nick T. <nh...@gm...>]

On Dec 29, 2007 10:33 PM, Stephen Sinclair <rad...@gm...> wrote:
> Hi,
>
> I'm afraid I don't have time to give you a point-for-point answer
> right now.  I've thought about it a bit, but in fact I think a lot
> better about these things in C++ rather than in english, so I started
> coding a little to see what issues might arise.
>
Okay, I read your code, and it mostly makes sense to me. One question:
I can't seem to discern the purpose of NEEDSYNC. What is it used for,
precisely?

> I would be interested to know what you think, and how it differs from
> your approach.
>
The main difference (aside from what I address below) is that your
approach keeps things more cleanly separated: it keeps the MIDI
business with the MIDI code, without getting it mixed into the
LoopObs. I understand what you're trying to do there, and I appreciate
it. The counterpoint, of course, is that your approach adds a new
class, whereas mine does not. It's a trade-off; at this point, I don't
feel strongly either way.

> There are only two points in your message that I think I disagree
> with.  First is the necessity of handling this corner case where the
> user unplugs a MIDI cable and reattaches it.  I have little interest
> in handing that case -- if the user is doing such a thing, he'll
> expect things to go strange, and a key command 's' to re-synchronize
> manually is probably sufficient, as we have now.
>
That's a reasonable position to take. I think I agree with you, actually.

> I think it is quite dangerous to assume that all CC messages will be
> exactly 1 tick apart.  You mention yourself that it won't handle the
> button case -- there may be other cases where the user wants to set
> everything to a particular value.  (Loading a preset for example.)  My
> idea for 'pick up' was to only enable that state when a sample is
> loaded (i.e., the 'internal' case, a context change.)  It might also
> be useful for when the user moves a slider, but again, this state is
> deterministically available to the program and doesn't depend on the
> difference between two successive CC values.
>
Good point; I hadn't thought of it that way. However, your solution
(only enabling pick-up after an internal control change) is still only
a partial solution. Suppose that I have a non-auto-syncing controller
with buttons on it being used for CCs, specifically for feedback. The
feedback on a loop is set to 0, and the button is off, thus
effectively also being "zero." Now I move the feedback slider in the
GUI, setting it to 32. This is an internal control change, and it puts
my button in pick-up mode. My button goes to 64 when I turn it on, and
0 when I turn it off, so I can never get to 32. I'm stuck in pick-up
mode; my button is rendered useless. This same situation will happen
in any case where we have a control move in a non-stepwise manner when
the control is in pick-up mode.

The essential problem here is that it just makes no sense to have MIDI
pick-up for a controller that can move in a non-stepwise manner; the
two concepts are mutually exclusive, since one is designed to avoid
jumps in control values, and the other inherently results in jumps in
control values.

Two solutions to this problem occur to me. One is simple, one is
complex. The simple one is to just outlaw non-stepwise movement of
controllers. This might be good for a first step.

The complex solution is to allow pick-up to be disabled selectively.
That is, it can either be disabled for individual controls, or for all
controls at once. The first case is for non-auto-positioning
controllers that have MIDI CC buttons on them. We disable MIDI pick-up
for the buttons, and leave it enabled for the sliders and knobs. The
second case is for auto-positioning controllers, which have no use for
MIDI pick-up. The reason it is necessary to disable MIDI pick-up
entirely for these controllers is the possibility of loading presets
on the controller; this results in jumps in all of the control values,
and would create conflicts if there were pick-up on any controls.

What about loading presets on non-auto-positioning controllers? Trick
question; it's not possible, because the controls have to be manually
positioned. In more general terms, the sliders and knobs on
non-auto-positioning controllers must move in a stepwise manner; they
inherently cannot have jumps in their values. Therefore, there will
never be any issues with pick-up on these devices. (On the other hand,
I suppose it's possible that there exists a device with an internal
mechanism for auto-positioning the controls, but no mechanism for
controlling this through MIDI. However, I seriously doubt that such a
device exists.)

As I said before, I think that, for now, we should simply not support
non-stepwise movement of controls. We can add support for that later,
but for now let's focus on getting the basic pick-up and sync working.

Now, getting back to the design. If we outlaw non-stepwise movement,
then there's no need to have a special mode for pick-up; we can simply
have it on all the time. (In the future, it will either be on all the
time or off all the time, depending on static configuration). This is
the only change that I would make to your design at this point.