v0.1.6

What's Changed

• Say what the plugin does, in the field Resolume shows by @stoatworks-labs in #3

New Contributors

• @stoatworks-labs made their first contribution in #3

Full Changelog: v0.1.5...v0.1.6

v0.1.5

What's Changed

• build(deps): Bump softprops/action-gh-release from 2 to 3 by @dependabot[bot] in #1

New Contributors

• @dependabot[bot] made their first contribution in #1

Full Changelog: v0.1.4...v0.1.5

v0.1.4

The OpenFX plugin now ships for Linux

There is a -ofx-linux-x86_64 build in this release, for Resolve on Linux. It is
checked by loading it in a Rocky 8 container — the oldest glibc Resolve supports —
and calling the two entry points a host calls first, rather than inferring from a
successful build that it would load.

A User guide button in the About block

About now carries four buttons instead of three: User guide, Project page,
Source on GitHub, Support the work. The guide button is new and opens this
plugin's published guide.

Also in this release

• demo: let the support footer reach the intake origin
• docs: add a user guide, and fix two stale docs

---

Full changelog: v0.1.3...v0.1.4

v0.1.3

Full Changelog: v0.1.2...v0.1.3

v0.1.2

Factory presets work

Reported in #2: choosing any preset did nothing and the dropdown snapped straight back to Custom.

Resolume does not act on the value events a plugin raises when it changes its own parameters. It keeps pushing the values it still believes in — the ones from before the preset — and those arrive looking exactly like an operator moving a slider, which is what the plugin took them for. So the preset was being applied and then immediately abandoned, every time.

A preset is now an override rather than a write: the render and the parameter read-back both take the preset's value for anything it covers, and the plugin tracks what the host last sent separately so it can tell an operator's edit from the host restating itself. Moving a covered slider still drops to Custom, as it should.

Dropping to Custom is now logged with the values that caused it, so the next report of anything like this is answerable from the log rather than from a code read.

Also

CMakeLists.txt had been left at 0.1.0, so v0.1.1's bundle reported the wrong version inside a correctly named file. Fixed.

Full Changelog: v0.1.1...v0.1.2

v0.1.1

Full Changelog: v0.1.0...v0.1.1

v0.1.0

Full Changelog: https://github.com/stoatworks-labs/vertigo/commits/v0.1.0