Cabbage Logo
Back to Cabbage Site

Best way to use variables

Is the code bellow a “child component” ? Should I notice performance improvement ?

groupbox bounds(0, 20, 305, 110), visible(1), identchannel("GROUP_OSC1"), plant("GUI_OSC1"){ image bounds(0, 0, 305, 110), colour(20, 30, 40, 255), $bgtabstyle label bounds(245,4,50,20), text("OSC1") rslider bounds(6, 6, 45, 45), channel("osc1wave1"), range(0, 8, 0, 1, 1) , text("Wave1"), $rsliderstyle rslider bounds(48, 6, 45, 45), channel("osc1wave2"), range(0, 8, 0, 1, 1), text("Wave2"), $rsliderstyle rslider bounds(6, 56, 45, 45), channel("osc1morph"), range(0, 0.999, 0, 1, 0.001), text("Morph"), $rsliderstyle rslider bounds(86, 50, 50, 50), channel("osc1vol"), range(0, 1, 1, 0.5, 0.001), text("Vol"), $rsliderstyle rslider bounds(124, 50, 50, 50), channel("osc1det"), range(0.001, 0.5, 0, 0.5, 0.001), text("Detune"), $rsliderstyle rslider bounds(164, 50, 50, 50), channel("osc1wid"), range(0.001, 1, 1, 0.5, 0.001), text("Width"), $rsliderstyle rslider bounds(204, 50, 50, 50), channel("osc1phase"), range(0.001, 1, 0, 0.5, 0.001), text("Phase"), $rsliderstyle nslider bounds(50, 56, 40, 42), channel("osc1voice"), range(1, 8, 1, 1, 1), text("Voices"), $nsliderstyle nslider bounds(254, 30, 38, 35), channel("osc1octave"), range(-3, 3, 0, 1, 1), text("Octave"), $nsliderstyle nslider bounds(254, 65, 38, 35), channel("osc1semi"), range(-12, 12, 0, 0.5, 1), text("Semi"), $nsliderstyle rslider bounds(94, 8, 45, 40), channel("osc1cent"), range(-100, 100, 0, 1, 1)text("Cent"), $rsliderstyle label bounds(162, 32, 100, 13), text("Retrig.") checkbox bounds(170, 30, 15, 15), channel("osc1retrig"),text("Retrig"), , $checkboxstyle }

And thanks a lot ! HTML files, and direct URL request work perfectly :slight_smile:

I forgot to add the same thing to images, but will do. Yes, when you hide this plant, none of the child components will be queried for values. Note in my test I was using some profiling tools, which makes it easier to see a different in performance. If this doesn’t help at all, PM me your file and I can run it through a profiler here. although it won’t be until Monday before I get a chance to look at it.

1 Like

Btw, you not calling chnset for any channels at each k-boundary by any chance? That wouldn’t be good. All your identchannel chnset calls should be done once when needed. I always wrap them in an if statement:

kTrigButton chnget "button2"
if changed(kTrigButton))==1 then
    chnget "visible(1)", "plant1"
endif
1 Like

Yes I do the same as you, they are only called when the user click on a tab button

[quote=“rorywalsh, post:20, topic:1236”]
@mauro this build is from the develop branch. I made a new branch to investiage some weirdness on Windows.
[/quote]What weirdness? Maybe I can help you investigate? I use Cabbage mainly on a Windows 10 PC. On a Linux PC I tried Cabbage inside a Win7 virtual machine and, apart some graphical glitches that I think are dependent from the software emulated vga, it works quite well.

[quote=“rorywalsh, post:20, topic:1236”]
in the meantime you can try this one
[/quote]I will try it when I get home. :slight_smile:

Btw, the performance improvement won’t be all that notable, as Cabbage still needs to check each widget’s visibility. But it’s incurs less overhead than checking for the existence of strings on channels. in my test I saw a clear improvement, although you may need to optimise the instrument in other ways too.

1 Like

Hey Rory, actually, I’m having some trouble with the new version you provide above :

