Re: [LAD] Terminology problem

Phil Frost wrote: 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