Back To Schedule

Beyond ValueTrees

(Confessions of a ValueTree Skeptic)

15:40 - 16:00 Monday 11th November 2024 BST Bristol 2
Beginner
Intermediate
Advanced

The JUCE website says "The ValueTree class is JUCE's secret weapon," and it's true. They give you:

  • A really easy way to capture and pass around the entire state of your application's data at run time
  • A rich mechanism to watch that data at a fine degree of granularity
  • Trivially easy persistence of application state

...but at the cost (in comparison to using native POD or class/struct variables) of being:

  • slower
  • less convenient to use
  • less type-safe, since all values are stored in the JUCE var variant type.

This talk will explore the new Cello library to abstract away the underlying API calls in favor of syntax that's more like working with POD data. The original goal was to be able to write code something like the below, but using ValueTrees as the backing data store:

struct MyStruct : public cello::Object 
{
    cello::Value<int> x;
    cello::Value<float> y;
};

MyStruct demo;

// will be executed any time the value of X changes
demo.x.onPropertyChange = [&demo] ()
{
    std::cout << "x changed to " << demo.x << "\n";
}

// after executing this line, stdout should print: "x changed to 100"
demo.x = 100;

...and it's surprising how close to that we were able to get.

This project has a set of overlapping goals:

  • make working with ValueTrees more like working with C++ objects and less like calling API functions
  • add type-safety and type conversions without explicit use of VariantConverter objects
  • reduce boilerplate wherever possible
  • handle undo/redo management invisibly
  • support validation of values when they are accessed
  • explore the gray area between compile-time strong typing as in C++ and the kind of runtime dynamic typing that's possible using the ValueTree API
  • explore the available methods of reactive programming enabled with this system
  • build out new functionality that's implied by the capabilities of ValueTrees but perhaps not obvious, like:
  • creating a kind of NoSQL database
  • creating an in-proccess sync mechanism to make ValueTrees thread-safe
  • creating a simple IPC implementation
  • In general, add support for more complex use cases where the complexity can be hidden inside the framework.

Brett g Porter

Lead Software Engineer

Artiphon

Brett g Porter is a composer, trombonist, and developer of music software, currently Lead Software Engineer at Artiphon, where he designs strange little electronic musical instruments. He is a frequent speaker on the topic of Music Technology at industry events including SXSW, the Audio Developers Conference, the NAMM Show, and the Audio Engineering Society convention. He also serves on the executive board of the MIDI Manufacturers Association, which defines and maintains the MIDI standards used by electronic instruments, and has been active in several of the working groups tasked with developing the MIDI 2.0 specifications. Brett holds degrees in composition and electronic music from the Frost School of Music at the University of Miami.