Introjucer suggestion cool feature


#1

Introjucer should automatically create  ValueTree get/setter structures

Example, defining (maybe in a graphical environment)

 

Car: thread-safe

"Speed" float min-value:0 max-value: 200 default-value: 0

"NumberOfWheels" int min-value: 1 max-value:12 default-value:4

 

==> generates something like

class Car

{

public:

  virtual ~Car()

  static Identifier speedID;  /* ("Speed") */

  static float SpeedMinLimit = 0.f;
  static float SpeedMaxLimit = 200.f;
  static float SpeedDefault = 0.f;
  void setSpeed(float speed) { ScopedLock l(cs);      set.setProperty(speedID,jlimit(SpeedMinLimit,SpeedMaxLimit,speed,0);};
  float getSpeed() { ScopedLock l(cs);  return vt.getProperty(speedID,SpeedDefault);};
  Value getSpeedAsValue () { return vt.getPropertyAsValue(speedID,0);};

  // and so on , the same with wheels

  ValueTree& getValueTree();

  setValueTree(ValueTree& vt_);

private:

  CriticalSection cs;
  ValueTree vt;

}

 

Introjucer should also create an GUI propertyPanel-Class which can be used to modify such a structure.

Also it would cool if such a class, can inherit other such generated classes, directly in the introjucer

I think this would drastically  speed up developing time ...

 

 


#2

Don't most IDEs already offer such get/set generation tools?


#3

At the moment we're in the process of refactoring Tracktion so that the entire edit model is based on one big ValueTree, and in the course of that work we've been inventing some interesting helper classes that cut out a lot of boilerplate code.

For example, we have a CachedValue class that looks like this:

struct Car
{
    Car()
    {
        speed.referTo (state, "speed", undoManager);
        numWheels.referTo (state, "wheels", undoManager);
    }

    ValueTree state;
    CachedValue<double> speed;
    CachedValue<int> numWheels;
};

Car car;
car.speed = 100.0;
double s = car.speed;
int wheels = car.numWheels;
Value v = car.speed.getValue();

IMHO this approach is much cleaner than code-generation, and also helps to work around other issues like thread-safety. It doesn't handle min/max values, but could easily be made to do so.

We also have a clever class which creates an array of objects which mirrors the set of child ValueTrees in a parent. As child items are added/removed/re-ordered, the class automatically updates your list of custom objects to reflect the change.

It's all still work-in-progress, but we'll release these classes when they're a bit more polished!

 


#4

this looks great too, it would be cool if such a cached-value also supports a default-value, currently thats something i miss when working with values and connect them to user-controls.  (Also  if i change the underlying value-tree, no need  to reconnect them to user controls )

Thread safitiy is also a big topic, so i can access the cached-values without thinking from which thread i do.

Another cool feature would be if  such ValueTree-changes could be transaction safe, so i can manipulate many values at once, and when i access them from another thread the data should be consistent (simplest way of doing this, is with a lock).

 


#5

Yeah, we added a default value for it too.

Having a lock doesn't make much sense for ValueTrees at the moment, because they're not multi-threaded - if you want a lock, you might as well just take a MessageManagerLock. Making them thread-safe is tricky - definitely not just a case of adding a lock, there are lots of subtle things to consider, which we're pondering.

FYI another thing we'll be adding for Tracktion will be a mechanism for autmatically synchonising two ValueTrees that exist in different processes, so that we can easily move our audio engine into another process or machine.


#6

This looks very cool jules.
What time frame are we talking on releasing the cached value class?

Is it “bi-directional” so that I can simply set a new value for numWheels in for example a setter method, and the valuetree will be updated automatically?


#7

Should be able to release something pretty soon - I might have a look at doing it this week. And yes, they allow setting + getting values, although at the moment setting the value isn't multi-threaded, so I probably need to sort that out before releasing it.


#8

would be cool, if there is also a lock-free mode, for cached values. When the value is changed, they only marked as dirty, and a supporter thread synchronize the data with the value tree 

 

(so they can be accessed from an audio-callback for example)


#9

But I've put the code I'm using at the moment for ValueTrees on audio threads here: 

https://github.com/bazrush/juce-toys

It should be completely lock-free on the audio thread side. But when there's a bit change in the tree I just re-copy the bloody thing.  So if there's a better solution coming out from Jules...? :) 


#10

Will there be a way to commit several cached values at once into the ValueTree with this future class? I.e. a way to set only the cached values (not the tree) until a commit method is invoked.

I'm thinking about configuration UIs that have Apply/Cancel mechanisms, and whether this CachedValue class could be suitable for that at all. Right now, I'm just writing values into a temporary copy of the ValueTree and then copy that back into the real tree on commit.


#11

Any updates on the CachedValue?

Would be super handy..


#12

sorry for the necro, just curious if this ever made it in? i just searched through the code on github and didn’t see anything similar - i’m having to implement this now and i’m running into some issues.


#13

No, I don’t think it ever did make it. Thanks for the heads-up, we should do that!