hedron
hedron copied to clipboard
nudibranchrecords
Vector3 param type
With different flavours of picker, such as RGB, HSL, XYZ. Would be lovely to have colour pickers as well as a 3D picker style thing. Needs some thought on how each component can be controlled via inputs such as MIDI. Under the hood this will probably be three separate nodes...
I really want to take these ( #185 ) on. I have a string param working in my own branch, I completely forget what level you believe the split from one param to the other should take place though, I remember talking about this on facebook way back, but getting this down here would be good
I think the first thing we need to work out is how it's going to behave from a GUI perspective and in terms of the config. We haven't implemented param groups yet, but perhaps something like a Vector3 type is a special kind of param group that shows up a clever GUI where all three params are combined to appear as one. Even the config could make it seem as if it's one, but really the nodes are still split out and we don't have to think about doing any extra work where data flow is concerned.
Just to expand on my above comment. I still think each value for vec3 types should be stored as three separate nodes, but in all user related areas it should appear as a vector (or perhaps a three part array for configs). When arriving as a param to your sketch it should probably be a THREE.Vector3, although I'm a little concerned about mutability of incoming params and if that might mess stuff up...
Ultimately I'd imagine this would result in four nodes:
- One for the param, with references to the three vector nodes
- Three for each component of the vector
We'll have to come up with new types for the nodes I'd imagine. Most things in the app are nodes now so this shouldn't be too tricky.
If we're going for different flavours (e.g. Position and colour) perhaps the param could also arrive as a THREE.Color.
Boolean param type is in! Some of the stuff I did to get it to work might be relevant with this one: https://github.com/nudibranchrecords/hedron/pull/314
This one is quite a bit more complicated, however.
Perhaps should consider having types as a sort of "plugin" style thing. They could live in folders and be a collection of functions/components that are called in various places throughout the app. This would make adding new types easier but also open up custom user generated types.
Might be worth implementing vec3 first to see the complications of having multiple values for a type. Then abstracting float, bool and vec3 into the above format.
The plugin style format could handle stuff such as:
- The component
- MIDI behaviour
- Macro behaviour
- Hot reload behaviour
- Sequencer behaviour
This new approach to value types is happening here: https://github.com/nudibranchrecords/hedron/pull/323
I think it's working quite well. Would be super easy to get strings in now. Vec3 and Vec2 not so easily, but I'm hoping the architecture will allow for this.