Some builds of glib on macOS end up delivering IO_PRI when IO_IN is also set. This differs from our own build stack
version, but it isn't really an error, so we should handle it.
This partially reverts 2edbda2526.
Using cairo-groups increases performance on MacOS, and retains
retina-resolution.
However it adds a performance regression for MS Windows graphics
rendering. cairo-groups use a "similar" surface, not an image surface.
Empirically this adds significant overhead compared to rendering
using the CPU and using bitblt.
This reverts commit af30a6f001
because it breaks OSX/MacOS builds:
libs/surfaces/mackie/mackie_control_protocol.cc:945: error: 'G_SOURCE_FUNC' was not declared in this scope
Session::TransportStateChanged notifies about transport stop before the stop is complete (i.e. at the start of the declick).
Various other objects (notably control surfaces) connect to this signal and use it to modify their displayed state.
We need a method that can tell them we are stopped (or stopping) even though we are not "fully" stopped yet. This is
that method
This is similar to sort(1) --human-numeric-sort,
as opposed to naturally_less() negative numbers, hex-prefixes
and SI metric prefixes are taken into account.
For MacOS/X this is equivalent, rendering happens using a
CGBitmapContext + image-surface. Windows and Linux needs profiling
for respective equivalent surfaces.
This is an intermediate commit, before replacing image surfaces with
cairo pattern groups.
The eventual goal is to reduce flickering and/or use
CPU + bitblt for specific widgets instead of cairo
graphics-cards accel.
This also removes excessive calls to getenv() for every rendering
operation.
This might fix a "SessionHandleRef exists across session deletion",
when the shared_ptr was be pushed onto a x-thread pool, and not
invalidated in time before the session was closed.
destroy_sources () is only called from Session::remove_last_capture ().
The list of sources to be destroyed is the local scope of that method
and will hold a reference to the object.
copy-construct the list and removing elements one by one from the
copy is only unnecessary overhead.
This allows to indicate that a control should by default be displayed
inline in the mixer-strip.
Previously that was hard-coded for and enabled for send-level
controls only.
Even though the method that is overridden (shared_ptr<t>::operator=),
has that signature in modern boost, it's of no real significance
for the case at hand (ExportChannel, ExportTimespan)
While loading a session XML state, set_state must use
`Stateful::loading_state_version`.
When later copying processor state,
`Stateful::current_state_version` is correct.
We don't really need to do this if the bounds have moved "outwards", but
at present we don't know if that is the case, so be safe and resolve in
case the loop bounds moved "inwards" and we would otherwise get stuck notes
caused by the now-missing noteOffs
At least on my machine, the fonts on the Push display were ridiculously large,
making everything overlapping and unusable. I suspect this is because
pango_cairo_font_map_get_default() inherits DPI from the system, so the
monitor scaling factor got applied to the Push display as well.
This commit instead creates a new plain font map, and sets the resolution to
96, which looks like what the UI was designed for. Some more tweaking of the
Pango context might make things more optimal on the Push, but just setting the
resolution makes things look reasonable to me anyway.
It's long been a guideline (and IIRC a Weff-c++ warning) that either all, or
none, of the copy methods should be defined, but this became a standard warning
in GCC9. Presumably to account for a later language change though I'm not sure
which.
I don't remember why the ChanMapping copy constructor can't just be a simple
copy (it's just a map of POD), but figure it's safer to just copy what that
does.
This also solves bi-stable automation for plugins where latency
can change due to automation. e.g.
cycle 1: run (t): automation (t) = on: -> increase latency
cycle 2: run (t-latency): automation (t-latency) = off -> decrease latency
repeat.
The file_sample[AUDIO] member was not updated to reflect the last-read sample in the
switched-to buffer.
Also move several methods and members from DiskIO to DiskReader where they belong.
With inclusion of Mp3FileSource, this would get tricky.
On MacOS, the SndFileSource's sf_error_str message is never displayed,
anyway, also calling methods all handle failed-constructor.
So error-log is less important.
Declare DoubleArray in GUI context so that runtime uses the symbol
from the .exe (not the .dll).
This is mainly for the benefit of MSVC, that does not allow to use
LuaBridge_API in .exe
This fix ensures that the a-fluidsynth "synth" object is not used in two
threads at the same time during midi event handling (run() in RT thread vs.
load_sf2() in worker thread), which could result in crashes.
Ardour only saves Config when the session is saved.
When changing the VST Path and starting a plugin-scan the newly
discovered plugins would otherwise not be avalable unless
the session is explicitly saved after a scan.
Session::process() can call split-cycle which offset the
buffer pointers. When vari-speeding at speed > 1.0, the
engine also splits the cycle every n_samples, to not exceed
the configured buffersize. This needs to take prior buffer
offsets into account.
find_next_ac_event, needs to find the next event *after* (but not
at) start.
std::upper_bound returns an iterator pointing to the first element
in the range [first, last) that is greater than value.
This is equivalent to using std::lower_bound an iterating until
finding the first element greater than.
Ardour 6 internally always runs at speed 1.0 (or -1.0, or stopped 0.0).
There is no vari-speed that scale "BPM" or "n_sample" time progression
per cycle.
Instead Ardour 6 vari-speed mechanism transparently re-samples I/O.
So process-time is scaled only relative to wall-clock time.
From a plugin's POV this is similar to "freewheeling": The plugin
processes data as if the host plays at speed 1.0. While the host
plays this data at a different rate.
Some plugins may like to be informed about the host's actual
playback rate.
Currently this is mainly for the benefit of github.com/x42/repitch.lv2.git
Previously setting a boolean-control to "write" and roll did not
create an automation-point.
The state was not correctly captured.
The boolean-control needed to be toggled explicitly to create
an automation point.
When locating while writing automation, begin a new write-pass,
and add a guard point at the locate target position.
NB set_in_write_pass takes 3 arguments: (write_enable, add_point, when)
the last two default to false, 0.
103ef2ba08 introduced an API to write raw data (const void*)
to a child process, along with the previous API to
write (std::string const&)
VideoMonitor uses write_to_stdin("fixed text"), and g++
interprets this to use the (const void*) API instead
of the std::string, which breaks communication.
Pre-roll to fill buffers only needs to be done once when starting
to play or when locating.
Seamless looping just continues. Every processor takes the loop
position into account locally.
We never stopped the transport, so there's no reason to start it again. Doing so causes alignment problems
because all tracks have their ::run() ranges reinitialized
When looping, we do not want to resolve notes at the end of the loop via ::realtime_locate() -
::get_midi_playback() has already taken care of this. But when not looping, we need this. So,
add an argument to tell all interested parties whether the locate is for a loop end or not
When looping, we do not want to resolve notes at the end of the loop via ::realtime_locate() -
::get_midi_playback() has already taken care of this. But when not looping, we need this. So,
add an argument to tell all interested parties whether the locate is for a loop end or not
Although at the Session level we never run "through" the loop end,
latency compensation means that that start/end sample values passed to
Processor::run() may cross the loop end. Fix how we handle this so
that we do not read data from after the end of the loop
Split cycles are run as if they are an entire self-contained cycle, starting at zero and running for "nframes".
We adjust the timing and position of data only when retrieving and writing it to Port buffers.
All _immediate_events data gets written to the output buffer at the end of the current (split) cycle anyway, so the
timestamp is irrelevant (as long as it is zero, and will therefore be read by ::snapshot_out_of_band_data()
This fixes an issue with existing MIDI routing between MIDI tracks
and/or busses. Automatic MIDI connections should only dis/re-connect
ports that are explicitly configured in Preferences > MIDI Ports
and leave all other connections alone.
This is made possible by knowing that it is never called upon to read across
loop boundaries. The session splits the process cycle for the end of the loop
