A transport-speed-change is no reason to skip processing.
Prior to this change cannot_process() silently skipped in the process
cycle of the speed-change (which may have been every process-cycle),
without moving the transport or doing any processing.
This works around abysmal performance (~.15ms) of
boost::function and boost::bind (in PBD::Signal).
The overall load is probably higher but the realtime
thread remains unaffected.
fixes#6277
This indicates a deeper problem though. Even removing a punch-range never
clears out the events. and ession::process_with_events() does not use
process_without_events() until re-start.
This cleans up a lot of false-positives in static analysis
and also helps compilers to optimize code paths in general.
(tagging the fatal stingstream operator as ‘noreturn’ is
far less trivial)
If enabled, then the button simply changes the behaviour of the "play" button rather than actually starting playback. If disabled
transport behaviour should be unchanged from before.
Keep in mind: While this is the correct thing to do,
it hides another another bug under the hood, related to
_global_port_buffer_offset in MidiPort::flush_buffers.
For debugging the latter issue, revert this.
incoming MIDI data has to be parsed EVERY process cycle, not just when Slave::speed_and_position() is called.
The private MIDI::Parser owned by the MTC and MClck slaves was irrelevant, since the port has its own.
See comments in midi_port.h on the strangled inheritance heirarchy.
commit fdbae82077db53add90df7448a06869dac89acc6
Author: Paul Davis <paul@linuxaudiosystems.com>
Date: Wed Mar 27 21:45:28 2013 -0400
mammoth changes in basic signal flow, total redesign of MIDI channel filtering and more.
commit 59343a8283698e02bc0f622313b29e98f449e4c8
Author: Paul Davis <paul@linuxaudiosystems.com>
Date: Wed Mar 27 01:58:53 2013 -0400
initial working version after changes to MIDI channel filtering. may affect metering input too. testing not yet finished
this commit merges many deep changes in ardour's internal architecture,
combined with a total redesign of how MIDI channel filtering works.
data in a track used to flow from JACK port buffers to diskstream's ringbuffers
and was then copied from the ringbuffers into a BufferSet for use during
Route::process_output_buffers(). The butler thread would handle the movement of
data between the ringbuffers and disk.
with this commit, data now flows from JACK port buffers into the BufferSet used
for Route processing, and is copied from the BufferSet into the diskstream's
ringbuffers (the butler thread continues to handle interactions with disk as
usual).
this change allowed a dramatic consolidation of code and simplification of most
aspects of Track/Route::roll() and Track/Route::no_roll(). in particular, see
Route::fill_buffers_with_input() which now concisely describes how we move data
from JACK port buffers into the BufferSet for all Route types (including Tracks).
this work was initially motivated by changing MIDI channel filtering so that we
can process capture and playback independently. there is now a very clean
pathway for this - see MidiTrack::roll() (NOTE: This needs implementing in the
no-roll case too - a TODO item).
the channel selector for MIDI tracks has been moved out of the track header and
is now accessible via the context menu. more work is likely here, to make it
(more) obvious to the user when filtering is going on.
This reverts commit 13708 -- because it's the wrong approach to fix this.
git-svn-id: svn://localhost/ardour2/branches/3.0@13713 d708f5d6-7413-0410-9779-e7cbd77b26cf
locate() will call realtime_stop which will reset the slave-state.
git-svn-id: svn://localhost/ardour2/branches/3.0@13290 d708f5d6-7413-0410-9779-e7cbd77b26cf
