Haha yes I know. As mentioned, I made every product render and animation of the MOD devices and I’m well aware they are pixel based
It’s definitely a manageable way of doing it and I’ve actually been advocating for this for the last 2 years. I even mentioned it near the beginning of this thread
For me, vector art is a more broader available and simpler option. We can post Inkscape templates that people can easily edit with nice graphics and colours to quickly make new GUIs. These GUIs are also nice and responsive and they can look really nice. This should especially be used for plugins that don’t replicate a real world device. In that case vectors are preferred because a vector graphic made now can be used into the future even if people start using 16k monitors, they will still render at full resolution. With pixel graphics we will always need a higher resolution image
For the best looking GUIs though I think realistic 3D renders are the way to go and yes I know that they are bitmaps (pixel images). If it were not for the problem of resources, I would be all in on this. The file size of these bitmaps is a real disadvantage that I would like to see if we can overcome.
The best idea I have currently to tackle this problem is to convert the images to WEBP format. This is a web picture format developed by google that has much smaller file sizes than JPEGs and PNGs. I’m not sure if we can already support these file types or not @falkTX maybe you can enlighten me? I know that in the past, some browsers did not support the format (safari for example) I’m not sure if that is still the case
We often create that file-format, for us this is no problem and indeed, it is a cool one because it’s small file-size and supporting transparency. I am not sure if Blender is already supporting it, but Gimp does. I know that some guys of the Blender community at least are working on that support.
Yeah it’s also not a problem if it isn’t supported in blender since we can just convert it to a webp at any point, I’m more concerned about if the MOD GUI can support it and if the browsers people use to open the web GUI support it
We just did some tests in the office and were able to replace a plugin GUI image with a webp one on the safari browser and it displayed correctly so that’s promising (edge, chrome and firefox already had support for it). Unless @falkTX has an issue with it I would say it would make sense moving forward to make all pixel image GUI elements as webp format to reduce file size. Perhaps we can even find a way to convert all the existing PNGs to webp. This could help with the responsiveness issue people have been experiencing on mobile devices connected wirelessly
@James sh… I forgot to upload the renders of the Chickenhead knob with linear movement. I finished it some days ago already. It can be downloaded here.
@brummer
It took a bit longer because I had too much work last week. But here is my proposal for the Record mono and stereo. It must be a bit polished still…
I found a method how to save all shapes in Gimp in paths. These paths can be easily imported to InkScape for further editing. I now could easily create a vectorized version of this as well.
This looks awesome. Defiantly nice interfaces for the recorders. And if you be able to create a SVG from that, we are fulfil the needs of the new upcoming artwork guideline (at least I guess so)
Great work.
@brummer
Cool, thanks a lot for the compliment! I will try to create a vectorized, scalable graphic now. It certainly will not look as nice as the pixel graphic because lighting etc. is more artificial in vector graphics. As well no pixel graphic should be used in SVG due to scalability. Thus e.g. the housing will be not as nice as it is now. But let me try. We can decide which one to take by comparing both, the pixel and the vector graphics.
One question: You will need the red Rec-button and the red diode separatls in two stages on / off, right? Do you need something for the scale and the field for the file-format as well?
Yes, easiest would be a horizontal sprite, even if there are just two stages.
The record button looks really cool.
File-format field is based on some CSS rules, so we don’t need a image for that one, for the scale it used currently a png image which I’ve generated with cairo/C++. If it comes handy to you to create a other one, that wouldn’t hurt, but is not necessary, we could reuse the old one, or I generate a new one for the needed size.
The current used MOD UI images and definitions you’ll find here, so you could have a look on the CSS file and the javascript to see how that worked.
There is no intention to have vector graphics be a requirement in the guideline. It’s one of 2 options
If it’s going to be a pixel image it just needs to be optimised but it seems like using webp is a viable option. Actually @Kim perhaps it would be a good test if you could try making a GUI with all webp assets
@brummer The sprites for Record plugin are finished. I created:
Two background sprites for mono and stereo Record in the file-formats PNG (165 KB) and WEBP (39,4 KB)
Rec-knob in the file-formats PNG and WEBP
Red diode in the file formats PNG and WEBP
Scale im file format PNG (WEBP has been blured because of compression)
The scale has 61 stages. The size is 610 / 124 Px. The size of the scale itself is 8 / 122. There is one transparent pixel on the left, the right, the top and at the bottom of each of the 61 scales. The row of scales thus starts with one transparent pixel, then 8 Pixels of visible scale, then 2 pixel transparent, then 8 visible Pixel, then 2 visible etc. I hope everything is fine with this scale. Please let me know if correction is needed.
The suff can be downloaded here.
I think it’s great, the work you’re putting in man
I would say though in terms of the values I think a lot of people are expressing in this thread, the tape recorder design is a bit in the opposite direction. It looks cool don’t get me wrong. I think for a utility plugin like this, it has a lot of unused space and shows very little information. It’s mostly aesthetics and limited function. Also in my experience, reel to reel tape player style GUIs are usually used for Tape Saturator type plugins so it might be a bit confusing to see this for a recorder
I imagined a GUI like the ones used for the Audio File Player and the MIDI File Player for this kind of plugin. I’m not saying this to dis you in any way, I really don’t want to discourage you at all because you are doing great things here. I just want to try to steer things more towards practicality a bit
Of course it’s not my choice though, just giving my 2 cents
Great! The webp format works without issues here. I’ve started to implement it. Looks very cool.
I hear that kind of argument often in discussions about skeuomorphic GUI’s, I always wonder what you expect to do otherwise with the “wasted screen space”, blanc screen or a nice view on a background image or what?
So in a daw I don’t think it matters because each plugin has a window but on our platform the user needs to assemble multiple plugins around each other and route them all together so unused space on a plugin GUI means that more space needs to be made on the board for that plugin and means that you need to be on a further zoom level to route things which means that all of your controls and visual information is harder to read because you need to be zoomed out.
Basically I think it’s ideal for the user if they don’t need to zoom in and out so much
