[LAD] Terminology problem

[Krzysztof Foltman]

Phil Frost wrote:

>> Now, what do I call the first dimension, *before* specifying what 
>> channel I'm talking about? How do I address "the Volume CCs of all 16 
>> MIDI channels", or "the PFL buttons of all mixer strips?" I'd like a 
>> short, logical, non-confusing name for this, but I can't seem to 
>> think of one.
> Parameter?

Attribute? (not to be confused with Buzz attribute, which is something
totally different)

Property? (both OO-lovers and OO-haters would perhaps hate me for it)

Setting?

Control/controller? (it might even reuse CC messages in case we use
something similar to my fixed-size 8-byte MIDI Port record passing
scheme - or control port numbers and extended record, just some ports
would be flagged as "permits 2D addressing", you know what I mean?)

Control sink? (that's just bad, too COM/DirectShow/GStreamer-like)

Multifunction aftertouch? (that's bad as well, but I'm hoping to seed
some ideas here)

Articulation?

I still don't think we know enough about different ways of doing
per-note addressing, by the way, how the parameter numbers are presented
to the host, if they should be the same parameters than normal ones or
different, per-note parameters...

Or how the "final" MIDI port spec should look like, either.

<threadjack>

And I think it should be decided on rather sooner than later, because
otherwise Lars' first proposal
(http://ll-plugins.nongnu.org/lv2/ext/MidiPort/) will become the
de-facto standard - and while it's definitely a good start, some very
simple improvements have been already proposed:

- aligning records to 4 bytes (so that we don't have unexpected crashes
on SPARC machines etc)

- using 16:16 fixed point values instead of doubles (I've proposed an
int, but 16:16 looks better)

- float-typed control port value changes, to replace or supplement the
outdated NRPNs - there are at least two flavours possible; the first one
is adding extension record consisting of 32-bit int for parameter number
and 32-bit float for parameter value, the second one is by reusing ctl1
and ctl2 or cmd and ctl1 of the basic event for LSB and MSB of 16-bit
control port number, and adding an extension record consisting of 32-bit
float. In fact I can think of a third one - giving both new float value
and the per-sample increment, so that a linear change of a parameter
over time can be communicated to a plugin. So we'd have:

  struct MIDIRecord {
    uint16_t timestamp_samples;
    uint16_t timestamp_fract;
    union {
      struct {
        uint8_t cmd, ctl1; // use when flags&1 == 0
      };
      struct {
        uint16_t param_num; // use when flags&1 == 1
      };
    };
    uint8_t ctl2; // reserved when flags&1
    uint8_t flags; // bit 0 set iff float extension record follows, bits
4-7 contain the second part of the "2D address" tuple
  };
  // this follows the MIDIRecord is expected when flags & 1
  struct MIDIRecordExtFloat {
    float new_value;
    float new_delta; // typically 0 unless we have a very smart host
that does parameter smoothing :)
  };

Any unsolved problems and counterproposals?

- and, maybe in the same spec, maybe in a "sibling" extension, the
per-note control ports/2D addressing we're talking about now (I've
included my 2D addressing solution in the proposal above, but I have no
idea if this particular approach is OK for anyone else than me :) ).

</threadjack>

Krzysztof