ValueTree & plugin host

Jules, you said that if you would had ValueTree class Tracktion would had been easier to program and bug fixing. However I’m confused about how you use this class in a plugin host with tons of objects like MidiMessageSequence [I don’t find any example].

So, if you would rewrite Tracktion, what should contains your ValueTree object? MidiMessageSequence? Avaliable plugin list? I’m pretty insterested into know how you would do it.


i was moving my code to ValueTrees in my plugin (lot’s of surfaces that contain modulators/midi messages) i went through the new Jucer code witch uses ValueTrees a lot, it’s a good place to start.

My favourite approach at the moment is to take a ValueTree, and to wrap it in a class that understands the format of the data inside it - e.g. the Project::Item or Project::BuildConfiguration in the new jucer, or Drawable::ValueTreeWrapper and its subclasses. That gives you an easy-to-use public interface for a type of ValueTree, and keeps all the knowledge about its property names, etc, encapsulated in one place.

I guess that the edit and all its data would be a ValueTree, and all editing operations would be performed on it. Then to play it, that structure would be converted to (and cached as) low-level objects like MidiMessageSequence that are fast enough to be used for real-time operations.

Thanks, very valuable nfo! :slight_smile: