| Age | Commit message (Collapse) | Author |
|---|
|
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)
|
|
|
|
|
|
This moves MIDI channel filtering into a reusable class and moves filtering to
the source, rather than modifying the buffer afterwards. This is necessary so
that the playlist trackers reflect the emitted notes (and thus are able to stop
them in situations like mute).
As a perk, this is also faster because events are just dropped on read, rather
than pushed into a buffer then later removed (which is very slow).
Really hammering on mute or solo still seems to produce stuck notes
occasionally (perhaps related to multiple-on warnings). I am not yet sure why,
but occasional beats always.
|
|
Fixes bug #6166 (except record).
This attempts to follow the "current" control value somewhat aggressively:
* On locate, slider is set to the value from the top region at the new
transport position.
* Playback or MIDI input is followed "live".
* Whenever the slider is moved (including automatically), that value is emitted
as an immediate event to keep external gear in sync.
General idea is that the Ardour slider should act as a mirror of an external
hardware knob, and both should be synced to whatever the control is at the
current transport position. Since we lack real playback/touch/etc modes for
these for now, we must choose one behaviour, and this seems like the most
reasonable one.
Follow is handled in the audio thread, which is probably not ideal, but since
these controls have no lists and do not record, should be fine. Probably.
|
|
Fixes bug #6206.
|
|
diskstream reads directly from port, Route
use prefilled buffer-set.
|
|
operation is undefined. C works on all platforms
|
|
|
|
Among other things, this means that automation controls/lists have the actual
min/max/normal/toggled of parameters, and not those inferred from the Parameter
ID, which is not correct for things like plugin parameters.
Pushing things down to the Evoral::ParmeterDescriptor may be useful in the
future to have lists do smarter things based on parameter range, but currently
I have just pushed down the above-mentioned currently used attributes.
|
|
Reference : https://bugs.webkit.org/show_bug.cgi?id=59249
|
|
Work towards ParameterDescriptor being used more universally to describe control characteristics.
|
|
conditions
|
|
Allow controls to work without a list. see also 34c1465 and b469cd2
|
|
Also some work towards tolerating automation controls with no automation list,
towards actually doing something for these cases, though not required just to
fix this crash (MidiTrack::set_parameter_automation_state() avoids those
paths).
|
|
amend to 8f52bf7d9f
|
|
|
|
|
|
platform-neutral solution (MOTE - 'llabs' and '::llabs' are being used successfully in other parts of Ardour)
|
|
|
|
|
|
|
|
|
|
fixes
* http://tracker.ardour.org/view.php?id=5628
* http://tracker.ardour.org/view.php?id=5561
|
|
|
|
|
|
|
|
|
|
|
|
see http://www.oofus.co.uk/ardour/Ardour3MonitorModesV2.pdf
the overall logic can probably be simplified somewhat
track-rec-enable on -> always monitor input
|
|
if meter==input, meter depends on In/Disk
see also 29108187ed
|
|
Route::Auditioner. this has been the meaning of these terms for years now and it would be better to make it explicit
|
|
was completely broken because of the use of absolute floating point comparisons for time comparison, and serialization/deserialization of patch change property changes was borked because of int/char conversions by stringstream. Note undo/redo would fail for note removal if a note had been moved and/or had its note number changed as the next operation after it was added, because time-based lookup would fail. Similar small changes made for sysex messages, which just needed the musical_time comparisons and nothing else
|
|
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.
|
|
Completely eliminate static MIDI controller name code.
Reduce dependency on midnam_patch.h (which would have saved me several hours if I did it earlier).
Store controller name numbers as an integer.
Keep controller names in a map keyed by int instead of a list for fast lookup.
More cleanup of MIDI::Name code.
git-svn-id: svn://localhost/ardour2/branches/3.0@13927 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
|
|
of piano roll whether rolling or not
git-svn-id: svn://localhost/ardour2/branches/3.0@13679 d708f5d6-7413-0410-9779-e7cbd77b26cf
|
|
git-svn-id: svn://localhost/ardour2/branches/3.0@13646 d708f5d6-7413-0410-9779-e7cbd77b26cf
|
|
i.e. treat MIDI tracks just like audio... needs feedback from MIDI users (also #5060 reporter)
git-svn-id: svn://localhost/ardour2/branches/3.0@13602 d708f5d6-7413-0410-9779-e7cbd77b26cf
|
|
git-svn-id: svn://localhost/ardour2/branches/3.0@13253 d708f5d6-7413-0410-9779-e7cbd77b26cf
|
