Just wanted to say: absolutely f**king awesome. Incomprehensibly awesome.

Oh, small request. I see NamedValueSet has an option to retrieve a value ‘withDefault’ - any chance of plonking that out into ValueTree too?

That’s been my feelings too, using it for the new Jucer, I’m realising that ValueTree is probably the most useful thing I’ve ever written. Wish I’d thought of it years ago - Tracktion would have taken half the time to write and would have had half as many bugs!

Good idea. Will do.

Any chance of a ValueTreeArray built into juce? I can use Array but only if i only try to access them via getUnchecked(), as they don’t have a default constructor. I’m working on a ValueTreePath / Finder, and (amongst other cases) it’s proving increasingly common to need to grab a list of ValueTrees (i can’t add them as children of another, as they’re already children).

Unless… maybe having a default constructor isn’t so bad? It could just init as invalid…

Unless… maybe having a default constructor isn’t so bad? It could just init as invalid…[/quote]

I second this. ValueTree is a great class.

In my code I’m using a static instance in the form of

static ValueTree::invalid; ValueTree ValueTree::invalid( T("?"));
to return invalid references or create instances without having a parameter.

In general, I woud like to see that all juce classes have a parameterless or pre-initialized constructor.
This especially makes sense in conjunction with abstract factories which separate the process of
creating from initializing. Think about the problem, that you can’t use a virtual initialize method
inside the constructor. You have to call init in a second step.

Another place where I missed an empty constructor is the MidiMessage.
I would like to write just Midimessage msg;
and then fill it later.

Not a bad idea! Now that there’s ValueTree::invalid it could certainly have a default constructor. I’ve been using it in Arrays myself, but always use Array::getReference() so hadn’t noticed the problems with operator.

MidiMessage… Hmm. Not as sure about that one. At the moment I like the fact that all MidiMessage objects are genuine midi messages - allowing an empty message might break things like the MidiFile or MidiBuffer classes. Or is there some sort of empty midi message in the midi spec that it could use?

I just put the first version of my ValueFinder in the Useful Tools forum. It’s pretty nifty, thought I’d mention it here in case as it’s relevant :slight_smile: basically it makes it possible to define a pattern to refer to / retrieve values or valuetree nodes from an existing tree. I made the core abstract so people can make their own decisions about how these patterns are defined, but it’s easy (as demonstrated with the BasicValueFinder I cobbled together) to for example make a simple path-based locator. Having it abstract makes it possible to make a finder tailored to specific data structures, rather than having to shoehorn all your searches into a complex path based interface.
Feel free to take it over if you reckon juce would benefit from it as a standard feature. It is pretty awesome :wink: