ValueTree


#1

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


#2

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


#3

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.


#4

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…


#5

[quote=“haydxn”]
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.


#6

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?


#7

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: