towards fixing #6238 and #6096.
GUI thread:
#2 Glib::Threads::Mutex::Lock::Lock
#3 Evoral::ControlList::eval
#4 Evoral::Control::get_double
#5 ARDOUR::AutomationControl::get_value
#6 ProcessorEntry::Control::control_changed
..
#15 PBD::Timer::timeout_handler
at the same time: Audio Thread (try-lock, fails)
#0 Evoral::Curve::rt_safe_get_vector
#1 ARDOUR::Amp::setup_gain_automation
#2 ARDOUR::Route::process_output_buffers
Due to the failed try-lock.. AMP::_apply_gain_automation
is false. and Amp::run() uses a different gain factor.
-> click.
Mixbus in particular uses both types of tooltip so we might as well make them look the same.
N.B. The appearance is fine now on Windows but needs to be tested on the other platforms (i.e. some tweaking might be necessary).
All canvas objects share just one tooltip object which is based around Gtk::Label. The Label expands if the current tooltip text is wider than the previous text. However, it doesn't shrink again if the next tooltip has shorter text. Eventually, this results in some very strange looking tooltips (especially in Mixbus where they're used quite extensively).
Deleting the object after use will force a new object to get generated next time (at the correct size). There's still only ever one object per canvas but it's no longer persistent.
This reverts commit 6ba555c2f5.
which does not yet take monitoring states into account.
Ideally the case handled here should not happen in the
first place, It should be fixed in session_transport
transport_sub_state.
If there's port-latency > period-size, there is a
split cycle with (this_event->action_frame - _transport_frame).
Yet Session::check_declick_out() keeps PendingDeclickOut if
StopPendingCapture is set. The route declick’ed twice:
Once with the period-size and one with the remaining frames,
which resulted in a click.
fixes various fader zipper noise issues.
It voids sample accuate fader automation (the fader-gain
is low-pass filtered at 10Hz). Yet all musical purposes this
makes a lot more sense than sample accuracy anyway.
This does NOT work with MIDI files at present, because of SNAFU in SMF class, where end_write()
opens the file on its own, without _file_path being set. Needs some careful work, because basically
the SMF<=>SMFSource relationship is not tenable
* don’t allow to rename read-only sessions
* prevent periodic save (while rename is in progress)
* no renaming while actively recording (peak files
among other things will mess things up)
Lock was not held across a replace_{tempo,meter}() operation because of re-use
of {remove,add}_{tempo,meter}. Moved functional code into _locked variants so
that replace operation can hold lock across its entire active lifetime.
Made correct error handling for cases we didn't see before.
Removed redundant and experimental code I forgot to remove months ago.
Added debug output which will help in future testing
Conflicts:
libs/ardour/ardour/audioengine.h
libs/ardour/engine_state_controller.cc
libs/backends/wavesaudio/waves_midi_device.cc
This works around a bug in OnsetDetector.
It requests a buffer of 1114 samples but later FFT
bails out if the buffer size is not a power-of-two.
Also large buffersizes fail.
Work-around: use ADAPT_ALL_SAFE (no buffersize
adapter), use a reasonably small buffersize.
The current settings work, even though it produces
the following warnings (vamp-plugins/OnsetDetect.cpp)
WARNING: OnsetDetector::initialise: Possibly sub-optimal step size for this sample rate: 512 (wanted 557)
WARNING: OnsetDetector::initialise: Possibly sub-optimal block size for this sample rate: 1024 (wanted 1114)
This commit should be reverted once VAMP/QM/aubio
is updated/fixed.
Technically it doesn't make much difference but from what I can tell, the only files which #include 'gtk2_ardour/gui_thread.h' are the source files from gtk2_ardour itself. The support libraries always #include 'gtkmm2ext/gui_thread.h' directly (which seems sensible). So for consistency's sake, let's keep it the same for libcanvas.
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.
Add "PERFORMER" to the exported .toc & .cue files based on the value of the
"album_artist" metadata field, and also use the value of the "album" field
for the TITLE if is set, falling back to the session or range name if it is
blank.
Invalidate all source entries from the image cache when we get our
region's DropReferences signal, while ignoring any subsequent regions with
no source.
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.
<oofus> rgareus: pre fader sends are not really used
for FX sends, they would either be sending to other
busses or to something like headphone/cue feeds.
You don't want those mixes having stuff muted in
them as you are muting you main mix.
ignore non-plugin processors for OSC
/ardour/routes/plugin/parameter
fixes issue with hidden internal processors. (rec-en
track adds a hidden [meter] processor at the top,
internal returns on busses have returns etc.)
Add an option to insert new routes at the top of the list ("First").
Reorder/rename the entries in the dialog.
Session's _order_hint is now the signed int it always wanted to be.
Fixes bug #6179. Top vs. bottom seems pretty arbitrary to me, and this solves
the obscuring issue (which is quite common since there are often PC events at
the start of MIDI files), so bottom it is.
When building with MSVC, some libraries had PROGRAM_NAME set to "Mixbus" and PROGRAM_VERSION set to "3". Whereas other libraries had PROGRAM_NAME set to "Mixbus3" while PROGRAM_VERSION was an empty string.
I've a horrible feeling there must have been a reason for this but I can't quite think what it was. Hopefully though, this change will standardize everything.
this is not a fix yet, just some comments and
code cleanup done while reading/investigating:
* limit reads to available write-space
* skip inactive tracks
* handle potential unsigned + negative value.
This breaks the build for windows builds that don't use the pthreads_win32
library. Using the opaque pthread_t type like this is probably not a great
idea. Using PBD::pthread_name is another option that I've used elsewhere
that seems more useful.
For some backends the process thread can change (e.g.
switch coreaudio headphone + internal speakers)
If there are existing x-thread event calls this can lead to
the following situation:
1) SessionEvent::operator new
2) audioengine process thread change
3) SessionEvent::operator delete -> crash, wrong thread
SessionEvent::operator delete can safely push the event back to
the pool for later cleanup..
Summary:
* use mmap() for the whole peakfile instead of lots of small seek/reads
* cache the computed peaks
* where possible, open files with O_NOATIME.
In summary:
* no antialiasing of waveviews
* no diagonal lines
* simplify clip detection
* don't use LINE_CAP_ROUND for outline
* use the wave colour when drawing outline only
Add a function TempoMap::meter_section_at(), similar to
TempoMap::tempo_section_at() but returning the meter section at the given
position, and use this to make editing meter changes from the main clock
work on the meter that's in effect at the current position.
The only user (matrix) does not care which bundles are added/removed.
This simplification will make it a lot easier to keep bundles
in sync with actual hardware ports.
Before this, LV2 preset deletion in Ardour was doubly broken: the wrong file
was being removed, and removing the correct file would only result in a broken
preset. This change uses a new version of Lilv which has a more sophisticated
mechanism for preset deletion.
Also, fix "clashing" presets saved with the same name for different plugins, by
prefixing the plugin name to the bundle (this is now a recommendation in the
LV2 preset specification).
* allow to change buffersizes
* subscribe to buffersize & samplerate changes
* add support for half-duplex devices.
* aggregate Devices (not yet used) code from JACK2
* unify deprecated API wrappers
* properly keep track of MIDI ports
* disable MidiI/O during freewheeling
* various small fixes & cleanup
This avoids stuck notes if active notes are edited, but without stopping all
active notes in the region on any edit as before.
This implementation injects note ons in places that aren't actually note
starts. Depending on how percussive the instrument is, this may not be
desired. In the future, an option for this would be an improvement, but there
are other places where "start notes in the middle" is a reasonable option. I
think that should be handled universally if we're to do it at all, so not
considering it a part of this fix for now.
Towards putting more advanced logic here, where two copies of everything will
get even more hairy.
The two cases of reading from one or many regions are not very different in the
read phase, the only difference is the target. So, point a reference to the
appropriate target, use the same read code in either case, then sort/etc
afterwards only if necessary.
(hopefully) fixes export randomly stalling on windows:
dequeue_request() was a single request (no queue) on Windows.
Butler::queue_request() is called
-> Butler goes to work..
-> while working, another request is queued
-> butler never sees this
-> deadlock
during Freewheeling/Export wait_until_finished()
waits for the 2nd request to be handled, and never returns.
MidiPort::cycle_end() was never called, hence after the
first cycle all midi buffers were assumed to be
“mixed down” already.
this fixes
Midi-track 1 -[midi]-> Midi-track2 synth -[audio]-> out
on export.
Ardour calls input_streams(), output_streams() to determine
if the plugin is about to be re-configured (old stream I/O count
!= new I/O count) and emit PluginIoReConfigure() if that’s true.
If the plugin has not been initialized (no format set), we can
safely assume that it will need to be reconfigured.
Forcing Audio=Midi=0 will do so.
The only time where the format is not yet set and hence the actual
channel count is still unknown) is during the first call to
PluginInsert::configure_io().
At the time of writing, this all is a NOOP anyway! The only user
of the PluginIoReConfigure() signal is the GUI to update connection
lines… and since the first PluginInsert::configure_io() happens
during insertion before the plugin is painted and subscribed to
PluginIoReConfigure(), this function could return any value.
Still 0,0 is just more appropriate than assuming mono audio in/out
and no midi.