| Age | Commit message (Collapse) | Author |
|---|
|
|
|
|
|
This reverts commit 8702ff2189665b473918ed60f34b6be4010a06f7,
and b10d9cf09bf6150f0ba0eae5dc34fd8db8b2fa91.
There was a misconception on the iterator (port vs message
in sequence), besides Ardour's mixer-strip is preferably used
with a single MIDI port. Most plugin-standards also only support
one port.
If need be LuaDSP run_map() can be used to handle multiple
MIDI I/O ports already.
|
|
|
|
The previous approach failed in case where PluginInsert
uses no-inplace buffers with a linear map.
Since buffers are replicated up to a total of number of
all (inputs + outputs), the number of output buffers
could not be determined. There was insufficient information
using the I/O map alone.
With a known number of outputs processing and applying
the i/o map is also a lot easier and faster.
This break the API of process_map().
|
|
Since Lua function arguments are not typed, there is no
explicit "const", and a function can always modify the parameter.
When passing `ChanMapping const&` as argument, the object is
copy constructed. In this specific case the std::map<> members
of ChanMapping allocate memory.
Passing a pointer to the object works around this issue.
LuaBridge later dereferences the object as needed when calling
c++ methods, and copy-construction would only happen later.
|
|
This handles a very specific edge-case: A script that was
successfully parsed before, fails load on session state restore.
|
|
|
|
We determined several years that we should never ever do this,
and changed the basis for the free/demo copy because of that.
|
|
|
|
|
|
|
|
This has been superseded by value_as_string() along with meta-data
from parameter-descriptor, which is supported by all standards, except VST.
|
|
|
|
|
|
|
|
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).
|
|
|
|
|
