Notably ... reading from MidiRingBuffer into MidiBuffer includes the event size,
rather than relying on the MIDI bytes to determine size. This isn't required
for MIDI, but is a more portable design for other event types.
The compiler can rearrange class layouts in memory, which defeats
the entire purpose of using the zero-sized array hack, as well
as causing problems with pool allocators/intrusive refcnts
I'm not sure if this is really the best way to do event types (should it
just be a completely static enum in evoral, or completely dynamic and
provided by the type map, or a mix like currently?), but previously the
event type was frequently set to either total garbage, or parameter
types, which are a different thing.
This fixes all those cases, and makes Evoral::EventType an enum so the
compile will warn about implicit conversions from int.
It is slightly questionable whether type specific methods like
velocity() belong on Event at all, these may be better off as free
functions. However the code currently uses them as methods in many
places, and it seems like a step in the right direction, since, for
example, we might some day have events that have a velocity but aren't
stored as MIDI messages (e.g. if Ardour uses an internal musical model
that is more expressive).
In any case, the former inheritance and plethora of sloppy casts is
definitely not the right thing.
Windows key generates Mod4+Super (at least with the version of Gdk we use on
linux) so for bindings using the Windows key to work, GDK_SUPER_MASK has to be
added to modifier mask.
- quarter note precision is greater than the frame-based
_position. using it as a reference may cause a rounding error
if the region is locked to MusicTime.
- also fixes a _start position bug when trimming midi regions.
- we really need a better api for this kind of thing.
- in combination with the previous two patches, this should fix
various missing first note issues.
This allows to flush an async MIDI port's ringbuffer at cycle-start,
to makes its data available as "input/source" during process(), while
collecting data in the background for the next cycle.
This facilitates virtual MIDI Ports for eg. Control Surface Pads:
output from a surface, input to Ardour channels.
eg. import a .mid that has a CC later in the file.
Arodur wrongly added an initial point, effectively moving the event
backwards to "0" (no virgin territory)
