| Age | Commit message (Collapse) | Author |
|---|
|
|
|
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
|
|
|
|
Inform plugins about host theme (fg, bg colors) and UI scale-factor.
The latter follows an implementation already present in Carla and DPF.
These extension use proposed official URLs.
|
|
This allows mono to stereo plugins to override the default
routing and forces both outputs to be connected.
|
|
|
|
|
|
Fix space-alignment, mostly due to "frame" -> "sample" changes.
|
|
|
|
This has been superseded by value_as_string() along with meta-data
from parameter-descriptor, which is supported by all standards, except VST.
|
|
Plugins are only a source of Latency (Plugin delay).
The API to query, signal and override Latency is managed
by PluginInsert.
|
|
This keeps track of lv2:Parameter properties modified with Port:Set,
currently file-paths.
|
|
|
|
* dedicated API for classes (effect, instrument, util)
* prepare for tags (rather than categories)
* prepare removal of per-plugin in_category() API
|
|
* Processor implement get_state(), classes derived from Processor
implement protected ::state() -- as documented in processor.h
* likewise for Route, Track: make ::state() a protected interface
* removal of "full_state", use explicit "template_save"
* use RAII/Unwind to skip saving automation-state
|
|
Generated by tools/f2s. Some hand-editing will be required in a few places to fix up comments related to timecode
and video in order to keep the legible
|
|
class RingBuffer<> is a very generic name and should not pollute the
global namespace.
|
|
* Emit signal once midnam was actually updated
* only re-read midnam if was it changed. This allows idempotent calls to
read_midnam() - from the same thread.
At session-load a synth-plugin may load a soundfont in the background
and emit midnam_update() after the synth was initialized but before the
GUI thread connects to the signal. By making the call idempotent the
GUI can call read_midnam() after connecting to the signal to catch up.
|
|
|
|
... in .ttl file rather than by extension_data() in code. That's more in the
spirit of LV2.
|
|
This is currently done by an extension data similarly to
LV2_INLINEDISPLAY__interface.
|
|
|
|
This is needed for save-as and archiving, LV2 state may not be saved
otherwise if lilv_state_equals() returns true.
Also if thestate is saved as part of save-as or archiving or
template, the state-version did increase.
Upcoming normal save will reference a plugin state that does not exist
in the current session bundle.
|
|
and also allow immediate work during use latency-compute runs.
At session load, Ardour calls a plugins "set default" state (GUI thread).
Some plugins may schedule work during state-restore. Ardour immediately
proceeded to restore the actual session plugin state without processing
the already scheduled work and without calling run() for a plugin
to apply state synchronously.
|
|
This mostly fixes an issue with notifying plugins about tempo-ramps
and BPM changes.
remaining to be fixed (in tempo.h):
```
_session.tempo_map().metric_at(frame_position).tempo().beats_per_minute()
```
currently returns the most recent *fixed* tempo at or before
`frame_position`. All other Plugin types are affected by this as well.
|
|
The original LV2 state extension required that run() is suspended during
restore(). Ardour violates this rule, which can lead to crashes and
other issues.
The state extension has been updated to allow restoring state in a
thread-safe way by using the worker to enqueue state changes. This
commit supports that new specification, i.e. supports dropout-free state
restoration properly.
However, the bug with old plugins that do not use this facility is still
not fixed.
|
|
|
|
|
|
Pass current (latency compensated) cycle times to plugin.
This fixes time-reporting to plugins and also fixes automation
and when bouncing (the session->transport* is not valid) etc.
|
|
|
|
* thin automation at end
* allow plugins to disable its internal write state (ctrl port)
* Debug messages
|
|
* extend plugin API (query IO ports)
* collect possible variable plugin configurations (AU, Lua)
* prepare semi-automatic configuration (presets: mono, stereo, N)
|
|
|
|
|
|
|
|
|
|
goes along with https://github.com/x42/automate.lv2
|
|
The Session-reference is only needed to instantiate/load the plugin.
Indexing presets is not supposed to call load() and be const WRT to
PluginInfo
|
|
|
|
|
|
|
|
Since control-ports have a fixed value for the current process-block,
Ardour splits a plugin's run() process cycle on every automation event
to facilitate sample-accurate automation.
Since automation is interpolated between events, this ensures that each
explicit automation point is reached (not interpolated).
Plugins where this is not required and which favor a fixed block-size,
can now specify an optional Feature: NoSampleAccurateControl.
One example: a convolution plugin with smoothed gain control.
|
|
|
|
This is akin to VST2's audioMasterGetBlockSize.
It returns the current nominal block size (think jack-buffersize).
It's not the only block size that may be used when calling run(), it's
just the normal one. The actual block sizes used may be larger or smaller
and may vary between successive calls of run().
This change became neccesary after 53e969e9. Some plugins expected
maxBlockLength to be the /current/ buffer-size and not all-time maxiumum.
Those plugins can now use nominalBlockLength.
|
|
the buffersize may change anytime (split cycles),
also plugin analysis uses a 4096 sample window.
|
|
|
|
Work towards ParameterDescriptor being used more universally to describe control characteristics.
|
|
This fixes circular dependency issues that arise when using ParameterDescriptor more widely.
|
|
|
|
|
