Plugin resizing (scroll down for latest solution)

[hdale94]

A feature I was thinking would be really nice to have is a resize-functionality for the full plugin window. I notice that some VST’s have a resizing functionality by dragging the downright corner to another position, but also other plugins have this through a combobox with percentages (100%, 125%, 150%). Also it would be really good for future-proofing plugins (resolution)

[rorywalsh]

This request has popped up quite a bit. To be honest, it’s not a easy one to add. I think a 100/125/150% option might be the handiest because random resizing does not work well at all. Let me think about it.

[t_grey]

I’ve been designing for a relatively tiny screen, and have concerns about keeping it reasonable in a higher res use case… so this is something that would definitely be useful to me!

[mathieu_dombrock]

I think that doing predefined scaling options would be nice. Having options to scale down to 75%, 50% ect. would be great as well.

IMO this is a pretty reasonable compromise and a lot of fairly high-end soft synths only have preset scaling options.

However, scaling is actually almost something that can be implemented in the current release.

I’ve attached an example csd to demonstrate how close we can already get. I think with some math this could even work for more dynamic scaling options.

Essentially everything except for setting the size of the window (form) and changing font sizes seems to be possible (I’ve read some posts about using fontsize() but I can’t get this working myself.)

If we could even just get more control over manually resizing things I don’t think that building custom scaling solutions would really be that tricky or cumbersome.

resizeTest.csd (1.4 KB) [Edited to remove some unused test code]

Edit:
I’m attaching another csd that demonstrates a more dynamic approach to resizing that doesn’t use preset scaling values. This example has the same limitations on window and text resizing that the first one does.

I also want to say these are really simple tests. I’m sure that attempting to implement something like this into a full featured plugin would bring up a set of problems I didn’t encounter here.

dynamicResizeTest.csd (1.1 KB)

[rorywalsh]

I actually thought I could simplify this be placing everything in a plant and then simply resizing that dynamically, but that doesn’t seem to work, although it should. That would make this much more streamlined. I will have to look into how to change plugin sizes dynamically. I’m not sure how VST/AU handle this.

[EDIT] Nice example by the way. In practice it’s always better to send channel updates ONLY when a value has changed. In your string messages get send to Csound on every k-cycle. This will waste CPU cycles…

[rorywalsh]

This is what I had in mind (see below). I will take a look at how best to dynamically change the size of the plugin when I get a chance. Note that Logic and other Apple based DAWs handle resizing themselves. So it’s best to avoid any kind of scaling routines in your Cabbage code if you are targeting Logic. You can do a chnget:i("Logic") to determine if your plugin has been launched in Logic.

[Kzz]

Resizing looks nice)

[rorywalsh]

Looks better now Scroll down to see most recent solution…

This version doesn't even require the use of plants. Just attach an identifier channel to the form widget and set the scale identifier in your code:

instr 1
kSize chnget "sizes"
if changed:k(kSize) == 1 then
    SMessage sprintfk "scale(%f)", kSize/2
    chnset SMessage, "formIdent"
endif
endin 

One caveat, it's works fine in standard DAWs, but might cause a few issues in the Cabbage host. I this a few debug assertions when I run it here, but I think the release build should be Ok. I'll push my changes now to Azure and you an try it out when it's done. I've attached the full test .csd. [CabbagePlugin.csd|attachment](upload://qWFFKNms36U8crOc3mgtC5ln6Uw.csd) (1.4 KB) p.s. I've just realised that I need to save the current scale when DAW sessions are being saved, that's not currently working :roll_eyes: Also note that if you are using images, you may need to swap them when you resize.

[Kzz]

i guess , MOUSE_X and Y, need to be changed too after resize? if they seted to react on specific area

[rorywalsh]

Best would be for you to scale them according to the new scale factor. So always do:

kMouseX = chnget:k("MOUSE_X)*kScaleFactor

Or? That should work?

[Kzz]

got it

[lindsey]

I think you are right for resizing plugin

[hdale94]

Nice Rory!

I notice when I resize it down in Cabbage, something weird happens

Edit: Ah I see what you wrote, will test in several DAWs now
Edit 2: Works nicely

[rorywalsh]

Yeah, I will sort that once I find the time, but it’s not high on my todo list to be honest…

[hdale94]

Being able to resize the plugin is actually a game-changer, and it’s so easy to implement in Cabbage. You should probably put it in the examples folder?

[rorywalsh]

It’s already there see ResizingPlugin.csd

[hdale94]

Ah I’m probably not on the newest build
Edit: I’m on 2.5.18

[rorywalsh]

Sorry, it was in my local examples folder but I hadn’t added it to the git repo! Thanks. It’s there now.

[t_grey]

Out of curiosity… what happens if widgets get their location set via x/y position in an identchannel, will the pixel positions auto-rescale to follow or will the math for these need to be done before sending the values as well?

[rorywalsh]

The whole thing should still scale accordingly. I don’t actually call any resize operations on the individual widgets. It’s a higher level operation. So I assume everything will still scale correctly.