| Age | Commit message (Collapse) | Author |
|---|
|
|
|
|
|
We determined several years that we should never ever do this,
and changed the basis for the free/demo copy because of that.
|
|
|
|
The spec [1] says:
"If the mData pointers are null, the audio unit can
provide pointers to its own buffers. In this case,
the audio unit must keep those buffers valid for
the duration of the calling thread’s I/O cycle."
A plugin *can* do this, but it does not need to. An extra
NULL test is required.
furthermore [2] specifies
"mDataByteSize - The number of bytes in the buffer pointed
at by the mData field."
In case the host does not provide any buffers, this is obviously zero.
[1] https://developer.apple.com/documentation/audiotoolbox/1438430-audiounitrender?language=objc
[2] https://developer.apple.com/documentation/coreaudiotypes/audiobuffer?language=objc
|
|
|
|
|
|
Instead of uniformly demote configurations with a non-matching audio
input count (using a penalty offset of 1000), also grade the
impreciseness of the configuration so that those with the nearest input
count are preferred. As for outputs, give a slightly higher handicap to
configuration with too many inputs with regard to the actual audio
inputs that can be fed to the plugin.
POLICY CHANGE: when only imprecise configurations are found the actually
selected one can be different (better) than before this commit.
|
|
Just make the code responsible for possible_in > 0 also handle
possible_in == 0 since it nearly does the same thing.
The only difference is that the possible_in == 0 case, by using
FOUNDCFG(), acted as if possible_in was audio_in. The consolidated code
uses FOUNDCFG_IMPRECISE which will add some penalty to the
configurations where desired_in == possible_in != audio_in.
There is thus a small POLICY CHANGE, but the selected configuration will
stay the same unless a better matching configuration is available.
|
|
This relieves exact matches of the need to duplicate the bookeeping done
by FOUNDCFG()
|
|
Still no policy change, since when a configuration is chosen that would
have belonged to the second pass, then its penalty will be increased by
1000 and it will be selected only as last recourse.
|
|
It enables only setting the imprecise audio channel count if the
configuration is indeed selected.
|
|
Merge the cases in == -1 and in == -2 since those are both wildcards,
almost symmetric in the AU spec, and handled completely symmetrically by
the code here considering it accepts invalid or unspecified demands.
Also merge the cases in > 0 and in < -2 since they are handled exactly
the same as far as outputs are concerned.
No policy change
|
|
Instead of doing an initial loop for detection of exact matches, then
letting the following loop set \audio_out yet ignore its value, merge
the two loops but give exact matches a negative penalty so that the
\audio_out value they set won't change afterwards.
No policy change.
|
|
Since previous line just asserted that possible_in > 0, it is
necessarily non-null and the test is always true.
|
|
To match the actual type used by ChanCount. Keep the int type in the
structure passed in by the Audio Unit, because we have no control over
it.
|
|
|
|
This has been superseded by value_as_string() along with meta-data
from parameter-descriptor, which is supported by all standards, except VST.
|
|
This is only used for plugin-analysis, AU plugins are otherwise not
replicated, and variable-i/o is used instead
|
|
Plugins are only a source of Latency (Plugin delay).
The API to query, signal and override Latency is managed
by PluginInsert.
|
|
Use AU's preset->presetNumber as identifier since std::map are sorted
this also indirectly sorts presets by preset-number. (user presets
start with a '/' and are listed first, sorted by name).
Since Presets are now identified by URI on session load (53a0199a0)
and AU user-presets can added/be removed (since ae4604a24b7), simple
sequential numbering is no longer an option.
|
|
This works around async parameter-changed signal emission when loading
an AU preset. A simple timeout is used to delay making the preset
as modified.
|
|
|
|
This is a step in the right direction: first load the preset and
only if preset-loading was successful mark it as loaded.
This still does not properly unset "parameter_changed_since_last_preset".
AU signals "kAudioUnitEvent_ParameterValueChange" later in the event-loop.
|
|
|
|
load_property_list() takes a file-path (not URI). Actually it's not
clear why we've ever used a `file:///` URI internally.
|
|
|
|
Copy c'tor needs to initialize "audio_input_cnt".
|
|
This fixes duplicate AU presets when adding a new preset.
Presets are kept in a std::map<URI,...> adding a new presets uses
the file-URI as ID. Loaded presets needs to have the same URI.
|
|
* dedicated API for classes (effect, instrument, util)
* prepare for tags (rather than categories)
* prepare removal of per-plugin in_category() API
|
|
|
|
This fixes issues for synths with zero audio input, explicit default
stereo config and optional busses.
|
|
|
|
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
|
|
This explicit case should never have existed in the first place.
Plugins can always implicitly exceed the range and are expected to
cope with out-of-range values (e.g. meters when fed with a peaking signal
may return an out-of-bounds value)
|
|
(don't leave buf uninitialized)
|
|
|
|
|
|
|
|
|
|
It is slightly questionable whether type specific methods like
velocity() belong on Event at all, these may be better off as free
functions. However the code currently uses them as methods in many
places, and it seems like a step in the right direction, since, for
example, we might some day have events that have a velocity but aren't
stored as MIDI messages (e.g. if Ardour uses an internal musical model
that is more expressive).
In any case, the former inheritance and plethora of sloppy casts is
definitely not the right thing.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
