I have just discovered this strange behaviour of FL Studio. It seems to rescale the GUI of a Cabbage VST plugin. Why do I care?
I use the FFT display from the Examples. The mouse is activated within the bounds of the display in order to project a frequency value. It works with Cabbage play, but in FL Studio the mouse operating frame is off-set and scaled (multiplied by a value).
I do not know if there is anything to do from Cabbage side to trace this problem. Please, let me know, if this post has some value, in order to provide more data and photo evidence.
FL Studio rescales VST plugin GUI
I use Windows settings custom layout scaling of 125%. I suspect this is the problem. FL Studio takes into account this setting, while Cabbage doesn’t…
I think that is likely to be the issue. I can vaguely recall this issue popping up before. Hang on, I’ll look through the docs. If you had access to the current DPI you could scale accordingly right? Or would that work 
I prepare a demonstration of the problem.
1 Like
There are two red dots at (80,80) and (100,100). Although I failed to reproduce the cursor, it always points at the center of the dot (80,80).
Windows display scale 100% = everything is OK in both Cabbage and FLStudio. The png file is of 200x200 pixel size. The label has its left-top corner at the cursor and prints the x and y position.
Window display scale 125% = Cabbage: The png file is of 250%250 size. Notice that everything is enlarged. The label has its left-top corner at the cursor and prints the x and y position. Yet, the MOUSE_X, MOUSE_Y pair has values that follow the geometry of the plugin GUI.
This situation changes inside FL Studio!
The png file is of 250x250 size. The two red dots are positioned at the expected places according to the geometry of the plaugin GUI. The cursor still points at the (80,80) dot. However, the 'MOUSE_X, MOUSE_Y pair now reads the values multiplies by 1.25 and prints the label to the position that corresponds to these values. Here is the problem:
chnget MOUSE reads the pixels with windows scaling taken intio account
cabbageSet "label's position" interprets the MOUSE coordinates in accordance with the plugin GUI’s geometry, not taking into account Windows scaling.
The poroblem could be corrected with something like
if channel FLStudio == 1 then cabbageSet "label's position", MOUSE /= 1.25
Here is the code I used for this test.
<Cabbage>
form caption("Scale problem") size(200, 200), guiMode("queue"), pluginId("def1")
button bounds( 75, 75, 10, 10) channel("dot1") value(1) corners(10) colour:0(0,0,0) colour:1(200, 0, 0) text("","")
button bounds( 95, 95, 10, 10) channel("dot2") value(1) corners(10) colour:0(0,0,0) colour:1(200, 0, 0) text("","")
label bounds( 80, 80, 95, 13) channel("cursor") text("") align("right") visible(1) fontColour("black") colour(255,255,255,200)
</Cabbage>
<CsoundSynthesizer>
<CsOptions>
-n -d -+rtmidi=NULL -M0 --midi-key-cps=4 --midi-velocity-amp=5
</CsOptions>
<CsInstruments>
; Initialize the global variables.
ksmps = 32
nchnls = 2
0dbfs = 1
;instrument will be triggered by keyboard widget
instr 1
kEnv madsr .1, .2, .6, .4
aOut vco2 p5, p4
outs aOut*kEnv, aOut*kEnv
endin
instr 2
kMOUSE_X chnget "MOUSE_X"
kMOUSE_Y chnget "MOUSE_Y"
if changed(kMOUSE_X,kMOUSE_Y)==1 then
Stext sprintfk "x= %d, y = %d",kMOUSE_X, kMOUSE_Y
cabbageSet 1, "cursor", "bounds", kMOUSE_X, kMOUSE_Y, 95, 13
cabbageSet 1, "cursor", "text", Stext
endif
endin
</CsInstruments>
<CsScore>
;causes Csound to run for about 7000 years...
f0 z
i 2 0 -1
</CsScore>
</CsoundSynthesizer>
But that’s only if you have access to the scaling, i.e., 1.25 or whatever? So if I was able to broadcast the scaling to a reserved channel, then it would be possible to do the same as above, only dynamically? Does that seem like a reasonable solution?
Why FL Studio and cabbage read different mouse coordinates?
Here is another way to express my conclusion.
FL Studio returns the actual pixel coordinates relevant to the top left corner of the frame.
Cabbage channels read a number relevant to its geometry. The actual pixels divided by Windows scaling. (Actual pixels are 100, but it reads 80 in order to place the label on the dot).
Another way to express the problem: Why, inside FL Studio, the bounds Cabbage opcode understand pixel values in a different way compared to the MOUSE_X and MOUSE_Y channels?
If the Windows scaling is a global variable that is used by Cabbage, then it could be taken into account. By whom is another question. By the code (the programmer is aware of the feature and reserves a line of csound code exclusively for use within FL Studio) or by the dll (or vst3) file.
I honestly have no idea. Have you tried using Cabbage’s own plugin UI scaler? Perhaps that gives better results?
combobox bounds(10, 180, 80, 20), mode("resize"), value(3)
Please, let me know if channel FLStudio should work with following code… (cause it doesnt). It seems that kFLStudio = 0 inside FL Studio.
kFLStudio chnget "FLStudio"
if kFLStudio==1 then
cabbageSet 1, "host", "text", "FL Studio"
else
cabbageSet 1, "host", "text", "Cabbage"
endif
Just tested, and fails for me too. Let me take a look…
So I just tried with the latest build and it seems to work fine again.
https://dev.azure.com/rorywalsh/cabbage/_build/results?buildId=2528&view=artifacts&pathAsName=false&type=publishedArtifacts
I really can’t explain the issue with 2.9.0, but hopefully it’s resolved now 
2.9.45 worked also for me!! 
My FFT display works perfectly inside FL Studio!
I decide not to experiment with mode("resize") and move on!
BTW, 2.9.45 also fixed another “bug”. 2.9.0 (on Windows) crashed every time I tried to export a plugin, having previously “played” the csd file inside Cabbage. Export worked only when exporting was the first action of a new Cabbage instance. With 2.9.45 everything is OK.
Please, let me know, if you fixed the problem I reported on github cause I’d rather not update my main working app on my linux laptop. My blood pressure goes high whenever I manually update apps on Linux.
Shoot, that one escaped me completely. I’ll be back in the land of Linux tomorrow, I’ll take a look then 
I just ran Cabbage here on Linux but I am using kDialog and not Zenity. Hence, no issues. I’ll see if I can get access to a Zenity linux and test there. I might have a laptop somewhere with it installed…
I installed 2.9.49 on Ubuntu 22.04LTS.
Now the “select new project type” window remains on top of “zenity”. (“zenity” always stays behind.) I can always click a ‘project type’ and it always open a new “zenity”.)
I am not sure what the expected behaviour was supposed to be.
Can you record a screencast so I can here a better idea of the issue?
Does this help?
(The second time zenity stayed on top.)
I see the issue now. Zenity is showing up behind the modal window. Yeah, that’s not a great situation to find yourself in. I can try to experiment with some of the modal window settings to see if I can stop this from happening. Worst case scenario, I can add a new project type sub-menu to the file menu. So you could just create a new synth/effect/etc from File->New->Project Type…?
Tbh, this might be easier than having to dig through OS callbacks.
Can’t you just close the modal window as soon as the OS dialogue window appears?