Rietveld Code Review Tool
Help | Bug tracker | Discussion group | Source code | Sign in
(1253)

Issue 284280043: Add Staff.midiCC context property, refactor handling of MIDI control changes

Can't Edit
Can't Publish+Mail
Start Review
Created:
8 years, 2 months ago by ht
Modified:
8 years, 1 month ago
Reviewers:
dak, dan
CC:
lilypond-devel_gnu.org
Visibility:
Public.

Description

Add Staff.midiCC context property, refactor handling of MIDI control changes Setting the Staff.midiCC context property to a list of (control number, control value) pairs, where every control number and control value must be an integer between the inclusive range from 0 to 127, will send the corresponding raw control changes to the MIDI output on the MIDI channel associated with the current context. For example, \set Staff.midiCC = #'((7 . 100)) will set the MIDI volume control (#7) to 100. Most of the logic for handling MIDI control value initialization from context properties (in Staff_performer::new_audio_staff), changes (in Midi_control_function_performer::announce_function_value_change), and value conversion for output (in Midi_control_function_value_change::to_string), was moved into the new Midi_control_change_announcer class. All MIDI control changes are now encoded using {Audio,Midi}_control_change items. This change makes the old {Audio,Midi}_control_function_value_change classes obsolete.

Patch Set 1 #

Unified diffs Side-by-side diffs Delta from patch set Stats (+374 lines, -185 lines) Patch
M Documentation/changes.tely View 1 chunk +22 lines, -0 lines 0 comments Download
M Documentation/notation/input.itely View 3 chunks +18 lines, -2 lines 0 comments Download
M lily/audio-item.cc View 1 chunk +5 lines, -17 lines 0 comments Download
M lily/include/audio-item.hh View 1 chunk +4 lines, -27 lines 0 comments Download
M lily/include/lily-proto.hh View 2 chunks +3 lines, -2 lines 0 comments Download
A lily/include/midi-cc-announcer.hh View 1 chunk +64 lines, -0 lines 0 comments Download
M lily/include/midi-item.hh View 1 chunk +13 lines, -13 lines 0 comments Download
A lily/midi-cc-announcer.cc View 1 chunk +139 lines, -0 lines 0 comments Download
M lily/midi-control-function-performer.cc View 5 chunks +43 lines, -35 lines 0 comments Download
M lily/midi-item.cc View 4 chunks +11 lines, -63 lines 0 comments Download
M lily/staff-performer.cc View 4 chunks +40 lines, -26 lines 0 comments Download
M scm/c++.scm View 1 chunk +7 lines, -0 lines 0 comments Download
M scm/define-context-properties.scm View 1 chunk +3 lines, -0 lines 0 comments Download
M scm/lily.scm View 1 chunk +2 lines, -0 lines 0 comments Download

Messages

Total messages: 6
ht
Hi, This patch introduces an interface for adjusting the values of all MIDI controllers responding ...
8 years, 2 months ago (2016-01-16 18:08:08 UTC) #1
dan_faithful.be
On Jan 16, 2016, at 13:08 , ht.lilypond.development@gmail.com wrote: > > This patch introduces an ...
8 years, 2 months ago (2016-01-16 18:50:43 UTC) #2
ht
On 2016/01/16 18:50:43, dan_faithful.be wrote: > On Jan 16, 2016, at 13:08 , mailto:ht.lilypond.development@gmail.com wrote: ...
8 years, 2 months ago (2016-01-16 18:55:29 UTC) #3
dak
On 2016/01/16 18:08:08, ht wrote: > Hi, > > This patch introduces an interface for ...
8 years, 2 months ago (2016-01-21 15:21:22 UTC) #4
ht
On 2016/01/21 15:21:22, dak wrote: > I am not happy about the increasing abuse of ...
8 years, 2 months ago (2016-01-23 17:20:43 UTC) #5
dak
8 years, 1 month ago (2016-01-30 13:16:29 UTC) #6
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.
Sign in to reply to this message.

Powered by Google App Engine
RSS Feeds Recent Issues | This issue
This is Rietveld f62528b