zam-plugins
zam-plugins copied to clipboard
zamaudio
Redundant and low-res artwork
I am in the midst of revamping the look of some of my favorite zam plugins to my liking (nothing against the original artwork but it suffered from low contrast and a cramped feeling), see for example here. Now I noticed some issues, when I saw how the artwork is actually included in the plugins:
- All source and generated assets (source SVGs, fonts, exported PNGs and static C arrays) are included for each and every plugin. This means that if a knob changes in one place, it has to be changed everywhere else.
- Generated assets are included in the repository which is not necessary and needlessly increases the repo size and clone times.
- The artwork is very small in size which makes it a bit hard to read and use when manipulating the small knobs. This is particularly bad on my 4K monitor.
So my question is, are there plans to
- centralize/refactor the asset management,
- generate PNGs and static arrays at build time and
- increase the bitmap output size?
If you want, I could help you out with one or more of these points.
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.
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.
I meant that the binary they produce is fully self-contained. Duplicated images (or even code) in the source files is a different question.
But I meant the duplication in the repository. I am not arguing against bundling the binaries with the data, that's a neat idea.
@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 :+1: . Can we work together to fix this?
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.
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?
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.
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. 🙂
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.
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
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