COCKOS
CONFEDERATED FORUMS
Cockos : REAPER : NINJAM : Forums
Forum Home : Register : FAQ : Members List : Search :

Go Back   Cockos Incorporated Forums > Other Software Discussion > WDL users forum

Reply
 
Thread Tools Display Modes
Old 11-17-2017, 02:50 PM   #1
Bobflip
Human being with feelings
 
Join Date: Nov 2016
Posts: 341
Default Change a control's Bitmap at run time?

Been exploring but haven't got anything to work yet, is it possible to change the bitmap of a control such as an IKnobMultiControl, to allow the user to customise the interface?
Bobflip is offline   Reply With Quote
Old 11-17-2017, 03:00 PM   #2
random_id
Human being with feelings
 
random_id's Avatar
 
Join Date: May 2012
Location: PA, USA
Posts: 356
Default

I have been thinking about this, too.

It would allow for users to customize the knobs, and it would also allow for some space-saving. My T-Chain plugin has a lot of assets that get compiled into a single binary. If a user installs AU, VST, VST3, and AAX, that means there are a lot of duplicated images. I would love to be able to load the bitmaps at runtime from a common folder (if there isn't performance issues).
__________________
Website: LVC-Audio
random_id is offline   Reply With Quote
Old 11-17-2017, 07:28 PM   #3
Bobflip
Human being with feelings
 
Join Date: Nov 2016
Posts: 341
Default

I was thinking of images contained within the binary's resources folder, but I can see how your approach would suit your situation better.
Bobflip is offline   Reply With Quote
Old 11-17-2017, 07:47 PM   #4
Youlean
Human being with feelings
 
Youlean's Avatar
 
Join Date: May 2015
Location: Serbia
Posts: 654
Default

Loading bitmaps from common folder is possible if you want to load it from constructor. If you load bitmaps elsewhere it will break GUI scaling in my branch.

Since we are there I would like to ask you guys that are using the bitmaps, is it acceptable bitmaps not to be shared in memory for every plugin instance? If it is, we might make working with bitmaps a whole lot better using cairo!

BTW, if you want to test memory usage just remove static keyword from these 2 lines of code in my branch in IGraphics.cpp
Code:
static GUIResizeBitmapStorage storeLoadedBitmap;
static BitmapStorage s_bitmapCache;
__________________
Website | Facebook Page | IPlug-Youlean
Youlean is offline   Reply With Quote
Old 11-18-2017, 12:34 AM   #5
stw
Human being with feelings
 
stw's Avatar
 
Join Date: Apr 2012
Posts: 279
Default

Quote:
Originally Posted by Bobflip View Post
Been exploring but haven't got anything to work yet, is it possible to change the bitmap of a control such as an IKnobMultiControl, to allow the user to customise the interface?
As Youlean says it's easy if you do it in the constructor. You can change you IControl that way, that you pass more than one bitmap address. You can then simply change the selected bitmap in a addicted function. E.g. i use two alternative of knob controls in my current plug which works simply like that.

Code:
// bitmap1 and bitmap2 are bitmap pointers passed to the constructor
// mBitmap is the IBitmapControl member

void SetAuxBitmap(bool set = false)
	{
		mBitmap = (set)? bitmap2 : bitmap1;
		Redraw();
	}
stw is offline   Reply With Quote
Old 11-18-2017, 02:01 AM   #6
earlevel
Human being with feelings
 
Join Date: Dec 2015
Posts: 331
Default

I change bitmaps and locations on the fly. My plugin has several models, and while they mostly use the same set of controls, they look different. I pre-cache (LoadIBitmap) all the bitmaps, for a quick and smooth change of models.

My knobs (I call IMutableKnobControl) inherit from IKnobMultiControl (well, I have an in-between, too, a non-mutable highlight control, which also uses bitmaps). To change the knob bitmap and location, basically this method (in my actual one, I also manage a highlight bitmap, so a few more lines):

Code:
    void ChangeKnob(int x, int y, IBitmap* pBitmap) {
        mBitmap = *pBitmap;
        mRECT = mTargetRECT = IRECT(x, y, pBitmap);
    }
earlevel is offline   Reply With Quote
Old 11-18-2017, 05:24 AM   #7
Youlean
Human being with feelings
 
Youlean's Avatar
 
Join Date: May 2015
Location: Serbia
Posts: 654
Default

I just want to add, if we don't need to share bitmaps from same location in RAM for all plugin instances we can make bitmap GUI scaling behave almost like vector regarding speed and functionality. Currently when you load plugin you add bitmaps to the ram and every other plugin that uses same bitmaps will use bitmaps that are already loaded in ram. In that way you are saving the ram. So basically if you have bitmaps that are 10mb by not sharing memory you will have 10mb per plugin more ram usage. So I am asking how big are your bitmaps..
__________________
Website | Facebook Page | IPlug-Youlean
Youlean is offline   Reply With Quote
Old 11-18-2017, 06:53 AM   #8
random_id
Human being with feelings
 
random_id's Avatar
 
Join Date: May 2012
Location: PA, USA
Posts: 356
Default

I don't want to sidetrack the original question by Bobflip, but here is what I have been thinking about:

My T-Chain plugin loads various plugin modules, each with different assets (due to 3d lighting). The current size of all of my pngs are around 30MB, but I am continuing to add more. The compiled binaries are about 30MB for VST/VST3, and about 100MB for AAX. Most of my other plugins are about 1/8th the size. The installers for T-Chain are up to 350MB, with all compression options turned on.

I would like to reduce the installer size. I guess I could start splitting up the installers by 32 and 64 bit versions, and/or plugin formats. My long-term concern would be if I continue to add assets, at what point does it become a problem within the DAW. I guess it makes more sense to share the assets in RAM than have each plugin instance consume more memory for bitmaps. That could get ugly.

Going back to the original question by Bobflip, I think it would be really cool to have users create bitmaps for plugins, and use something like an XML file to place the items. Letting people completely skin the plugins would be a nice feature.
__________________
Website: LVC-Audio
random_id is offline   Reply With Quote
Old 11-18-2017, 09:46 AM   #9
Bobflip
Human being with feelings
 
Join Date: Nov 2016
Posts: 341
Default

Thanks for the pointers, will have a go at implementing that today!


Regarding the graphics and memory question, a lot of my graphics are generated on the fly within the plugin I'm writing and so there's currently less than a MB of PNGs. So I'll bow out of that side of the discussion for now, but freely carry on as it's certainly something that could be looked at.
Bobflip is offline   Reply With Quote
Old 11-18-2017, 11:15 AM   #10
Bobflip
Human being with feelings
 
Join Date: Nov 2016
Posts: 341
Default

Yep, got this working with both stw's and Earlevel's approaches, but will be using Earlevel's as this doesn't add extra clutter to the constructor and easily allows for using as many different images as required.
Bobflip is offline   Reply With Quote
Old 11-19-2017, 09:01 AM   #11
Bobflip
Human being with feelings
 
Join Date: Nov 2016
Posts: 341
Default

I wonder, is there a case for adding a version of earlevel's code to the base IControl? I've renamed it to ChangeBitmap in my controls as I have it on sliders and a couple of interface bitmaps as well, but it feels like its potential use could be widespread enough that it could be included as standard.
Bobflip is offline   Reply With Quote
Old 11-22-2017, 05:36 PM   #12
Youlean
Human being with feelings
 
Youlean's Avatar
 
Join Date: May 2015
Location: Serbia
Posts: 654
Default

Quote:
Originally Posted by random_id View Post
My T-Chain plugin loads various plugin modules, each with different assets (due to 3d lighting). The current size of all of my pngs are around 30MB, but I am continuing to add more. The compiled binaries are about 30MB for VST/VST3, and about 100MB for AAX. Most of my other plugins are about 1/8th the size. The installers for T-Chain are up to 350MB, with all compression options turned on.

I would like to reduce the installer size. I guess I could start splitting up the installers by 32 and 64 bit versions, and/or plugin formats. My long-term concern would be if I continue to add assets, at what point does it become a problem within the DAW. I guess it makes more sense to share the assets in RAM than have each plugin instance consume more memory for bitmaps. That could get ugly.
I don't see much problem adding 3-4mb more RAM usage per plugin for your regular one. If you look it other way around, T-Chain is heavy plugin with a lot of modules and naturally people could expect higher RAM usage, also you can add to memory only bitmaps that are being used, so that could limit RAM a lot I think.

As for benefits, you can basically reduce installer to 50-100mb by loading bitmaps from run time.
if we don't share RAM we can also expect huge performance benefits when scaling like 5x-15x faster and that would be extremely helpful if you have a lot of bitmaps to scale like in T-Chain. Also, current implementation of scaling is fundamentally flawed since if you have two plugin interfaces open at the same time and you scale graphics in one bitmaps will be scaled for second plugin too, so the workaround is to blackout the screen in second plugin instance and to request interface reopening...

I have not worked yet with the cairo and the bitmaps so it might be possible that cairo automatically shares RAM for same bitmaps, but we will see. Also there is an option to scale bitmaps at every redraw, but I guess cairo would cache that automatically.
__________________
Website | Facebook Page | IPlug-Youlean
Youlean is offline   Reply With Quote
Old 11-22-2017, 05:38 PM   #13
Youlean
Human being with feelings
 
Youlean's Avatar
 
Join Date: May 2015
Location: Serbia
Posts: 654
Default

Quote:
Originally Posted by Bobflip View Post
I wonder, is there a case for adding a version of earlevel's code to the base IControl? I've renamed it to ChangeBitmap in my controls as I have it on sliders and a couple of interface bitmaps as well, but it feels like its potential use could be widespread enough that it could be included as standard.
Sure, update controls and create pull request and I will update my fork.
__________________
Website | Facebook Page | IPlug-Youlean
Youlean is offline   Reply With Quote
Old 11-24-2017, 07:28 AM   #14
Bobflip
Human being with feelings
 
Join Date: Nov 2016
Posts: 341
Default

Quote:
Originally Posted by Youlean View Post
Sure, update controls and create pull request and I will update my fork.
Ok, cool. That's something that's new to me but I'll look into it in the near future.
Bobflip is offline   Reply With Quote
Reply

Thread Tools
Display Modes

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off

Forum Jump


All times are GMT -7. The time now is 06:51 AM.


Powered by vBulletin® Version 3.8.11
Copyright ©2000 - 2024, vBulletin Solutions Inc.