How to use AND MODIFY sliders and color controls INSIDE groups?

I think that groups have been done and created TO SIMPLIFY AND MAKE EASIER the process of creating filters, but now I find that it seems that is more complex than not using them, maybe is because I do not understand well how to use the groups, so please, I would like that someone could explain and show how to use them better and explain why the things told below happens.

I have seen something that I still do not understand about the FF 4.0 groups and is how to use in the right way the sliders and color controls inside a group, because if you add them inside the group you can customize them as usual inside the group, but this way they are not showing in the settings tab, so for them to appear in the settings tab you have to also add the same slider or color control outside of the group, BUT the problem I find with this is that if you now enter inside the group there is NO WAY to modify and customize that slider or color control!!! You only see that this is controlled by an EXTERNAL setting outside of the group.

SO, do I have to go outside of the group, change the setting, and enter again inside the group and see what result this setting do?

Should I always have to unlink the sliders and color controls from outside of the group to be able to modify them INSIDE the group???

Because if they are linked externally you can´t modify them inside the group

If this is how should be done, this way is really awkward, bad and unfriendly

SO my question is How to use AND MODIFY sliders and color controls INSIDE groups?

TEST WHAT I AM TELLING WITH THIS FILTER

I have made a filter to show what I am trying to explain

1 - Download filter attached at the end

2 - Edit filter in Filter Editor

3 - Go inside the group

4 - Try to modify any of the "H Range", "Mortar Width" or "Chaos" sliders and you will see that is NOT possible because the sliders are NOT showing in the left side

5 - Try modify the image input of the color controls INSIDE the group and you can´t do it, EVEN if the color control is NOT attached outside of the group.

6 - Now try to modify any of settings of "L Range", "Fill Mode" or "Circular Arc" and then now these settings APPEAR INSIDE the group at the left, but as said, this only happens if there is no external slider linked outside of the group

7 - Go outside of the group

8 - Go to "Filter Controls" under Result component to see the "Settings tab" at left and see that ONLY the sliders that are linked OUTSIDE of the group will be seen in the settings tab

9 - So the only way to make all the controls inside the groups appear ALSO in the settings tab in the filter you must connect EACH one of the sliders and color controls ALSO OUTSIDE of the group, BUT then after you can´t modify any of the settings from INSIDE the group.

10 - So if you really need to add also externally the sliders externally it seems that you must copy them from inside the group and paste them outside after, because you can´t go outside of the group and add a new slider because this slider will have DIFFERENT values than the sliders that is already inside and linked and connected to this external link.

11 - What I have seen is that YOU CAN modify the remapping of the slider EVEN if the slider is already connected to another slider outside of the group, so you can go to an internal slider and do the remapping and the external slider will follow the internal remapping

Thanks very much for any help that any of you could give to explain this

FF HELP AND FEATURES PAGES

I have already seen the Groups Help page and also the Groups Feature page

And the only reference to using input control is

Quote
Adding Inputs A group can have an arbitrary number of custom inputs, such as colors, sliders or checkboxes. To define group inputs, Filter Forge uses Control Components, which now serve a dual purpose: in addition to their usual role of defining filter controls, they can now define group inputs when placed within a group:

This does not help much, but in the other text

Quote
To define the inputs Filter Forge uses Control Components, which don't show up in the Settings tab but specify group inputs when placed within a group:

I see this text telling that you can use control components inside the group and you have the option to NOT show them in the settings tab, so this is the dual purpose that is told in the first text.

BUT none of this texts help to solve the problem

Group Sliders test.ffxml

tl;dr: Controls can't be dealt with inside groups when connected externally. Help.

Thoughts: it's probably just this way to preserve hierarchy. Albeit, mildly frustrating but it makes sense in a bigger picture.

[A side note]
I'm a bit confused at what you wrote above but I kinda get it.
Is my tl;dr basically what you mean?

[edited]

No, it's not a bug. It's an interface design issue. Or is it?

Quote
GMM If you take a component, say Perlin Noise, and connect a Slider to the Roughness input, you are no longer able to modify roughness fr om inside the component settings: it is now controlled by a slider

Of course, I agree with you in this and you are totally right that you can´t modify the values of the component itself when there is already connected a slider, and you have to go the slider to change the values and this is right and nothing wrong with this and is good AND this is really what happens when using control components INSIDE a group IF THEY ARE NOT CONNECTED EXTERNALLY

THIS is the real problem, you can´t modify any control component and any value of a component IF this control component has attached another control component outside of the group

Please, as this is thread was not made clear and can be confusing and has a lot of text I have done another thread that has VISUAL examples and show exactly what I mean and wh ere is the problem

Bug? WHY I can´t modify the values of controls INSIDE group if linked?

I get the logic of it and I don't necessarily disagree on the stance of it. I've been using node-based systems for years and groupings have always behaved this way so I'm quite used to it. Products like Quartz Composer just behave this way as well. So when I break it down I quite get it. Logically what's inside of a group is just it's own system. Having the ability to access what's external would probably get messy given how it's illogical to alter data fr om what's feeding it. So changing data from within a group goes structurally against the flow of things in node based programs, so that's illogical. Interface wise, having a sudden appearance of some other, external node would probably make my head spin a bit before I say "Oh yeah, it's THAT node outside of THIS component that's feeding THIS data." Which seems easier just to be directed to that node instead.

