-
Notifications
You must be signed in to change notification settings - Fork 23
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
ofxVPParameters #22
Comments
The purpose of ofxVPParameters is to speed up and simplify the creation of nodes by wrapping common variable/parameter behaviour in a templated class. ofxVPParameters will provide common actions on parameters such as : saving+loading data, providing metadata (name, flagChanged,...), serialisation (to string), custom behaviours (sanitisation+validation, timed-updating, manual updating), displaying data, accessing data. Related to #21 : Loading and saving --> ofxVPParameter->saveTo(XMLHandle); |
So what do parameters need to do for this first basic implementation ? BaseParameter
Optional ParamFeatures (currently
I'm thinking about adding a feature to define inlet/outlet pins which will map to object pins.
AdditionObject would do : ofxVPBaseParameter<float, true, false> inValue;
ofxVPObjectParameter<float, true, false> numToAdd;
ofxVPBaseParameter<float, false, true> result;
update(){
result = inValue + numToAdd;
} What do you think about this inlet/outlet proposal ? How would this match/interfere-with existing nodes' behaviour/implementation ? Do you have any other suggestions / needs ? |
OK, let me tell you what i have right now with params and objects: 1 - simple inlets, no GUI related, just inlets for internal use, NO saving/restore to/from xml 2 - simple outlets, no GUI related, just outputs some value from the object (internal operation or simple bypass from some inlet), NO saving/restore to/from xml 3 - inlets with GUI (mainly int/floats and sliders/textboxes), if the inlet is connected, the GUI control is deactivated and the internal value came from the wire; if is disconnected, the internal value is directly controlled form user input in the GUI. The value controlled from the GUI is always saved in the xml for restore when opening a patch (with the setCustomVar(value,tag) method). 4 - dynamic inlets/outlets, some objects have the capability of create new inlets/outlets from the GUI (osc receiver or osc sender, or timeline), and in a special case creating inlets directly from a script (shader object, loads a glsl shader, and i have hardcoded a way of name textures, float and int vars to have automatically appearing inlets associated plus their GUI). This cases are like type 3 above, plus the dynamic part. Basically, all the inlets with related GUI, are saved/restored to/from the xml patch file, and the special dynamic ones, also save/restore the specific object inlets/outlets configuration (there can be a shader object with 4 inlets and 1 outlet, and another shader object (same node) with 2 inlets and 1 outlet). So, from your explanation about ofxVPParameters, i think we are on the right path, maybe i will add, for the BaseParameter:
Apart from that, i think your first implementation covers the issue fine. Tell me if something is not clear about inlets/outlets |
Thanks for your explanations and details, that clarifies a lot. Sounds good, I'll continue implementing this until I have more questions. I'll probably end up adding a minimal Pin class to simplify pin logic too, hoping it won't involve too much changes. What do you think ? Don't hesitate suggesting more parameter types I can start implementing too. You can indicate more specific objects with common/specific data types. |
This is getting complicated. I'm working on some draft code as a proof of concept for Pins + ofxVPBaseParameters. I'm running in a lot of trouble, but learning a lot.
I'll post code when I have bare minimum functionality, or report back with some more details. |
Ok, I got major progress ! I'll soon have a basic version to propose. Btw, found a really useful utility, pre-compiling C++ code and showing how the compiler parses/unfolds the actual code. Good to see what happens under the hood in complex scenarios, seeing what |
I'm trying to port some objects to test specific stuff, and i just find out the Order of inheritance and multiple inheritance problem with the ofxVPParameters code, generating duplicate symbols on compile. I'll wait for your code ;P By the way, great tool the https://cppinsights.io/ !!! |
Yet another great tool I found : https://app.diagrams.net/ I've been thinking around, drawing the logic down to get something future-proof. And I'm not completely happy with my current (gist) proposal too, it feels a bit too complicated. So here's a slightly different proposal. Changes are mainly the pin logic : inlets could be modifiers and are not guaranteed to be kept alive. Whereas outlets are always accessible (if enabled on the parameter). This might be closer to a master/slave model, bringing some kind of variable ownership, simplifying the dataflow logic. And the .drawio xml file to open with diagrams.net, if you wish to edit. |
Yes, i agree, and it's perfectly clear! About the question about ParamAbstract classes, i think they don't need to be separated, one big class will do the job fine. Generally speaking, i think the diagram covers the Mosaic pins/params needs beautifully, at least regarding what we talked about till now. Just a detail about the HasUID class, i think it's a great idea to add an unique identifier to every element, but i have a question, why uniqueName when we have uniqueID? With uniqueID alone we can cover the logic, no? |
Ok, sound good.
What do you think ? |
Yes, it's handy, you're right, it's better with it! About the non-unique name, i'll leave it too, for GUI labeling issues. Imagine a patch with 3 "constant" objects, having the same object with the DragFloat GUI with "number", "number_1", "number_2" labels can be confusing in design/interface terms, it would be better to have the same "number" label for all objects, and maybe on rollover showing the unique name? This goes for the objects name on headers too, maintain the GUI non-unique name and on rollover show the unique name and the unique ID too? Well, small details anyway, i think it's ok as you design it from the beginning. |
Yeah, small details, the hover idea sounds good. |
I've updated the drawing to better reflect our discussions : I'm not sure about storing the address of the pin relative to the object (Pin.ID & Pin.objectID) in #28 , so Ive not added them (yet?). // EXAMPLES
// Check if a pin can connect with int
myObject.parameters[0].links[0].toInlet.acceptsLinkType<int>()
// connect 2 params together
myObject.parameters[0].createNewLinkWith( otherObject.parameters[0].addModifier( new InletPinModifier() ) ) |
This is what i'm imagining it, we will have (maybe) three map vars? map<int,shared_ptr> objects; map<int,shared_ptr> parameters; map<int,shared_ptr> links; So, when we create a PatchObject, we store a reference to his parameters in the "global" parameters map. Then, every Parameter (if hasPinOutlet) store a reference to his PinLinks in the links map (we need PinLinks class to inherit HasUID too) With that, we have the reference to every element on the patch, the objects, the pins/parameters for every object and all the links of every outlet pin, everything accessible from "outside", as of now, where a map is used to manage all the objects of a patch, and it will be a really easy to read code. In the case of Pin.ID and Pin.objectID, we can sure remove the first one, using HasUID inheritance will give us the access to every single pin on the patch, so it's not needed anymore. But about objectID, will not be useful for access map elements from outside? We will have a way of relate links with pins/parameters, because PinLink class get me the reference to the With that it'll be really easy to port all the actual logic to the new design, then, while working on the port, we can always optimize and remove eventually var redundancy. |
Ok, sounds good for the 3 maps. Indeed, we need global access to Links too. We can have So, from another perspective, we have :
We'll see later if we'll need PinLinkTyped or if we can keep it abstract. |
Perfect, i think we are really close. About And about |
Latest update, in Mosaic-Engine-Tester repo, I got the first working link connections 🚀 . But by using references to link params, editing 1 variable changes the other connected variable, even upstream... which messes with thinking logic (logical flow direction); although it's also interesting to be able to edit the same value from a downstream node parameter. Also, I feel the need of extending the ImGui node api to support something like beginParam(), beginParamInlet, param menu, etc. ? So parameters easily all get a similar look. #17 |
Amazing! I'm really happy to see it working! About the first two issues, can we just limit the logical flow direction with the if(bIsConnected)
inletParam.editable = false;
else
inletParam.editable = true; So we avoid inverted flow direction and looped connections. Right now is like that, if a node param has inlet and the inlet is disconnected, you can edit it, but when the inlet is connected, the value is overridden from the cable. And about the extending of the ImGui node api, let's do it "surgically", i've changed various stuff, and just yesterday i was testing it on a retina screen, and the design come up completely distorted ( widths, heights and spacings are most of them off ), so we'll need to do all this plus your extensions with precision ( the fixing retina issues is really a pain in the ass!! ) I'm going to finish something today and i'm going to push a commit ( i'll let you know when is done ), so you'll have the last version of imgui_node_canvas Let's coordinate on the ImGui node extension then, and congrats for the first linking connections!!! |
Ok, just pushed the last commit on refactor-params-and-gui branch |
Ok, I'll checkout the changes. Is ImGui even retina-compatible ? I've read trough a lot of DPI issues, it can come from the (older) ofxImGui implementation or incomplete native ImGui support, see ocornut imgui/pull/2826. I'll try to disable editing for connected params. (ImGui internal beta functionality, but it should work). |
Well, nothing is retina compatible, but basically you just need to detect it ( already working in Mosaic ), and multiply by 2 every design constant ( spacings, borders, etc... ), hacky but it works. A friend is sending me screenshots with the retina issues, so i'll fix them over time. About the loop, as a suggestion i think that probably we'll need to make a copy of the parent value ( a pointer copy ) for all the params with GUI/inlet, while not needed for the internal params without GUI/inlet. |
I'll digg the ptr copy method and report back here. |
It appeared to be an infinite recursive function call, overwhelming the call stack. |
I continued to think and experiment with the next ofxVPParameters steps this summer.
What are your thoughts on these points ? |
Ok, point 2, i think you're right, basic link types conversions ( as int with float or double ) will be better located inside the parameter class. Tracy for debug looks amazing, i discover it some time ago looking at imgui projects, i think is another good idea ( if not too complicated to integrate ) about point 3, i'll answer on #23 |
|
point 2, nice idea! about tracy, the same, i compile Mosaic with c++14 on osx, so i'll need to tests the Profiler on linux too. And the network local traffic? is about Tracy? Mosaic did check something on startup, download the release file from github to check if new releases are available and inform the user ( in the logger ) |
Ok, nice to know, I'm using C++11 for Mosaic on osx. I read some report that OF won't compile in C++17 yet. |
Hey, no much advancement in terms of code, but I'm still thinking about this from time to time, and planning to resume somewhen this winter.
I feel like exploring Corrade::Interconnect for powering ofxVpParameters. What do you think of this ? Looking at Magnum globally, it could save us a lot of development time on hardcore topics. It looks like something similar to OF but it's far from having all its graphic features and extensions (=connectivity), maybe it's worth looking into, how it would interface with OpenFrameworks. I really like everything they say about Magnum. |
Magnum+Corrade looks amazing, didn't know it! Let's take a dive on it and do some testing, i'm open to use it, coupling it with OF or even substitute OF with it, we'll just need to check if and what we'll lose doing so. |
Hey, longtime ago ! 1. Component Graph Structure
Then the UUID of Number2 would be:
2. Ownership of variables
Mosaic shouldn't keep track of these lists, except the 3. Dynamic parameter count (inlets/outlets) |
No description provided.
The text was updated successfully, but these errors were encountered: