| Age | Commit message (Collapse) | Author |
|---|
|
|
|
|
|
* Processor implement get_state(), classes derived from Processor
implement protected ::state() -- as documented in processor.h
* likewise for Route, Track: make ::state() a protected interface
* removal of "full_state", use explicit "template_save"
* use RAII/Unwind to skip saving automation-state
|
|
gui_feed_buffer is used for DiskWriter -> GUI notifications.
It was wrongly migrated from MidiDiskstream to DiskReader in 7fb6807
|
|
- Fix API call to add region(midi_region) -- set count to "1"
- Forward DataRecorded() signal
- remove botched merge/rebase"
a4a87f56 accidentally brought back code from old-destructive API
which was removed in af103cf3 and 08c13007
There is no per track NonLayered record mode anymore, it's session global.
- set can_record correctly to not accidentally clear last capture sources
for cont'd recording (toggle track's rec-arm)
|
|
Immediate events are used for MIDI-Panic and to inject GUI generated
events e.g. patch-changes, note-events from the track-header
(scroomer-keyboard) and patch-change audition.
Current behavior:
- snapshot copy immediate events from ringbuffer into a buffer at
the beginning of each the cycle.
- Inject immediate events into input-buffer directly after reading the input
- process "normally"
- pass immediate event-buffer to disk-writer, so it can skip them
(don't write immediate events to disk)
- if the Route is not monitoring input: clear buffer before disk-reader
and re-inject (original) immediate events after the disk-reader
- immediate events process normally and are also sent to outputs.
|
|
Currently ::roll() may actually be a ::no_roll() under some circumstances.
This can also happen during count-in:
transport_stopped () == transport_rolling()
and during latency-preroll:
Global session-transport speed != 0, some tracks already roll,
read data from disk and feed latent plugins.
but other non-latent tracks or busses don't roll and still have to
behave like the switch from no_roll() to roll() has not yet happened.
This changes the game WRT to monitoring as well, previously, Route:roll()
called Route::no_roll_unlocked () for conditions outlined above.
Now Track::no_roll_unlocked is called and in some cases wrongly clears
the buffers before the signal hits the disk-writer. (more work is needed
related to 61f8e53b)
On the upside this also fixes an issue with MidiTrack::no_roll not keeping
a lock while pushing data into the step-edit-ringbuffer.
This is also a step towards consolidating all entry points:
::roll(), ::no_roll(), ::silent_roll() in the Route class.
|
|
|
|
We want Track to shrink, and logic consolidation is always good. Route already knew about
disk_reader and disk_writer, now it knows about _monitoring_control too
|
|
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
|
|
|
|
|
|
|
|
|
|
separated disk i/o changes.
THIS WILL NOT RUN. THIS REQUIRES MANY CHANGES
|
|
|
|
|
|
There are no float <=> string conversions and they are all now performed using
PBD::to_string/string_to via XMLNode
|
|
These were changed in the XMLProperty ctor and they now match the names used in
MidiTrack::set_state()
|
|
|
|
|
|
|
|
|
|
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.
|
|
void to bool, to indicate if value was changed."
This reverts commit c104c9d4726f3ba1ecd352d13b88a57f2f964510.
|
|
bool, to indicate if value was changed.
Don't call Session::set_dirty() when no change occurs
|
|
|
|
Route::no_roll(), Route::roll(), Track::no_roll(), AudioTrack::roll()
and MidiTrack::roll() all had the exact same loop for flushing buffers
of their Delivery processors. That was a lot of replicated code that had
to be kept synchronised by hand. Put that code into a protected method
Route::flush_processor_buffers_locked() which is called instead.
|
|
|
|
Pass current (latency compensated) cycle times to plugin.
This fixes time-reporting to plugins and also fixes automation
and when bouncing (the session->transport* is not valid) etc.
|
|
|
|
remote control ID and "order keys" have been removed.
|
|
|
|
and used. The controls now own their own state, rather than proxy for state in their owners.
Massive changes all over the code to accomodate this. Many things are not finished. Consider this a backup safety commit
|
|
Route now calls back into Session when solo/mute/listen state changes. All other interested
parties must use the Route::{solo,mute,...}_control()->Changed() to be notified of changes.
The Session requires more information than the Changed signal can provide, in order to
propagate solo/mute changes across the entire Session correctly.
Note that this uses an experimental use of CRTP to isolate a public API within Session
|
|
|
|
|
|
|
|
AutomationControl for track monitoring choice
|
|
|
|
This also removes Route::group_gain_control() and associated machinery.
Not yet tested with Mackie or other surfaces. More work to done to
start using the group capabilities, and also potentially to add
or derive more controls as RouteAutomationControls
|
|
|
|
well, now...
- Midi-Ports have a midi-buffer.
- Midi-Tracks have a midi-buffer.
- Midi-tracks have a diskstream.
- Midi-diskstream has a midi-ring-buffer.
- Midi-tracks have a delivery
- The delivery can get a reference to the actual backend-ports
- The delivery calls the Midi-Port's flush() buffer to send out queued events
at the end of a cycle
all clear ? :)
- when splitting the process-cycle: only the Ports are informed.
all other objects see a "normal" short process cycle starting at "0".
The offset needs to be applied early on, so that internally routed buffers
push the event at the correct time when combining the buffer with
immediate and async events.
Luckily Port::port_offset() is a static member, available to all, objects,
which allows to bridge the conceptual gap between the diskstream and
the delivery.
There's a snag:
When there's a note-on directly at the beginning of the loop it coincides
with the panic message sent when looping.
The panic comes before note events, so it *should* be good.
Also the final note-offs (state tracker end of loop/region) are sent
1 sample too early (smells like an off-by-one), and are hence dropped.
(no matter we send a panic right after it).
It should really be at the same time, just before the panic.
|
|
AutomationControl::writable() and use them.
Classes derived from AutomationControl now check ::writable() in their ::set_value() methods to ensure that they
do not attempt to overwrite data sent to them while automation playback is underway.
|
|
|
|
Paul Davis was responsible for introducing almost all of this.
|
|
assert in ARDOUR::MidiRegion::control() boost::shared_ptr<ARDOUR::MidiModel>::operator-> invalid ptr.
see http://pastebin.com/dTV10Zu6
|
|
If a "CC" automation lane was visible at least once, a Control Object
is created and henceforth saved with the session:
<Object id="automation TrackID TYPE" ../>
It is currently not possible to remove this object. (Automation > clear
will only zero all events, but not remove the Control itself.
The bug:
After showing a MIDI-CC lane at least once Events are sent for this CC.
If there is no corresponding value in the .mid, it will be zero after
session reload.
see also 7e2c8ac
Still ToDo: "Show existing automation" shows the lane even if there
are no values nor any automation at all for the given CC.
|
|
(old gcc has a built-in)
|
