For now we use std::weak_ptr and std::enable_shared_from_this to accomplish tracking. There
may be an argument for using our own (PBD::Destructible) mechanisms instead.
Cairo coordinate/argument limits are much smaller than the canvas. Trying
to clip to a gigantic rectangle throws cairo into a weird state, so
make sure we only clip to a part an exposed area
Methods that have been moved to EditingContext need
to reference the abstract definition there, and PublicEditor's
first parent class also need to be EditingContext (same
memory address)
MIDITrigger now has a direct reference to a MidiModel, and uses
that as the basis for discovering what state has changed and needs
updated after an edit operation pushes a new state to the trigger
Creating an iterator on a MidiModel (Sequence) creates a read-lock on the same,
which exists until the iterator is destroyed.
This new designs renders the model/source to an RTMidiBuffer, then atomically
swaps in a new RTMidiBuffer in an RT context.
Not yet implemented in this temporary branch is handling required
state-changing messages when the buffer is swapped.
84e38b4c65 made the same change for FP16.
It has apparently not been necessary for FP8 so far, because backends
have happened to report "Port 1" before the control port. But that is
not necessarily the case. It failed for me when playing around.
Change FP8 handling to also not make assumptions about the device order
returned by the backend.
These days it only produces false positives (locate at start
of session export).
We leave `ENSURE_PROCESS_THREAD` in place, since it may
come in handy at some point (eg. static analysis, documentation)
previously, _chunksize =
```
minimum_disk_read_bytes / sizeof (Sample)
```
can become larger then actual allocated ringbuffer:
```
audio_playback_buffer_seconds * sample-rate
```
In which case the buffer was never filled.
The disk writer has similar issues
This fixes an issue when undoing region fades.
Particularly but not limited to the following:
1. select a region and split it in the middle
2. switch to range tool. make a range selection across the split
3. Edit > Fade > Fade range seection (or press `/`)
4. Undo
Previously the fade-out of the earlier region was not undone.
When some other transport related session event (anything that
requires non_realtime_work_pending, e.g. PostTransportOverWrite)
coincides with SessionEvent::AutoLoop, the auto-loop event
was removed from the main event queue and executed as one-shot
immediate event.
While looping the AutoLoop event needs to remain on the main
event queue.
`butler_transport_work()` may be called for various reasons,
notably PostTransportOverWrite. At that point in time the
transport may still be rolling or stopping with rtloc already
set.
This can cause DR::Underruns since seek clear the entire
disk reader buffer.
This is needed to properly decrement "should_do_transport_work".
After a seek the DR:_pending_overwrite flag will have been
cleared, so not much extra work happens here.
The left edge of a region on the the editor is rounded to be
on a pixel. When zoomed out, the position corresponding to that
pixel is not usually identical to the region's position().
We need to correct for this as best as possible, while keeping
peaks aligned to pixels.
Previously loop-wrap around asked the butler to perform
a unnecessary seek operation next time it is summoned.
If the butler is then summoned for a PostTransportOverWrite
event, the seek causes a DR::Underrun.
The signal would be emitted while the session was temporarily renamed,
making it appear that we had switched to the new session, despite instructions
not to do so. We had not actually done so, but the saved-as name would show up
on window titles.
Popup Dialog Windows never unset the modal flag.
e.g. Session > Save Snapshot & switch.
Furthermore a 2nd dialog was able to get the menu stuck
forever (e.g. Snapshot & Switch .. -> Replace existing?
In order for the Filechooser Location widget to work two
things need to be setup, which only the FileChooserDialog
does:
* subscribe to Widget's "response-requested" signal
* call should_respond () hook from top-level window's
default handler.
The Location Entry emits "activates-default". In case of
the Dialog, that calls the dialogs response callback,
which then calls ` _gtk_file_chooser_embed_should_respond`.
That handles changes made by the user to the location entry.
-=-
Gtk::FileChooserWidget does not handle this, "response-requested"
signal is not exposed, nor is _gtk_file_chooser_embed_should_respond
available outside Gtk.
This change at least selects the file in the treeview, which
allows further handling, without interfering with FileChooserDialog's
behavior.
This reverts
* e48d97ed69
* 98c906b733
* 0cf73d459b
because the C++ API std::map:at can throw and exception
was not implemented (and also deemed excessive for the
case at hand). Also an explicit API for *p*plugin_pin
mapping is preferable and facilitates debugging.
When handling the `/set_surface` command, the code would set
plug_page_size to the new value first, and call `sel_plug_pagesize()`
later. The latter then sees the page size is already the same, so it
leaves it unchanged and also does not send the page size to the
OSCSelectObserver object. In practice, this means that only the default
plugin page size from the preferences or set with
`/set_surface/plugin_page_size` take effect and values set with
`/set_surface` are ignored.
Exactly the same thing happens for the send page size.
This code has been like this since it was first introduced in comit
9c0f6ea948 (OSC: Allow set_surface to set send and plugin page sizes.,
2017-06-13)
This commit fixes this by omitting the first assignment.
Before this commit, OSCSelectObserver would read the feedback value when
it was created, but then never update it anymore. In practice, the
OSCSelectObserver is created on startup, and when the surface connects
and configures feeback, this value is not applied.
For example, when sending `/set_surface` with a feedback value of
4 (Send SSID as path extension), `/strip/*` would get their ssid put
into the path, but `/select/plugin/*` messages would not have their
parameter id in the path. When setting the corresponding checkbox in the
default feedback preferences, it is applied as expected.
This commit passes the new feedback value to the OSCSelectObserver
instance whenever it changes, which ensures the value is applied as
expected.
MidiTrack::restore_controls is triggered by SessionLoaded
event. Yet MidiControl::actually_set_value checks if
_session.loading() is true and postpones sending actual
events to the synth (which may not be fully loaded).
Before 5d02970de8, Session::post_engine_init unset
"Loading" flag early on, so "loading" was already unset
by the time `SessionLoaded` was emitted.
this fixes issues with MIDI region recording, which otherwise never
goes through the code path required to "fix" the nascent data into
sources and regions.
This fixes a crash at exit for some Linux VST3s when Ardour
calls ::release_factory() before unloading the module.
The plugin will then also call unref the hostContext. Previously
the lookup interface for the host context was provided by the
plugin; which at that point in time was already deleted.
Previously this caused deadlocks (read lock while holding
write lock), and also not dropped references of plugins.
Ideally undo/redo of FX unrelated region state
will not re-instantiate plugins; we can optimize this later.
See also a1ba561cc5. JACK2 and pipewire unconditionally
report 32kB, Ardour internal backends report 8kB, also
independent of the buffersize.
While jack1 by default announces the audio buffersize.
A sensible value assumes that the GUI reads the FIFO at
a least 25fps, while also allowing MIDI ports to merge
data (hence 2 * raw_buffer_size). Yet limit to 64k per track.
Since RegionFx are significantly simpler compared
to processors, missing plugin state can directly be handled
in the implantation without creating a subclass similar to
UnknownProcessor.
Previously there was a race condition. DiskWriter::run()
cleared the gui_feed_buffer before writing new events.
If the GUI thread had not yet picked up the events by then
they were not displayed. Furthermore due to the try-lock,
some events may have been written to the buffer in the first
place.
This fixes missing events (notably stuck notes) in the red
record box while recording MIDI.
_output latency was not used for those. Processor automation
was not affected.
This also fixes the visual offset of automation vs buttons/slider
when the transport is not running.
When removing instances from some RCU managed list or vector,
they can still live on as shared_ptr references on the
RCU's dead wood stack.
In many cases this is not an issue, in these cases it's prudent.
see also 44610c7877
