In practice, this mostly means integers when presets leave off the ".0", but we
implement all the numeric types here for good measure.
Also while we're at it, warn about unknown types now so it doesn't take three
people a half an hour to figure out what's going on the next time something
like this happens.
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
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
If some plugin-internal state changes (GUI <> Plugin e.g. load a sample)
no ports change and the host does not know that the plugin state has
changed. The session may be closed without save.
This is a prototype using an ardour.org URI, pending upstream lv2plug.in
map MIDI event types (fix#4889).
All uri-map contexts are now just ignored, and equivalent to urid (which is
equivalent to uri-map with context NULL). We now just hope that no event types
are mapped after UINT16_MAX URIs have been mapped, and die horribly otherwise.
This is exceedingly unlikely to happen any time in the next several years, if
ever.
git-svn-id: svn://localhost/ardour2/branches/3.0@12462 d708f5d6-7413-0410-9779-e7cbd77b26cf
This saves a complete history of plugin state, i.e. save is no longer destructive. However, data is shared as much as possible, and new state is only written if the plugin state has actually changed. There is exactly one link in the entire session directory to any external file, so archiving will work with minimal copying.
Not sure sure about the naming of the "externals" directory, but I have nothing better...
git-svn-id: svn://localhost/ardour2/branches/3.0@11372 d708f5d6-7413-0410-9779-e7cbd77b26cf
This has a few benefits:
* As system installed extensions become more ubiquitous, we can optionally
build against those rather than including them in the source tree,
without any source changes
* No need to hack extension headers to change the include paths to match
our specific scheme (i.e. headers are precisely those from the extension,
even if they include other extension headers)
* Consistency, lack of ambiguity, easy code sharing, blah blah, etc.
git-svn-id: svn://localhost/ardour2/branches/3.0@10476 d708f5d6-7413-0410-9779-e7cbd77b26cf
Vimmers, try let c_space_errors = 1 in your .vimrc to highlight this kind of stuff in red. I don't know the emacs equivalent...
git-svn-id: svn://localhost/ardour2/branches/3.0@5773 d708f5d6-7413-0410-9779-e7cbd77b26cf
Robin Gareus
David Robillard
Paul Davis