This example works with the older Cabbage version (the current official version)
When you click on PITCH or FILTER button, a Rotary Slider is supposed to appear.

With the test version you gave above, nothing happens

testdebug.csd (1.4 KB)

And also, sometimes Cabbage exits when I save/run, but I can’t tell how to reproduce, it’s really random.

Thanks. I had to make some changes to other parts of the code base which might be the problem here. I’ll take a look. Probably best to revert to the previous version for now…

[edit] Hmm. Looks like my visible change fails one very important test when the widgets themselves are made invisible regardless of containing plants! Just preparing a new build for you now…

1 Like

My naive implementation makes me realise that for this to work we need to be able to able to control widget visibility through other means. One possible solution would be to have a reserved channel that holds a list of widgets that are to be polled. This wouldn’t break any existing code, and could easily be added to earlier instruments. We just have to come up with a possible syntax. Maybe something like:

chnget "widget_channel1:widget_channel2: ...", "REMOVE_WIDGET_POLLING"
chnget "widget_channel1:widget_channel2: ...", "ADD_WIDGET_POLLING"

Or a way to enable or disable in single go:

chnget "widget_channel1:1 widget_channel2:0 ...", "WIDGET_POLLING"

where widget_channel is the channel given to a particular widget. 0 or 1 will enable/disable the widget. Note it would only apply to widgets that use channels as they are the only ones queried on each k-cycle. It should be relatively simple to maintain a list of widgets in Csound and update accordingly. Let me know what you think. The performance gains might not be that much as we will still need to check the polling channel on each k-cycle. But it might be worth a shot.

I really like the [quote=“rorywalsh, post:29, topic:1236”]
way to enable or disable in single go
[/quote]

So if I understand : If I have 3 tabs (groups of widget actually), when the user click on the 1st tab, I will have to add a
chnget "volume_tab1:1 pan_tab1:1 ...", "WIDGET_ POLLING"
chnget "volume_tab2:0 pan_tab2:0 ...", "WIDGET_ POLLING"
chnget "volume_tab3:0 pan_tab3:0 ...", "WIDGET_ POLLING"

Is that correct ?

That’s the idea. But it still need some thought. For example, plants don’t have a channel. We’d need to add one if we want to quickly enable/disable widgets?

What is the problem in enabling/disabling “visiblity+polling” just for the internal widgets of a plant?

1 Like

That’s another option. I guess if people are concerned enough about this they will use plants if they are the only way enable this type of behaviour? I would certainly rather that than what I proposed…

1 Like

What’s the current status of plants regarding the visibility/polling feature? I thought it would not poll anymore for hidden widgets inside the plant…

I had to revert back. But I will revisit in the next day or so. If the restriction is that only child widgets of plants can have their polling disabled then it should be simple enough to add.

Personally, I vote for the plants solution. :slight_smile:
It appears to me the most simpler to implement and it should do the job right
The only doubt I have is: what happens for plants inside plants? Is nesting supported?

1 Like

It works, but it’s not supported!

A thing that bothers me when using plants is that after you place some widgets inside them, you cannot move/edit/insert/remove them anymore in the GUI…
From what I’ve seen, for now you have to create a plant in a dummy project, place all the objects so that the reference is the (0, 0) top-left point of the plugin window, and then, after you are satisfied with the widget appearence, copy&paste the code in your real project, after a groupbox or image parent widget code.

It would be nice to have some way to edit the children widgets always with the plugin GUI. For example, you could make so that if the user press the TAB key when you are on a parent widget, Cabbage would switch to the widget children area (setting the coordinates so that (0,0) is the topleft position of the parent widget) and let you edit all the objects inside the plant directly in the GUI. Another press on TAB and Cabbage would return to the parent widget area (and reset the coordinates to the topleft of the window that contains the parent widget).

1 Like

Cabbage 1 allowed user to select a group of widgets and convert them to a plant. And at any stage you could break the group up again. It didn’t make it into Cabbage 2. I agree, it would be nice to have more control of these things.