This was just a proxy for libs/evoral/evoral/Event.h. Note that the #define
that controlled allocation that was at the top of the removed header is
replicated in the Evoral header, so there are no semantic changes
This fixed a false-positive "ambiguous latency" warning for
MIDI busses:
MIDI track -midi-> MIDI Bus w/instrument -audio|midi-> master
The master-bus only has audio inputs, so the MIDI Bus'
MIDI out is left unconnected. Its latency does not matter,
it can float freely.
Previously it was assumed to be zero. So the MIDI Bus' input
playback latency range was [0, master-bus playback-latency].
jack2 can process in parallel with calling a graph-order or
latency-callback, so Ardour takes a lock to update those in sync.
Yet jack2 can also block while port-registrations happen,
and concurrently emit latency-callback from another thread..
Port and connection changes always imply a latency_callback from
the engine. Worst I/O latency is updated directly in
Session::update_latency() which is called from
AudioEngine::latency_callback.
Explicit subscriptions to route->output()->changed() is not needed
to update the worst I/O latency.
Only set_block_size() needs to to update the I/O latency when
the buffer-size changes.
The backend may call update_latency() while at the same time
the auto-connect-port calls set_worst_io_latencies().
The latter already holds the process-lock, so update_latency()
first needs to acquire it, as well. If one already holds the
_update_latency_lock, one must not ask for the process-lock.
---
Previously Ardour's connection manager first took the process_lock
and then waited to the _update_latency_lock.
Meanwhile jack calls latency_callback(), takes the
_update_latency_lock and waits for the process_lock.
Classic deadlock.
LV2 plugins may add a MIDNAM file when they're loaded.
This can be happen concurrently with the MidiPatchManager,
loading the system-wide patch files.
Session load should not be interrupted by the initial
background scan of patch files, which can take a very long time.
We need to allow update_custom_midnam() to grab the _lock.
Various backends have different strategies for updating latencies,
and different thread semantics for latency update callbacks.
With jack2 it is possible that processing happens concurrently
while port latencies are being changed.
Ardour internal backends emit the latency callback from the
main process thread, serializing latency changes with processing.
Various user actions can also trigger latency changes. e.g.
with a stopped engine it is possible to re-order plugins.
The semantics are that if the user configures things to allow transport commands while
using a transport master, issuing such commands first stops using the master
Auditioner seek calls are explicitly handled by the butler,
and DR:overwrite_existing_buffers() is called explicitly
to read MIDI data for audition.
Session::non_realtime_overwrite is no longer required.
This reverts commit 6fbcf83779
and parts of 2d11667ce3.
The Auditioner is not part of the session route-list and the
auditioner route's I/O latency is never updated.
Session::process_audition() does not handle pre-roll either,
so it need to be zeroed, otherwise Route::roll skips samples.
This has lead to initial samples being skipped, IFF the
auditioner's output-port had non-zero latency.
Since private port-latencies are usually only set for routes
in the route-list, and _remaining_latency_preroll is reset
at transport-stop, this *usually* worked...
Last but not least, MIDI notes need to be resolved when seeking.
IO::latency iterates over the port-set retrieving the
private_latency_range of each port. Since it can only change
when connections and latency changes, we can instead cache the value.
This is also in preparation to allow the auditioner to override it.
DiskReader::seek() no longer fills MIDI buffers.
MIDI is now read into memory via DR:overwrite_existing_buffers()
There is still some edge-case remaining to be fixed. For
some reasons the synth does not receive initial patch/program
changes when starting auditioning.
update_custom_midnam() is usually called from the GUI or butler
thread when a LV2 plugin is instantiated, or the plugin changes
its MIDNAM. It must be exclusive with load_midnams_in_thread()
and calls from MTAV to ::maybe_use().
- add missing translations
- largely follow original message regarding punctuation, capitalization
at the beginning of sentences, trailing white space
- fix typos and other obvious mistakes
Signed-off-by: Nils Philippsen <nils@tiptoe.de>
This fixes Virtual-keyboard velocity selection when scrolling
to numbers that are not explicitly in the menu-list.
(hopefully this does not introduce some recursive signals
for other ArdourDropdowns, fingers crossed).
Since 57118c2370, plugins are re-activated after every export.
So a silent pre no-roll is mainly useful for with realtime export,
and for some cases where a plugin does not correctly reset.
Note that for the first export, plugins are not currently flushed.
add methods to callback.js
automatically reconnect js client on disconnection
mixer-demo do not recreate UI on reconnection
NO-OP: indentation in message.js
make client JS reconnection optional
fix mixer-demo scrolling
minor JS client refactor
improve mixer-demo readability
This allows "stacking" of bindings by desensitizing the actions associated with a "lower" level
of bindings at certain times (e.g. MIDI editing bindings thare are sensitized in the appropriate
editing modes
Cairo::curve_to renders cubic Bézier splines, those are not
generally useful in a DAW context.
Canvas::Curve implements centripetal catmull-rom spline drawing
which can be used for fades and automation interpolation.
This adds a basic support to use multiple sound-cards, currently
limited to two devices: In/Out with shared settings.
Advanced setups still have to resort to using the ARDOUR_ALSA_EXT
environment variable
This apparently happens on some Windows systems when exporting
a range starting at 00:00:00:00
I'm still hoping there's a better fix for these race-condition
issues, perhaps by kicking the TFSM...
When running from the src-tree, ardev_common.sh sets multiple
data-paths, to allow running ./ardev ./gtk2_ardour/ardev.
Pick the first one that contains a "web_surfaces" subfolder as
docroot.
This picks up where cfd95340b1 left off.
The goal is to ensure that the butler has completed all
PostTransportStop related tasks and won't meddle with transport
after exporting has started.
Previously this could happen, because realtime_stop() queues
PostTransportStop and the butler is sommoned after every
export process cycle.
Since 61e7f3176b the butler keeps calling non_realtime_stop()
every time it is woken up, until TFSM comes around and unsets the
flag in the process callback.
This cuts reverb tails and synth sounds after export.
Disabling freewheeling, continues normal processing where
export left off. This previously kept notes ringing, or reverbs
audible.
The actual issue was introduced in 61e7f3176b:
Session::non_realtime_stop() no longer unsets PostTransportStop
(other changes from that commit are not relevant).
The real issue however is a race-condition.
So far this only seems to happen on MacOS, Coreaudio.
It seems that non_realtime_stop() is called in the butler-thread
after exporting has started, even though the butler has been
paused in wait_until_finished().
Perhaps Coreaudio thread switches causes TransportFSM to
reinitialize and scheduling the butler?
The use of `usleep()` makes this rather a workaround.
However it's sufficient for the coreaudio rt thread to run
at least once.
Port (or Tracks) can be safely added during playback, however
the disk-reader's playback buffer is initially empty. This lead to
false-positive Underrun() signals when processing takes place
before or concurrently with re-filling the disk-buffer for the new
channels.
Now new empty buffers are ignored, and produce silence until the
initial refill is complete. There is however no per-channel
de-click in, yet.
This fixes: play some audio track, ctrl+drag a region to the
drop-zone, creating a new track while playing.
Main features: Plugin (Select & Edit)
1. Plugin Select: When a track is selected that has PluginInserts, pushing the "Plug-In" button on a mackie will list these across the strips. Clicking a vpot of a strip enables editing the parameters of this selected plugin.
2. Plugin Edit: When a Plugin is selected for editing, the input parameters of the plugin are shown across the channel strips and the vpot is assigned the corresponsing AutomationControl for the parameter.
Minor features
- When the number of plugins or the number of parameters exceeds the number of strips available on the surface, one can flip through "pages" of views using the Cursor Left and Right keys (this logic I took from http://www.emagic.de/media/support/content/manuals/LogicControl_en.pdf)
- When in the Plugin Select mode, rearranging the plugins in the mixer strip is reflected on the surface.
- When in Plugin Edit mode, rearranging the plugins in the mixer strip still retains the edit view of the selected plugin (rearranging does not take away the current subview)
- When removing a plugin in the mixer strip, this is reflected in Plugin Select, while the view jumps to Pan/Surround (the None subview) when in Plugin Edit mode.
- Removing a track resets the subview to None
- When in a Subview that is track-specific (Track, EQ, Send, Plug-In, Inst), selecting a different track retains the subview but updates the channel displays and vpot assignments accordingly. When in Plugin Edit mode for track A, and track B is selected, it changes to Plugin Select mode for track B (if plugins are present).
