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)
- when the timeline displays many bars, zoom/autoscroll
speed is improved by calculating the bbt ruler scale first
then requesting a suitably scaled grid.
This can occur when the MIDI readahead time is too low and events get
pushed into the MidiRingBuffer after the corresponding read. In this
case, skip_to() gets called (as it does before every read) and the
events are silently dropped.
This is a Very Bad Thing(TM), so warn about it. I am not sure which
other scenarios can skip events that aren't problematic, but there's
probably some. A more sophisticated detection/reporting (or maybe even
dynamic reconfiguration) scheme would be nice here, but some false
positive messages are at least better than silently failing to play
notes and the like.
cc121.cc: In member function 'void ArdourSurface::CC121::encoder_handler(MIDI::Parser&, MIDI::EventTwoBytes*)':
cc121.cc:413: error: ISO C++ says that these are ambiguous, even though the worst conversion for the first is better than the worst conversion for the second:
/usr/include/architecture/i386/math.h:343: note: candidate 1: double pow(double, double)
/usr/include/c++/4.2.1/cmath:357: note: candidate 2: float std::pow(float, float)
shared_ptr<Port> now uses a deleter functor which pushes Port* to a lock-free FIFO so that the Port is
always deleted (and thus unregistered with the PortEngine/backend) in a safe context w.r.t. various
callbacks in the host. Currently the auto_connect_thread in Session has been tasked with doing these
deletions.
If some plugin-internal state changes (GUI <> Plugin e.g. load a sample)
no ports change and the host does not know that the plugin state has
changed. The session may be closed without save.
This is a prototype using an ardour.org URI, pending upstream lv2plug.in
