Climbing the ValueTree

Okay…I keep hearing about these ValueTrees and so on and so forth.

What are they good for? Can someone please provide a use-case?

Anything? :slight_smile:

They can hold any data you like, so really you can use them for almost anything. They’re most useful for user/project data I guess.

Why they’re good:

  • they can hold as much or as little data as you like, and you don’t have to define a specific class for your structures (though helper functions are handy)
  • they’re automatically reference counted, and passing them around is easy; you don’t have to worry about lifetime issues etc…
  • they have listeners, so you can easily detect changes to data without needing to write additional hooking code beyond simply responding in the appropriate callback.
  • they can return Values.

Really, despite the fact that a ValueTree can hold any kind of structured data, the most powerful tool in my eyes is the Value class. Being able to just grab a single common handle for any element of data is very handy. It doesn’t even need to refer to a piece of actual data (e.g. You can have a value that represents a dynamically computed value BASED on some data, but as far as the outside interface is concerned it’s just another value). Very cool stuff, but it probably takes a bit longer to appreciate that side of things.

Okay but can someone provide examples of what they are actually being used for?

Well, i’d give an example if I had time, but a sentence like “the entire user document model data” sums up what it can be used for in a reasonably concise manner! :slight_smile: true it doesn’t give any implementation details away, but it answers your question!

I just finished converting my data model over from sqlite3 to using ValueTrees. With sqlite I had a Database class that provided all the functions for storing my various model objects. Now I have a ValueTree as a member on my DataObject base class and each derived model then manages it’s own data concerns. It’s a bit of a doubled effort with each tree being fully wrapped, but it’s much easier to manage than sqlite and each particular model’s persistence concerns are localized. The model’s top level parent is registered as a listener and simply writes the entire ValueTree to disk when any change (at any depth) occurs. When I load a tree from disk I simply create a top parent by passing in the whole tree and it then loads up it’s children by passing in the corresponding trees and so on goes the process. Pretty straight up. I added a Uuid in the my base class to so that I could reference other trees.

Okay for example, ValueTree would be useful for persisting the state of a complex user interface across launches?

If complexity is your concern then I don’t see any issues and it has the (de)serialization support in either XML or binary format. What other approach would you be considering? Straight XML is going to offer zero advantages. A properties file is certainly not going to offer any structural gains. Sqlite might be fitting if your dataset is large enough and I don’t know where that line is, but it’d have to be big enough that you didn’t want to load the whole thing into memory. Like I said I decided to add Uuid’s to each tree to help with referencing requirements but that’s easy enough.

It may be helpful to mention that similar to you I didn’t pay attention to ValueTrees until the recent talk around them. I think part of the problem is that the name ValueTree doesn’t effectively convey the significance of it’s usefulness. It should be called SuperKickAssDataStructureUndoManagingListeningPersistenceMechanism…or yeah… something like that. 8)

I’m using sqlite already, and I love it. I adapted the ‘soci’ wrapper to my needs, and then put a layer on top of that.

As for undo well that isn’t really a requirement.

There is no example to give, it’s a generic data structure- you could use it for anything. What would you use a struct or a class for? If you need to store data, then ValueTree is just another option that is available to you. Whether what it offers is something you can benefit from is down to your opinions and requirements.

If you already have something that works, it’s probably not worth redesigning everything just for the sake of using it. However, it may be useful to familiarise yourself with it through experimentation if you find yourself at a loose end :slight_smile: you may decide to pick it up for a later project.

Personally, I’ve taken to using them heavily for a great number of things. Pretty much everything, in fact. I use a ValueTree for my document data model, and I also have developed a system which uses ValueTrees to define descriptors and templates for generating interfaces to the data. I’ve discovered that I can achieve a lot by focusing on what information I wish to present to the user, and turning it into a ‘value’. When its boiled down to the values the user is to be presented with, it doesn’t matter how it’s stored, I just need to make a ValueSource for it. Then the UI is just a case of combining components which work with ‘Value’ objects and basically nothing else. It’s quite a deep subject though, and I’m in the process of writing a comprehensive guide to the ValueTree and Value/ValueSource classes. Naturally I’ll be posting it here when i’m done, but its going to take a while longer!

At the end of the day, you should use what you wish to use, and what you know can do you the job. It just happens to be that ValueTree is a very useful and flexible class, and is one of the options on the table.

I guess now that I think about it, this could be applicable for my uses. I don’t have a traditional “document” but there are audio settings from the AudioDeviceManager, the input/output channel mappings, the directory to look for plugins, all of the current settings like master volume, even the position of scrollbars for media lists, could be remembered and persisted.