Re: Add Staff.midiCC context property, refactor handling of MIDI control changes (issue 284280043 by address@hidden)

[dak]

Ok, let's get the show back on track.

We have two things to figure out here: do we want this stuff to even run
through properties of any kind?  And if so, how?

One thing that properties are likely not good for is continuous changes
of Midi controllers.  Now the Midi format itself is not good for that
either I think since controllers will need explicit setting to every
value they are to assume (correct me if I'm wrong), so there will be
timing impact and granularity to to such changes, and any continuous
control process would need to figure out whether to change controllers
in time for each new note event, or even trigger timing on its own.

If we are going by properties: how many continuous controllers are
there? 128?  How about biting the bullet and creating properties cc0 to
cc127 then?  That's the simplest way forward.

The next more complicated way forward using properties would be,
basically, mostly a paradigm change: most of the code, I think, is
there.  It would basically declare that selected context properties
(which includes the defaults for all grobs) are managed with a "property
stack" (which basically is what ly:make-grob-properties creates) and
afterwards are accessed using \override/\revert (which can set and reset
subproperties as well).  The tricky detail here would be how we prevent
the use of unpure-pure-containers for midi properties: straightforward
callbacks seem fine.

Yet another way forward would be to extend set/unset to deal with
subproperties.

And while we are at it: this is one instance where I'm somewhat envious
of Lua which has as its sole data structure the "table", an associative
array that can be indexed with either strings (all of which are interned
in Lua and thus are equivalent to symbols) or numbers, with an array
part starting at index 1 being available for O(1) non-hashed indexing.
If that were the form of our nested alists, subindexing via a controller
number would be trivial.

As it is, I'm afraid that the first variant will likely have to rely on
_symbols_ for indexing.  (string->symbol "42") can actually be entered
directly as #{42}# (a rather weird syntax, and from LilyPond another #
would need to be prepended).  In order to mask the details from the
user, I can try to provide an input syntax for that that will convert
numbers in symbol lists into the respective symbols at first (maybe
we'll be able to let them stay numbers in some later stage of the
implementation).

Another possibility is to just allow a property to be a vector, and let
subproperty accessors interpret numbers as indexes then.  I'm somewhat
iffy over how to implement \temporary \override on that basis, though.
But it's probably doable.

I'm also iffy about indexing from the LilyPond side: it seems to me like
indexes should run starting with 1 so that I can write stuff like

violin = #(make-vector 2)
violin.1 = { ... }
violin.2 = { ... }

With 0-based indexing, this would have be either
violin = #(make-vector 3)
or
violin.0 = { ... }

neither of which feels convincing.  Unfortunately, Midi controllers are
numbered 0 to 127 while Midi Channels are numbered 1 to 16 (even while
represented by 0..15 in the Midi messages).

So, uh, big can of worms here.  I'd like to see it eventually opened
because it seems useful to have vector subproperties, but for your
immediate needs, I think going via dedicated music events (and
performers for them) would likely be the sanest path for now, also
allowing for a strategy for continous changes at some later point of
time.

https://codereview.appspot.com/284280043/