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.
Thanks!
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! 
