This simple example changes colour of images depending on slider position. It works fine manually but not with automation (in ver. 2.8.128). Maybe this can enlighten some of the previously reported issues?
<Cabbage> bounds(0, 0, 0, 0)
form caption("test cabbageSet automation") size(300, 200), guiMode("queue"), colour(0,0,0) pluginId("tcs1")
image bounds(18, 92, 60, 15) channel("image1") _sliderImage(1)
image bounds(108, 92, 60, 15) channel("image2") _sliderImage(1)
image bounds(194, 92, 60, 15) channel("image3") _sliderImage(1)
hslider bounds(44, 62, 191, 23) range(0, 2, 1, 1, 1) channel("ImageSlider") popupText("0")
</Cabbage>
<CsoundSynthesizer>
<CsOptions>
-n -d -+rtmidi=NULL -M0 -m0d
</CsOptions>
<CsInstruments>
instr 1
SImages[] cabbageGetWidgetChannels "_sliderImage(1)"
kImageSlider, kImageSliderChanged cabbageGetValue "ImageSlider"
if kImageSliderChanged == 1 then
kind = 0
while kind < lenarray(SImages) do
if kind == kImageSlider then
cabbageSet 1, SImages[kind], "colour", 255, 0, 0, 255
else
cabbageSet 1, SImages[kind], "colour", 255, 255, 255, 255
endif
kind += 1
od
endif
endin
</CsInstruments>
<CsScore>
;causes Csound to run for about 7000 years...
f0 z
i 1 0 -1
</CsScore>
</CsoundSynthesizer>
Avoiding the if statement within the while loops seems to resolve this issue, a workaround being to “reset” all images first and then set the selected one:
if kImageSliderChanged == 1 then
kind = 0
while kind < lenarray(SImages) do
cabbageSet 1, SImages[kind], "colour", 255, 255, 255, 255
kind += 1
od
cabbageSet 1, SImages[kImageSlider], "colour", 255, 0, 0, 255
endif
So this is probably not related to the other issues linked above and might be simply due to how Csounds if statements work or not work within loops? But since it works with a mouse and not with automation, there might be something related to how Cabbage handles this?
Thanks for explaining. I’m glad it is not a bug in Cabbage but in me instead.
This might help to correct my understanding how the interface works. I though DAW sends automation to Widgets (replaying mouse gestures) and Widgets to Csound, but based on this it seems that DAW sends directly to Csound, while being rescaled by Widget parameters? There seems to be separate mechanism for rescaling input, since mouse gestures work also without the need for rounding and mouse input is float, right?
No, the host calls a set parameter function, which is part of the relevant plugin SDK, (vst/au/etc). This is always in the range of 0 to 1, and will be doubles or floats depending on what host it is. The widgets are only in use when they are seen. In fact, each time you close the editor window, all widgets are deleted and freed from memory. Conversely, when a plugin window is opened, the interface is once again dynamically created.
Since writing Cabbage 2, I have learned of ways to manipulate the host data and apply the same scaling/increment/etc as the associated widget, but it would take some major surgery. Something for Cabbage 3 maybe. In fact, I think it might well be time for another complete rewrite
Thanks for the background and the courage to think about Cabbage “refreshments”.
When you have the possibility, I just wanted to remind you again to check the Live specific issue with automation (when number of widgets is too large) here: Non-latched buttons & automation
Thanks!!!