Redundant and low-res artwork about zam-plugins

[falkTX]

the artwork is included in every plugin so that they can be completely self-contained.

generating the artwork before build is possible, but the user would need some extra things installed to be able to build the plugins (python3, numpy, pil).
while it's easy to get them on linux, the same is not true for osx and windows (but not sure how important this is for zamaudio).

in the future I hope we can do scalable plugin UIs.

[matze]

the artwork is included in every plugin so that they can be completely self-contained.

I just cannot see the use case or follow your argument: 1) there are no individual source packages for single plugins so why bothering with self-containment, 2) the plugins in the Git repo use the same shared dpf module, so the same could be true for assets and 3) the install target is missing in the plugin Makefiles, so they are not entirely self-contained anyway.

[falkTX]

I meant that the binary they produce is fully self-contained.
Duplicated images (or even code) in the source files is a different question.

[matze]

But I meant the duplication in the repository. I am not arguing against bundling the binaries with the data, that's a neat idea.

[zamaudio]

@matze firstly, thank you for investing some time in this. When I created the image assets, I did not take into account that I would be reusing a lot of the assets. This certainly could be improved. I agree that the images are causing the clone time to be increased unnecessarily. I think it might be worth using some kind of git filter-branch to remove the artwork directories completely and reducing the size of the repo, then reintroducing the images in a proper framework. This could reduce the size of the repo considerably while keeping the git history mostly intact. I could certainly use some assistance in setting this up, but I have not got a lot of time to redo all the images like you have done with the new skin. BTW I do like your new slick skin theme 👍 . Can we work together to fix this?

[zamaudio]

I don't think its a really good idea to increase the bitmap size, because it still needs to work on small screened laptops where I do my recording. Others may find this also to be the case, but I can't accommodate for everyone's 4K monitors unfortunately. It would be good to one day have scalable GUIs.

[actionless]

It would be good to one day have scalable GUIs.

@zamaudio is related code resides only in https://github.com/zamaudio/zam-plugins/blob/master/widgets/ZamWidgets.hpp ? i am thinking about taking a try on it as part of c++ learning

or you want to switch from bitmaps to having sorta cairo-based toolkit?

[zamaudio]

@actionless : see DPF. It is a submodule that handles the UI toolkit.

[falkTX]

nanosvg might be an option for scalable UIs.
See https://github.com/VCVRack/Rack for an example of an application that uses it to draw UI elements.

[Audiojunkie]

Has there been any progress with support for HiDPI scaling? I use HiDPI for everything these days and generally leave behind all apps and tools for alternatives that scale ip for my screen. It would be nice to be able to use these plugins. HiDPI is much more prevalent now at the end of 2022 than things were back in 2017 when the last comment was posted. 🙂

[falkTX]

UIs will automatically scale up to the correct size, but will look blurry due to artwork being bitmap based.
The original SVGs are in the repo, eventually those will be used instead of bitmaps.

[actionless]

should i set some env var or how it's getting desired dpi? i'm running bare window manager, so mb i am missing smth

[falkTX]

it gets them from X11 WM hints, but you can use DPF_SCALE_FACTOR env var to force one in particular, like 1.5 or 2