I noticed that many beta plugins have no interfaces yet. Graphic backdrop nor control controls.
I wonder if there are people out there who need help creating artwork.
I’d like to give it a go now and then. I’m not too bad at design and as part of learning something new, I’d like to design some pedals/plugins backdrop/controls some day.
No experience in creating interfaces specifically yet though.
So, if any plugin developer or tinkerer is reading this and thinks: “I’m more proficient at making plugins than the artwork”, let me know and we might end up creating some package for your product?
You hit the point exactly. I always have a hard time doing the artwork, while I’ve a lot of fun doing the plugin engine.
Currently, there are two plugs which needs a better artwork. The one is the Rumor:
and the other been the Recorders.
any help improving the Artwork of them will be more then welcome.
Ah cool, I’ll get in touch soon, let’s see how I could give it a shot.
I’m going to see what I can figure out for myself first before bombarding you with a bunch of questions on default sizes, if there are templates commonly used by plugin makers, how art and interface are combined etc
This is a really cool idea! Thanks for that @LievenDV!
Also thank you @brummer to start immediately moving this on! Your plugins are so great that is a pity if they get lost by a lack of UI or something related to UI.
I would say as well that we have quite a few in beta right now that I believe the only lack they have is the UI. I’m saying this because I use them quite a lot! And we do have incredible plugins on that stage. For example, the OBXD is a great synth, but lacks UI.
Maybe we could put together a list of plugins on a similar stage and share it with you guys, so if some community members feel like doing some UI experiments they are very welcome. What do you guys think about this? I also ping here @James, @jesse and @Andre
There are a few things to note here. There is a way things are currently done which is using our template bitmaps and sprites which can be found on the github under the mod SDK section. Alternatively people can design their own backgrounds and sprites like @Andre does for plugins like Looperlative for example
I personally believe that we need to make some changes with how the plugin GUI’s are designed and handled. I’ll list a few changes that we are considering.
@falkTX prefers GUIs that are vector graphics rather than bitmaps (SVG rather than JPEG or PNG). This means that the art is basically just mathematical instructions rather than pixels so the art will always render at the display’s resolution no matter how big it is on screen. So when you zoom in it doesn’t look pixelated and it doesn’t need to be a really high resolution image that takes a long time load. I tend to agree however I think it’s unlikely that everyone will make vector graphics so we have to allow for both in a way that we can control the scale on the pedalboard
We need to make a separation between bitmap resolutions and scale on the pedalboard. I believe some of the GUI’s are too low resolution and would like to make some new templates that are a bit higher resolution so we can make them look a bit cleaner and more modern. The problem with this is that currently, if you have a boss pedal that is 200x400 pixels and you make another one that is 400x800 pixels to make it look nicer, the second one will be twice the size on the pedalboard meaning you would have one giant pedal that looks out of place. We need to make a change to the GUI to make scale independent of resolution FOR BITMAPS. Because in some cases you want to use a bitmap if you have say, a realistic 3D render of a pedal that can’t really be made to look realistic with vector graphics.
We need to establish a style guide. Currently there is a lot of size variation in plugins and you end up with a weird set of skewmorphic graphics that contradict each other and look weird. Boss style pedals being bigger than speaker cabinets for example. Now on the other end, we do NOT want everything to be scaled correctly as is in the real world (speaker cab 100x the size of a boss pedal) but, we do want something that kind of makes sense. Like a cab should be bigger than a pedal, just not by that much because you want to make routing easy and controls all available at a similar zoom level.
Design Guide
For this, I would like to develop a design guide, that would basically have a limited set of sizes for plugins to choose from the we can make the sizes of plugins more consistent. I would also propse a limited set of control sizes, like 3 sizes of knobs for example, as well as suggested distance between knobs. This would make plugins more consistent across the board. I think we could shoot for something “Semi Skewmorphic” where everything kinda looks like it does in the real world but is adjusted a bit so that it has a priority for ease of use in the GUI environment
So moving forward, I really need to work more with @falkTX and @Andre to establish what is possible with scaling. Then we need to start drafting up the style guide
I would appreciate comments from forum users and would encourage that if you want to work on art now, you can use the existing workflow but I would like it if we can soon change to a new workflow that we can get forum users onto to help create new art that way
One thing I’m stuck on now, since we should support both vectors and bitmaps, and we should allow different resolution bitmaps to be scaled to the same size, I don’t know if the dimensions specified in the design guide should be points (pt), pixels (px) or something else
Very interesting, @James is addressing exactly the stuff I was wondering about.
Establishing the right environment of technology and style guide should come together in a “design system”. I think you guys are in a more of mature enough stadium to consider that.
It takes the investment to get such a thing up and running and adoption might take a while but you reap benefits in the long run. A consistent style with a scaleable model (litteraly and figuratively in your case :)).
It is the necessary layer to be working together with external developers and third parties.
It might feel “limiting” in a way but it actually enables a broader tier and it keeps your environments looking slick as well. You might even end up offering a fixed set of case shapes and styles and ways to organise the control layouts but have have a library that offers more than enough choice and enough parameters to fiddle with.
I’m hesitant to commit work before this iesign system s established, as ifforts might be in vain
.That doesn’t mean I can’t be of any help when this is established.
if, for the time being, a simple sprite of a certain size could be an improvement, I could always give it a shot.
I think, if you use a vector graphics to design (like inkscape), your results will always be usable. The SVG file just needs to be exported again png or whatever graphics format MOD UI employs. Great idea to support the project, btw!
SVG offers more benefits then just scaling as well.
It opens up color customization with just one source file, so you could have the same design in many different color ways. This allows easy visual differentiation while still being aesthetically consistent. It could even be user selectable, or easily mapped to LED color if you wanted it to be. It’s just a color hex value.
I don’t know the professional reasoning behind a decision like this, but vector programs like inkscape can work with either.
I also think the investment is worth it to make it scaleable. I think having a new set of templates to go with the design guide would be great too!
As far as I know, we can already use svgs so you could directly use those files from inkscape. I think the audio file gui is an svg.
That’s a good point! We can also achieve something similar with transparent or adjustment layers with bitmaps. I generally like svg for things that don’t need to look like a real object. I believe it’s also possible to have bitmaps embedded into svgs so you could have a realistic, 3d rendered background with vector elements on top that can be user configurable
Basically we need to decide which one makes more sense because points works for vectors and pixels works for bitmaps but the scale will be independent from the resolution so maybe we should measure in mm or something
I don’t know why, but this thread seems to be leaded into a dead end. Future, well, how nice would that be. Let’s all sit down and wait for it? Nope! The future is now, so let’s take what we have and make the best out of it. Maybe tomorrow it isn’t worse a shit, but today, we’ve fun.
That said, @LievenDV your inspiration is really needed to make my plugs come true. I mean, the recorders, how ugly they are, in opposite to there usefulness? You ask for a multitrack recorder, well, gimme the mock-up and I’ll do it. Why wait for some Design Guide which will properly takes ages before it comes up.
That said, here you’ll find the MOD artwork as it is now for the recorders:
Contact me here or there when ever you’ve a mock-up to make it a tad nicer, regardless what ever the “future design guide” comes up with.
THE FUTURE IS NOW.
I completely agree with you. Sorry if I gave the wrong impression. This is why I made links to the current assets in the mod sdk
I do think it’s worth moving on with designs for the current plugins. I only want to shed some light on possible upcoming changes. My suggestion would be to try making vector based graphics when possible and to keep all your working files so that when we do transition to a new design system, there will be less resistance in updating GUIs. So try to keep the small amount of info I’ve given in consideration when designing I guess but yes, do not wait for us!
to add my point of view to the discussion: I work with a lot of technical Design that need to be simplified for websites, animations and presentations. I’ll break most of the components down and create vector graphics of them. Then I have complete control of exporting it to the specific use case (that can go through various tools, prebuild design etc.) or handing it to someone. This process has served me well over the years - especially as scaling for various screen sizes and platforms is the standard. Besides the technical aspect the design or look should be up to the developer with a guide that lays down best practices and prebuild components - like the mod sdk and most frameworks do.
Personally I like the modeling after the real world pedals and amp designs. I also like the simplified material design. It really depends on the use case: do I look for inspiration that a maybe a limited set of parameter or a pink pedal gives me. Or do I want to accomplish a specific task in the least amount of time.
I also get frustrated when the one knob I need is at the full setup interface. This is the only option I’d like to see - changing the pedal look for the full setup with a switch. I know there is more to consider than just switching views - in the end I just can build a CV Control / TouchOSC interface for that by myself exactly how I like it.
On a grander scheme there will always be good points for the one or the other option. Most of us are aware that the people at the forum are more tech savvy (or even work in that field) and have a high expectations/suggestions how things should work or have established workflows. This goes for users and the developers. I don’t know the ratio of forum users and real world user that aren’t here and don’t care about all the technical stuff. So these discussions tend to be skewed a bit and I’ll always have to remind myself that this in the end needs to be considered from all points of view - even from a business side.
I agree that the look can be totally up to the developer and that we should provide a complete framework of assets and templates to make things easier and more consistent but it’s okay if people don’t use the template.
One thing I will say though is that I think we should establish a minimum and maximum GUI scale (size on the board) that are not so far apart while still allowing basic things like the tiny gain to be next to the TAL noise maker and be usable without having to zoom in and out much. Some of the amps are bordering on being too big in my opinion. Once we are able to scale them independant of the resolution, I would scale down the biggest plugins and push to update their GUIs so that the controls (Distance between knobs etc) are similar to how they were before being downscaled. This might mean that you have an amp head that is not as wide as it would be in the real world and the knobs can be arranged in 2 rows instead of 1 to compensate for the reduction in width
There is a pdf of vector art knobs and guitar pedal bits floating around on the net, its about 6 pages and pretty handy . Im away at present so when I get home will post it.
Might be nice to have something similar for the mod.
Developers could even have mini competitions ie brummers pedal he sets the size gives it a name and let the deviants have a go at defacing it ; )
Should be back from.St Lucia tomorrow (sorry couldnt resist as its snowing in Bournemouth apparently) and will post more constructively.
Found it
https://www.dropbox.com/s/ny1xfq5av13ij2b/pedal_vectorpack.pdf?dl=0
Yes , sorry I meant you should do something similar to standardize the look layouts and make things quicker and easier for the developers. You could start by adding the stuff you already have. That way when new stuff comes out it has a MOD feel to it.
You could standardize pedal sizes and amps etc. ie 3 knob 1 switch virtual hammond 1590B 5 knobs and 2 switches a virtual 1590BB etc.
All amps same size with a virtual cloth to signify what type of amp .
Just thoughts but always happy to help with the project
