Hi,
Is it better in term of performances to store widget states into variables, and use these variables like here, when I need them :
ienva chnget "enva"
ienvd chnget "envd"
ienvs chnget "envs"
ienvr chnget "envr"
kMyEnv madsr ienva, ienvd, ienvs, ienvr, 0, 1
or directly read the values of the widget when I need them ?
kMyEnv madsr chnget:i("enva"), chnget:i("envd"), chnget:i("envs"), chnget:i("envr"), 0, 1
I’m trying to find the best way to save CPU/RAM
Thanks in advance,
I’m not sure. My gut says that calling the opcodes inline is probably more efficient but i I doubt very much that either will effect performance too much.
The number of channels you have might. Do you have lots and lots of channels?
Alright, calling the opcode inline seems easier to write by the way so I will go for it !
And my number of CSound channels = 2
But the number of widget channel (don’t know if that makes sense) is around 150
EDIT : I tried and, when I call the opcode inline to read widget, it consumes more CPU (about 10-20% more) than when I store widget values inside variables.
I don’t really understand why…
There should be no difference in performance terms between those two versions, but if you use some of those variables more than one time in the same instrument, then the first version is better, because using the same variable more times is faster than calling the ‘chnget’ opcode each time you need that variable.
As @mauro points out, if you are using those channels more than once in an instrument then it is better to create variable.
This is a lot. The channel system in Cabbage is not callback based so on every k-period Cabbage will poll each channel for a new value. The more channels you have the more congested things will be on each k boundary.
Do users really need 150 different controls? It seems somewhat excessive?
I think in this case he should hide controls as much as possible, so that the code does a polling only on the controls that are actually visible. Anyway I think that displaying 150 controls is not good from an ergonomic point of view (apart from the excessive polling).
Hiding those control won’t stop Cabbage from polling their values. It’s something that could be added. But I think the first thing that needs to be addressed here is the enormous number of controls you have on a single plugin.
Yes, I was referring only to the workload on the Csound code. I didn’t thought that the <Cabbage>...</Cabbage> section is polled anyway from Cabbage itself.
That number of controls is great but it’s not impossible. Let’s suppose you are working on a parametric synth when you want to enable the user to be able to change independently 5 parameters of each one of the 88 notes you could play on a full 88-keys midi keyboard. Then you would have 5*88 = 440 parameters (and 5 parameters for note is not too much for some synths…)!
Each widget that has an associated Csound channel is polled for updated values from on each k-cycle. This is so that Cabbage can catch any chnset calls from Csound and update accordingly. Things would be a heck of a lot faster if there wasn’t two-way communication between Cabbage and Csound, but it’s a nice feature.
It could be very nice if the user could write something like:
<Cabbage>
<group name="cpuDemandingGroup" enabled="false">
somewidget_1 ...
somewidget_2 ...
...
somewidget_400 ...
</group>
<group name="lightGroup" enabled="true">
somewidget_1 ...
somewidget_2 ...
somewidget_3 ...
</group>
</Cabbage>
and then Cabbage would poll only the enabled=“true” groups. Then we should have some button to enable/disable a group… Maybe a special widget that is completely independent from the Csound code, so that it should be faster.
EDIT: after having rethought it, I think it could be useful to enable/disable the groups from the Csound code itself, so there should be a special widget to allow enabling/disabling of the groups from within Csound code.
First thoughts here are we already have group abstractions in the form of plants which have visible() identifier, which can be set from Csound.
So it would just be a matter of preventing any controls contained within a hidden plant from updated. With the one caveat that the plant itself will continue to be polled so that the user can enable and disable it as they wish.
It would all happen in here:
That would be very nice (I didn’t know of plants).
It’s very interesting, but I don’t see a “visible” identifier in the plants documentation… And the “Custom plant imports” link in the webpage you posted is broken.
My bad, I need to fix the custom plant import. For a list of identifiers for plants check the groupbox and image widget entries as they are the only widget that can be parents. All identifiers are valid when they are used to create plants.
Well, the synth will have 4 oscillators, 4 enveloppes, 4 filters, 2 lfo, some FX
But they will be grouped in tabs (using groups, visible(1) to show the active tab) and these tabs buttons, oscillators selection button for the enveloppes for example are already like 16 controls, but the user will just see tabs he can click to display one of the four envelopes available
So in from of the user, there are way less controls !
Cool. Let me take a look at implementing some of things we discussed here. Should make things a little quicker.
I just pushed through some changes there that might help. Child components of hidden plants will no longer be polled for channel data on each k-cycle. In my tests here this helped improve performance. Note this only works for child components as their visibility can be be enabling by the parent.
I’m having some issues with my Windows machine at the moment. And my automated builds are screwed up since Steinberg decided to remove the VST2 SDK from their servers. Please leave it with me. I should have a new Windows machine shortly.
p.s. I also added support for loading remote URLs with infobutton. Just pass the full URL with http://...
Very nice! That could improve the GUI performance a lot if you use many widgets grouped in a few plants and, as a side effect, it makes you create better organized interfaces! 
I’m still having issues with the full build but in the meantime you can try this one. You can simple swap the files in this zip with the ones in your Cabbage folder. Let me know if it works Ok.
@mauro this build is from the develop branch. I made a new branch to investiage some weirdness on Windows. I will merge to master once I get to test out a few things on different platforms. The dev branch uses the latest master release of JUCE.