| Age | Commit message (Collapse) | Author |
|---|
|
|
|
|
|
|
|
Previously Ardour used a /local/ per track vari-speed mechanism.
Now that the disk-reader is a latency-compensated processor, the speed
of each disk-reader would need to be maintained locally, offset by each
disk-reader's output latency. Furthermore each disk-reader may
produce a different number of samples, depending on its global alignment.
This commit introduces port-data resampling directly at the engine-level:
Up/down-sample all input ports at the beginning, and down/up-sample output
port-data using the inverse ratio at the end of the session's process
cycle.
The session itself is unaware of the speed-change, and only needs to
handle transport speeds {-1, 0, +1}.
This also allows for aligned cue-monitoring and vari-speed recording,
and also pitch-shifts synthesized MIDI along.
|
|
|
|
AudioPort::get_audio_buffer() can offset the buffer simply by offsetting
a pointer. This allows to get an offset buffer for a given port.
For MIDI there's no such concept. A method writing to a MIDI buffer
which is backed by a Port can at best offset it by the global port-buffer
offset (static Port::port_offset), but not by the individual target port's
offset.
|
|
Generated by tools/f2s. Some hand-editing will be required in a few places to fix up comments related to timecode
and video in order to keep the legible
|
|
|
|
Should fix a race during Session::destroy(), Port::PortDrop
which unregisters ports with the backend, but the actual port instance
will still exist.
The engine does no longer have a session-pointer and only calls
CycleStart(); CycleEnd() to clear port-buffers. Trying to clear
and already unregistered Port will crash.
|
|
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.
|
|
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.
|
|
|
|
|
|
|
|
|
|
otherwise panic message will be delivered out-of-order when
seamlessly looping.
|
|
|
|
Paul Davis was responsible for introducing almost all of this.
|
|
mechanism away from a 64bit integer and toward std::bitset.
Clean up a few minor related PBD::DEBUG issues along the way
|
|
Probably.
|
|
Best to just do this as early as possible to avoid having to deal with this
situation all over the code.
Also fixes violation of LV2 MIDI specification, which requires no such events
are delivered to plugins.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
track-owned MIDI port buffers (at the Ardour level) get ::flush_buffers() called twice, once by Delivery::flush_buffers() which is called
at the end of MidiTrack::rol() to push data out in graph order, and then finally as a last-chance effort in PortManager::cycle_end().
This should not cause a repeated attempt to write the same data, but it was. Fixed by marking the buffer empty once its data has
been flushed into a backend port buffer.
|
|
|
|
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.
|
|
|
|
start up, disconnect from JACK and then reconnect
|
|
|
|
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.
|
|
git-svn-id: svn://localhost/ardour2/branches/3.0@13896 d708f5d6-7413-0410-9779-e7cbd77b26cf
|
|
We really need some kind of more sophisticated assert macro that can be
switched to non-fatal logging mode for release builds. A log message, which is
often all that would happen, is a lot better than a trainwrecked performance...
git-svn-id: svn://localhost/ardour2/branches/3.0@13892 d708f5d6-7413-0410-9779-e7cbd77b26cf
|
|
extensive testing; remove several unused parameter names
git-svn-id: svn://localhost/ardour2/branches/3.0@13810 d708f5d6-7413-0410-9779-e7cbd77b26cf
|
|
also fix a bug that led to messages about notes already being on at program start because of a double seek with no read in between
git-svn-id: svn://localhost/ardour2/branches/3.0@12762 d708f5d6-7413-0410-9779-e7cbd77b26cf
|
|
git-svn-id: svn://localhost/ardour2/branches/3.0@11983 d708f5d6-7413-0410-9779-e7cbd77b26cf
|
|
git-svn-id: svn://localhost/ardour2/branches/3.0@11906 d708f5d6-7413-0410-9779-e7cbd77b26cf
|
|
commit; separate numbering of aux sends, sends and listens to fix #3671 (still testing, but the assert failures are critical)
git-svn-id: svn://localhost/ardour2/branches/3.0@11263 d708f5d6-7413-0410-9779-e7cbd77b26cf
|
|
git-svn-id: svn://localhost/ardour2/branches/3.0@11005 d708f5d6-7413-0410-9779-e7cbd77b26cf
|
|
git-svn-id: svn://localhost/ardour2/branches/3.0@10179 d708f5d6-7413-0410-9779-e7cbd77b26cf
|
|
git-svn-id: svn://localhost/ardour2/branches/3.0@9772 d708f5d6-7413-0410-9779-e7cbd77b26cf
|
|
fault :D
git-svn-id: svn://localhost/ardour2/branches/3.0@9654 d708f5d6-7413-0410-9779-e7cbd77b26cf
|
|
output ports can resolve any notes currently playing (2) remove MidiStateTracker from MidiPort and use a fixed set of MIDI messages (sustain-off and all-notes-off, per channel) to do note resolution (3) move note resolution caused by a LoopEvent psuedo-event to within the main MidiPort::flush_output() loop, so that we resolve (turn off) Notes that come before the loop point, rather than send them out after the note resolution messages
git-svn-id: svn://localhost/ardour2/branches/3.0@9635 d708f5d6-7413-0410-9779-e7cbd77b26cf
|
|
git-svn-id: svn://localhost/ardour2/branches/3.0@9628 d708f5d6-7413-0410-9779-e7cbd77b26cf
|
