| Age | Commit message (Collapse) | Author |
|---|
|
Empirically this decreases gc-spike duration (worst-case) by a factor of
two and speeds up the average gc-run by a factor of over 4 (depending
on the amount of memory used by the plugin).
|
|
* dedicated API for classes (effect, instrument, util)
* prepare for tags (rather than categories)
* prepare removal of per-plugin in_category() API
|
|
|
|
|
|
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
|
|
|
|
|
|
All float <=> string conversions are done using PBD::to_string/string_to via
XMLNode so no LocaleGuard is necessary.
|
|
|
|
|
|
|
|
|
|
VST used the count of available of presets as URI:
- add 2 presets (1,2)
- remove first, add another one -> two presets with same URI (2,2)
PluginInfo::get_presets() simply lists all (name only) in a vector.
Plugin::find_presets() uses the URI in a map (unique by URI).
..various ensuing bugs: eg. Plugin::remove_preset() looked up by name,
but didn't check for NULL.
|
|
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.
|
|
|
|
|
|
This fixes an issue with dsp_configure not being when there are
only MIDI signals at the given insertion point.
|
|
|
|
...now that bindings alone need approx 700K and some more complex DSP
scripts are showing up 2MB is not much :(
|
|
|
|
It should have been removed as part of 539c062ed23daf308e650b5d1039384ac5a55666
(Make the configuration penalty subtler about inputs).
|
|
If the script doesn't provide a dsp_ioconfig() function, or if it does
not return a table of tables, provide an empty table of table as
default, which means a single configuration with default values.
|
|
_has_midi_*put members of LuaProc will be set according to the actual
configuration chosen, for configure_io() and run() to use.
|
|
Since MIDI in should be
|
|
Demote configurations if they have mismatched midi in or out with the
same mechanism as for audio, but with lower coefficients so that
mismatched midi has less influence than mismatched audio in selecting
the best configuration.
POLICY CHANGE.
|
|
Just refuse configurations without any output at all, and let the
remaining logic take care of selecting configurations with no audio
output if they make sense and there are no better configurations.
POLICY CHANGE: configurations with no output might now be considered
even if they have audio inputs (e.g. a pure pitch detector without audio
passthrough), whereas they were skipped before.
|
|
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 didn't check at
all for audio_in, essentially acting as if possible_in was audio_in.
There is thus a small POLICY CHANGE, but the selected configuration will
stay the same unless a better matching configuration is available.
|
|
|
|
...instead of at the very beginning, so that it can depend on the loop
iteration.
|
|
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.
|
|
This doesn't change the policy since configurations are given an
additional 1000 penalty if audio_in != possible_in, and will thus be
trumped by any "precise" configuration (unless the latter has 1000
excess or missing outputs which should be less than likely).
|
|
|
|
|
|
This is useful for exact matches that would otherwise need to duplicate
the bookeeping done by FOUNDCFG()
|
|
It enables only setting the imprecise audio channel count if the
configuration is indeed selected.
|
|
So that it can depend on the actual configuration selected.
|
|
Instead of setting \imprecise at the end of the loop if a configuration
was found (which clobbered valuable information, see dae2406187), set it
each time a new configuration is chosen.
In the second loop that tries harder, resetting \imprecise also avoids a
previous "imprecise->set(AUDIO, 0)" to last even if another
configuration is chosen later.
Last but not least, it will enable correctly setting the midi input
count hoped for by the configuration.
|
|
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.
|
|
That code modifies \imprecise if it is not NULL, but
- if a configuration is found, \imprecise will be set to in, clobbering
the tentative changes done here;
- if a configuration is not found, a last-resort loop will be run that
will set the same member of \imprecise, also clobbering our changes.
Remove it since it does nothing that is looked at before being
forgotten. A way to get the intended outcome will be introduced later.
|
|
...to later enable that condition truthiness to depend on the
loop iteration. The goal here is to prepare for the upcoming rewrite,
without introducing any policy change for now.
There is no behavior change because if all loop iterations are skipped,
then \found will be false, and with \imprecise being null the last
attempt will be skipped and we will return false.
|
|
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.
|
|
|
|
|
|
|
|
There is no code that read the set value in between the removed line and
its exact counterpart below. There is no similar duplicate in the
AudioUnit code due to the way AudioUnit handles midi.
|
|
So that the plugin knows that a preset has been loaded, and can send the
signal accordingly.
|
|
That caused truncation of parameters to int when the decimal separator
is not a period in the user's locale.
|
|
|
|
|