I guess otherwise if you had 2 or more nodes being controlled by one node, which you have specific settings for, there's a likely chance you'd mix something up given you don't have visual confirmation of what that node's specifically connected to. In any case, if I change a variable, I'd probably throw off every other node somehow. (I wrote this in another thread.)

Aw well... that was a bit of my rambling but I think I get it. I still think it's a global design issue with every other nodey program. It's something that's small and yet a mildly frustrating issue.

With FilterForge I basically discovered myself hopping in and out of a tree of groupings and this basically got extremely annoying quickly. And likewise I'd say something like "Oh why not do this or that simple thing that you can already do...." I sometimes can't. I make huge trees and typically make complicated chains of stuff. I know most of us don't make ridiculous chains of stuff but I do. And there's some part wh ere the node-based interface design fails given hundreds of components doing this and that. Oh boy the complexity... the confusion.

So I don't know anymore. I'm honestly thinking "Huh... that makes better sense now" and I get the feeling "then again..." I always see the bigger picture of things and I get it anyway. I understand it. I just trip on the little things still and that's what I'm wondering about. What can we do slightly differently... sort of.

Quote
Sharandra Quote GMM wrote: Is it an issue? You´re kidding, right?

I agree with Sharandra, I could not understand HOW this could be true and this could NOT be an issue and may have thought also that it was not true, BUT regretably after what Skybase and Vladimir have told above it seems that this is totally true and THIS is the way it is done

I can´t still believe and do not want to accept and want to think is a joke, that you will NOT be able to modify the content of the components inside a group when you make a group as you are forced to connect the internal controls externally so they are shown on the settings tab.

So this makes using Groups much more complex and difficult than using them, so I think it may be better to avoid using them, the problem is with all the filters that will be using this groups downloaded from the FF library and that you will NOT be able to customize and modify them as you could before, because all the controls inside the groups will be disabled

Quote
Vladimir Golovin Solution: If you want to be able to always edit group's input values directly, create a separate instance of that group, just for editing -- and leave all inputs unconnected. This way, you'll keep the first group properly connected to the filter tree, and you will be able to edit contents and controls from within the group at the same time.

Sorry to say it, but this is a very bad solution from my point of view and not useful and practical

Well I do understand why it works this way, and using instances is a solution ofc, but I don´t really like having to create extra instances in complex filters just to tweak some values.

Why not make the filter controls panel independent from the results node?
Then you could access the controls from everywhere in the tree, that would not only solve this issue with groups, but you wouldn´t have to navigate around the tree so much anymore in general. It should be hideable like the components panel ofc.

Yeah maybe we are talking about different things, dunno.
I think Ray was talking about the problem, that you cannot change the value of controls if you are inside the group, but a control is connected outside. you have to leave the group, change the value, go back in.

What I meant was, that you could add the controls panel on the left side, like outside the editor, so that the controls are always accessible. That way you can change the values from controls connected to groups from within, without having to leave the group, or disconnect the controls, or create instances or whatever.

Why not? If it was always accessible then it wouldn´t matter where in the nested groups you are, you could always access the control? Or am I missing something?

Oh and it wouldn´t take you out of the group or away from wherever you are in the tree? (I haven´t dared to use that command since it caused crashes back then, and can´t try it out to see what happens right now lol)

Quote
That's exactly what I suggested in my idea above. Enabling Sel ect Filter Controls from within groups would allow you to see filter controls.

Yes that would help.

I understand the nested groups problem.
But I think it would be still very helpful, if at least the top level controls could be accessed fr om within groups.

Quote
Why not? If it was always accessible then it wouldn´t matter where in the nested groups you are, you could always access the control? Or am I missing something?

This way you could only access the top-level controls, filter's controls, but not the controls of the parent group your current group is located within.

Quote
Sharandra but even only being able to access top level controls would help a lot

I totally agree much with Sharandra, IF you could ONLY be able to acess to the top level controls, I mean that you could be able to modify the values of the color control components inside a group that is externally connected would really help a lot and would make the groups feature MUCH MORE useful and easy to use

How it is done now the groups, as I am sorry to say but for me I would prefer to NOT use groups and ignore them if you are forced to link the internal control components with external control components AND then after this you CAN´T modify any the linked control components inside the group.

So as said already, if you could allow to modify them inside when linked from outside would be a very good thing

NOTE
"you are forced to link" I mean that IF you want that this color control is shown in the settings tab, you must connect it in the outside of the group, and then doing this the internal control component is disabled

Well it would be better than no access at all and I´d rather have that, than nothing until a better solution is be found:-)

Quote
As said, I may use groups ONLY if you do not need to have internal control components that needs to be connected from outside

Well, then don´t use them *shrugs*

Having only the external controls show up is fine. If all the unconnected controls in groups would show in the list, it would be a mess. It´s also useful, because you can use color controls in groups, without giving access to the user, for example.