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
compiler 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.
fbc8504f9e swapped the iterators: Instead of iterating over output
buffers like BufferSet::read_from(), the new code iterates over
the current buffers. In case of 1 in -> 2 out, only the 1st channel
was be copied. Also unlike BufferSet::read_from() the ChanCount was
not updated.
Processors after a Delivery e.g. out-meter, AFL processor did not see
all channels.
This no longer emits Changed() unless a change was made, and more
importantly, calls AutomationControl::actually_set_value() if
the self-soloed value needs to be changed
Moves global update of solo state and emission of Session::SoloChanged to
a single point after 1 to N solo controls are changed.
Also avoid unnecessarily emitted Activated() signal for listen controls,
though Process::{activate,deactive}() should probably be redesigned to
avoid this in a "deeper" way
Fixes an issue with corrupted std::lists<> due to concurrent writes
to the invalidation list which eventually resulted in
EventLoop::invalidate_request() not invalidating requests.
Concurrency sucks rocks hard.
