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

[Stephen S. <rad...@gm...>]

Hi Nick,

> What's nice about this feature is
> that it's an easy way to make sure that the controls on the device are
> consistent with the controls in the software. My own controller has
> this feature.

That's pretty cool, mine doesn't.. ;-)
You're right that LoopDub previously had support for MIDI output.  I
was working a long time ago on getting it to output a MIDI clock
signal, but it never really worked right so I abandoned it.  Then when
I changed from using PortMidi to using RtMidi, the output support
never got re-implemented, so this was a slight regression.  (Slight
because the midi output didn't really do anything useful yet..)

I had never thought of supporting devices which can auto-position
their knobs, but what I did consider and planned on doing sometime
soon was implementing a sort of "pick up", so that when the context
switches (a loop is loaded or program is changed), and the knob and
"virtual knob" become unsynchronized, I planned on having the value
stay put until the MIDI value passes through the position of the
virtual knob, to avoid having values jump all over the place when you
touch a knob.

> Anyway, I have attached a patch to exploit this functionality with
> LoopDub. It does two things. First, it adds MIDI output support to
> LoopDub. (A lot of the infrastructure for this seems to have already
> been present; perhaps LoopDub has supported MIDI output in the past?)
> Second, it adds a new user interface function: when the user presses
> 'S' (for 'synchronize'), CC messages corresponding to the current
> values for all volume and effect sliders will be sent to the MIDI
> output.

Committed.
We'll have to work out, in the future, some way of selecting a device
for CC-output and possibly a different device for clock output.

On the subject of device selection, I still like the simplistic little
panel of device-buttons at the top of the screen, making configuration
really fast, but as features are added, I can see that it may not
suffice for all cases.  It's also sort of a waste of screen-space to
list MIDI devices that aren't in use.. it might be better to have a
single button that cycles through available devices, or something
similar..  I have yet to implement a drop-down menu, but the silly
little GUI system I devised doesn't handle overlapping areas very
well.


> The most obvious way to do this would be
> to have the slider objects themselves send the MIDI messages, but the
> trouble is that they don't know anything about MIDI, being simple
> user-interface objects.

Actually I think it would be better to do this the other way around.
In my experience, moving more "intelligence" to the GUI is usually a
bad idea.  I don't really consider that the controls store the MIDI
values, they only store their own GUI-slider value, which is most
cases is the same as the MIDI-knob value, but, as you point out, can
become desynchronized.  So the problem is that the actual MIDI-slider
values are not really stored anywhere... Perhaps we really need a
separate representation for the MIDI knobs.

One thing to consider is that I hope to eventually cut a lot of the
information that is shared between the GUI and the audio/midi layer.
The end-goal being to eventually run them as separate processes
communicating using some protocol, such as OSC.  I think this would
lead to better performance and better code.  (I've learned a lot about
multi-threading and other aspects of audio software engineering since
I started loopdub a few years ago, and one thing I've learned is that
threading is, in general, a bad idea.  Unfortunately it's all over the
place in loopdub.)

So, with that in mind, I think we should do something similar to what
you propose, but instead of making the LoopOb more intelligent, we
should create a class representing a MIDI knob which lives within the
MIDI-oriented code (ld_midi), and which knows how to synchronize with
particular GUI sliders and also knows when to re-sync the real knobs
or go into "pick up" mode.

With the intelligence in the MIDI code, there will be no need for the
CtrlSource enum.  Knob values sent from the GUI (by mouse movement or
context change) can be directed to the output device (and put the knob
in "pick up" mode), and knob values received by MIDI input can be
directed to the GUI.  These will be in two distinct places in the
code.  If I'm correct, no feedback loop should occur.


Steve