Vector assets and multi-scale bitmaps for the GUI, leading to zoom. about surge HOT 97 CLOSED

FYI: I started working on a Bitwig themed skin for surge. Sadly its layout is crippled to be compatible with the current unscalable images.

from surge.

okay, then Ill just modify the assets I made to work with the "classic" color scheme. Happily, its quite easy (at least where I haven't forgotten to create symbols...)

from surge.

Whatever the final solution may be, vectorization of all the elements is the way to go. I could maybe help you vectorize the remaining elements. Would it be possible to export the finished vector elements to SVG?My weapon of choice is Inkscape that can't open Affinity files.

you're in luck, just did that! Ill update my repo (surge_reskin) within the next few minutes, watch out!

from surge.

@cyanit personally, i would prefer for surge to look like surge (classic surge skin) first, and be zoomable+rescalable.. this is what a lot of people are asking for on the forums. this establishes a template of "these are the files that you want to switch around", and maybe even some documentation.

after classic skin + template + documentation exists, then anyone can go hog-wild with the colouring and stuff. but still keeping it SVG/vector.

from surge.

@cyanit I was opting for the OG GUI because it would establish all of the things @esaruoho mentions. We get the synth up and working which will lay the foundation for going hog wild on 3rd party skins.

So in essence, I think what we're discussing is just a way to get all of this stuff working and looking "on brand" for now which is an incremental step to getting to your ultimate goal of an updated modern GUI.

Your file does look good WRT all of the dimensions as compared to the resources directory. I can knock off the remaining list of files you posted above if you want to recolor your file.

I agree with @baconpaul. In my experience with skinning apps, colors are defo low hanging fruit. The PITA comes when trying to change dimensions ,sizes, etc as he has alluded too.

I havent looked at the drawing code yet but given the resources folder I'm relatively certain that if you change the position of say, a slider track in one of the .png files things will get knackered really quickly. The GUI will seem off by a few pixels.

Usually, this stuff is really brittle WRT dimensions, shapes, and positions unless you can manipulate the code.

from surge.

Great. It is actually quite a big C++ lift to get the multi-bitmap scaling in place (beyond the somewhat crude version I already did for the AU) so I can’t promise it will be ‘quick’. I also have a few other issues I definitely want to close before I dive in.

from surge.

Closing up others issues so naming this one more accurately and consolidating the plan which is

1: We have the current bitmap assets pixel exact re-rendered from vector at 100%, 150%, 200% and 300%.
2: These are stored in surge/resources/original/100/bmp0132.png and original/150/bmp0132.png. The “original” implies that we may have other skins in the future; the 100, 150 etc.. are the sizes
3: We also check in whatever vector asset was used to make the bitmaps, probably in an “assets” directory
4: Based on that, I work on re-doing zoom to use the multi-res assets

I’ll track the actual work for #4 in another issue when it comes time for it. This is the issue we use to coordinate asset creation and the like.

If you are wondering why we came to this conclusion, you can read the discussions in the closed issues linked above. Basically I thought SVG may be the way to go but other made very convincing cases for scaled multi-res bitmaps. And so lets do that!

I think we can close this issue when

1: We have the assets and bitmaps
2: A few of the mainline hosts/os pairs implement zoom
3: We’ve turned off and removed the “crummy zoom” I implemented in the AU last year

But each of those will have other issues and PRs associated I’m sure.

from surge.

If we are worrying about what to do with the original bitmaps, I think we can declare victory!

I'll set up some directories in a bit, do a PR, and update this issue.

Oh also, while you guys are at it, over in #182 @esaruoho notes that the "Asymetrical wave shaper" is abbreviated as "ASSYM" (two ses) rather than "ASYM" (one s) in the bitmap.

from surge.

The drawing code is tricky. I should write a small primer on what it does and put it somewhere. I had to stare at it a while to figure out exactly how things like button swaps happened. If you do wade in and get stuck feel free to just put questions on this issue and I'll do my best. But I'm also only 3 weeks ahead of you - not like I'm an expert on Surge or anything!

from surge.

Oh but it will take me 10 seconds to write a shell script to move [email protected] to a folder by scale. That’s fine. There’s a convention.

We move all the assets with a script every time we build anyway. Not a problem.

from surge.

So then what we should have is an asssets/ directory with structure that looks like “skin-name/master” and “skin-name/export”. Skin-name/export contains the bmp####.png, bmp###@1.5x.png and so on. Then the build scripts just put everything in the right place. Easy for me.

Work for you guys?

If so I’ll set up the directories so you can do a PR.

from surge.

okay, glad theres such an simple solution.

from surge.

About 95% of the labels are in the bitmaps, not drawn by the drawing code. The exceptions are patch names basically and a couple of other super tiny things, and of course pop ups when you slide LFOs.

In other projects I’ve shipped .ttf files as a resource and loaded them to render fonts stopping the “is it installed” problem but adding the “can I redistribute this font file” problem. CFont in vstgui doesn’t seem to have an obvious direct way to load that font form a streamed resource file.

The fonts used to draw patch names are Lucida Grande on Mac and Arial on windows if I remember. Look in CPatchBrowser.cpp

@jsakkine and I had a chat about internationalization and the fact that labels are baked into the graphics makes it way too hard for our immediate release goal, so I think for now lets leave them in the images. If affinity designer can include the font file then that makes the choices pretty broad I guess?

Hope that helps.

from surge.

Oh also I’m not doing hardly any programming tomorrow so won’t get a chance to try assets until probably after the weekend or maybe Sunday. If you both want to arrange the files into an assets/original/master and assets/origina/exported directory and put in a PR I would sweep it if that helps; or you could work on a branch in your own repos and PR it later too. But I still have a couple of other outstanding bugs to squash before I start looking at new bitmap and zoom in earnest.

from surge.

Oh also I’m not doing hardly any programming tomorrow so won’t get a chance to try assets until probably after the weekend or maybe Sunday. If you both want to arrange the files into an assets/original/master and assets/origina/exported directory and put in a PR I would sweep it if that helps; or you could work on a branch in your own repos and PR it later too. But I still have a couple of other outstanding bugs to squash before I start looking at new bitmap and zoom in earnest.

Sounds good. Your help is greatly appreciated. Ill mull it over but Im thinking Ill just put in a PR for this stuff once Im done for the night.

Enjoy your weekend!

from surge.

That does look great! I just merged @itsmedavep change in the kurasu/asset branch. You should grab that branch and check in any additional assets you need in the "classic-vector/master" directory.

I won't have a change to look at these today but I think you guys can get the "assets" directory staged how you want and if there's another PR let me know. Then eventually we can push assets -> master.

from surge.

I swept in the PR!

from surge.

Here's the before and after with the AU in 100% mode. These images are merged into master but off by default. I'll add bug reports and instructions on how to use them on mac at least shortly.

from surge.

Wow ya'll. Im not able to build right now but this looks very nice on my phone.

Would it make sense to start to file bugs against the new skin now? I know @esaruoho has pointed out a few things. I would like to take a turn through and scrutinize things a bit as well. I'd be happy to consolidate Esa's comments into either bugs or improvements as I give it all a once over.

This thread is super long and packed with all kinds of info. Perhaps we should endeavor to have issues opened against the skin? That's what I would normally do at this point. Its real. The work is done. We have vectors for all of the skin assets. FULL STOP.

With opening issues people can hop in and polish. I know @cyanit you said there was important stuff coming up for you IRL. So, if we start to generate bugs/improvements against this current state we can just have a list of stuff to churn through and really put the final shine on everything. You, myself, or whatever future designer can start to work on issues.

@baconpaul and everyone else. Thoughts? Im happy to turn whats here into issues if thats helpful.

from surge.

I think a somewhat scalable interface is the most important thing to tackle now.

from surge.

I absolutly agree, but cant do that. Unless anyone does it, ill just continue making (svg) assets for the old skin and exporting them.
Should someone vectorize it, Ill be more than happy to contribute the graphics.

from surge.

I understand. Sadly I can't either.

from surge.

So I got it running on macOS and have spent the last few days in the graphics code. Converting it to vector will require quite a lot of work. There's also no SVG reader inside the vstgui so if you wanted an svg vst component you'd end up having to do the work (kinda like they did over in VCVRack with nanovg) of read a subset of the svg spec and output CDrawContext code. That's not easy work

To get an idea how it works now, look at CPatchBrowser. Or look how the UI gets laid out in code. Nothing wrong with this of course. This is exactly the right way to do it when the code was written but it makes it hard to adapt to a more 2018 vector assets layout style.

   oscdisplay = new COscillatorDisplay(CRect(6, 81, 142, 180),
                                       &synth->storage.getPatch()
                                            .scene[synth->storage.getPatch().scene_active.val.i]
                                            .osc[current_osc],
                                       &synth->storage);
   frame->addView(oscdisplay);

   // 150*b - 16 = 434 (b=3)
   patchname =
       new CPatchBrowser(CRect(156, 11, 591, 11 + 28), this, tag_patchname, &synth->storage);
   ((CPatchBrowser*)patchname)->setLabel(synth->storage.getPatch().name);
   ((CPatchBrowser*)patchname)->setCategory(synth->storage.getPatch().category);
   ((CPatchBrowser*)patchname)->setIDs(synth->current_category_id, synth->patchid);
   ((CPatchBrowser*)patchname)->setAuthor(synth->storage.getPatch().author);
   frame->addView(patchname);


   CHSwitch2* mp_cat =
       new CHSwitch2(CRect(157, 41, 157 + 37, 41 + 12), this, tag_mp_category, 2, 12, 1, 2,
                     getSurgeBitmap(IDB_BUTTON_MINUSPLUS), nopoint, false);
   frame->addView(mp_cat);

SO vector UI is both hard and a pretty big rewrite because we have pages and pages of that sort of code.

But that UI is awfully small on my mac so I was debating doing some scaling with just a transform. That will make the bitmaps look like crud if I can even get it done. Which it's not at all clear I can. But having an SVG file for any of the current assets may be interesting along the way, so if you did end up with any, please add them to this issue.

from surge.

FIRST UP: I'm not a c++ dev, I never fiddled with vsts. However, I know C# basics so I could probably help to rewrite the code (at least a bit) if someone tells me the basics. I understand that this is not just a SMOP.

Okay, so if vector UI is a hard thing to do, scaling seems (to me) the only option left to get a decent UI. Xfer's serum does that by taking two resolutions of the UI elements (1x, 2x) and combining (I have absolutely no clue how else to describe it) them. This allows the users to easily skin it and to be scalable.

If you need high res bitmaps that just fit, contact me, I could just export all of them in double the size and add them to my repo. Just hope it doesn't kill Github's space limit...

I can also make a custom skin, but you would need to adjust it quite a bit.

(BTW: I'm working with affinity designer, and can get you the project files if needed. It has an interchangeable file format across affinity apps & platforms, so if you own affinity photo, you could use it too)

from surge.

@cyanit query, which github size limit? now, attaching files into comments, there is a limit (10mb .gif for instance), but, surely not in the repo.

from surge.

@cyanit query, which github size limit? now, attaching files into comments, there is a limit (10mb .gif for instance), but, surely not in the repo.

Well, I had the “brilliant“ idea of versioning and backing up all my Bitwig Studio & Affinity Designer/Photo projects, turns out after a gigabyte they ask you to reduce the size of the repo. (I tried to upload 25GB)

Ill send you the newest bitmaps asap, but there are some in a repo of mine (called surge_reskin) you could use for now. Exporting SVGs asap too.

from surge.

Super generous thank you. I think the question is where do we put the scale operation. We can do a ux transform and then the bitmaps will look like crud at large size, I think. But if that works we can vectorize bitmaps one by one in the code I think if we have a vector rendering ui element.

Is it possible for now to just take one ui element - say a slider or something - and generate an equivalent vector graphic from it? If your tool has an option like “export the simplest svg” or “flatten paths” or some such that may also help.

Also I’m not sure if I will work on this in 18 vs 19 (vs ever! This is a hobby). So no rush and so on. Top priority now I have the ui working is to test mpe with my seaboard and get a packager working so we stand a chance at a release of the au. And get my au changes merged!

Thanks

from surge.

@baconpaul do you have discord or something to talk about what files you need? Cause I can get you any vectors and png's from my project file, just say what you need specifically.

Its still WIP though, so some stuff isnt vectorized yet

EDIT: the bottom one thats frankensteined is just a little mockup for me to see if everything looks okay together.

from surge.

Sorry I don't have discord!

Lets try something super easy. This UX element

the slider knob has a few states. It has a display state; it has a modulation state; and it has an active click-drag state for both base and modulation setting. So there's 4 versions of that element.

Could you just make the 4 SVG files for that element in the two base cases and two active cases and attach them to this issue? Then, if I get to this (and like I said I might not get to this this year!) I can see if I can use that in my scalable plan.

If I can, then we have quite a lot more work to do; and if I can't then you haven't done the work to make all the vectors!

Best

from surge.

Okay, so IDK in which state they are on which position on the bitmaps, (that's why I requested the documentation) so I only have the modulated (blue) and the unmodulated (grey) state.
I could color them differently so we can see which color appears when its clicked etc.

from surge.

Ahh right. So the sliders have two uses which are the blue and gray that you have. But generally UI elements also need three other looks

1. a hover look (mouse over and not clicked)
2. an active look (mouse over and clicked)
3. A disabled look (you can’t grab it)

So if we are going to do something like vectorize the slider we need 4 images for 2 colors in the most complete state.

Also I agree documentation for surge would be great! I’ve been figuring it out from the code. Do we know if there ever was any or if it is in the repo?

from surge.

Okay, the export issue is solved, now here are the images and vectors in the correct size, please use the updated ones, I deleted my old comment!

surge_bmp00153_sliders.zip

If you give me the results of "which state is which postion/tempcolor", I can recolor them properly.

from surge.

Whatever the final solution may be, vectorization of all the elements is the way to go. I could maybe help you vectorize the remaining elements. Would it be possible to export the finished vector elements to SVG?My weapon of choice is Inkscape that can't open Affinity files.

from surge.

I'll definitely check them out.

I'm not "surge" if I have the time to do something now, though.

from surge.

Thank you! I was able to download those assets.

In #81 I have started a discussion about the practicalities of implementing zoom. Can you follow that thread also? I think keeping this one for "what SVG assets would we need if we did vectorize" is smart though.

But as I've said several times now, vectorizing and associated skinning flexibility is a lot of work. Not sure I will do it quickly (but happy to share ideas with people who want to know what I'm thinking), especially now I have a cruddy bitmap zoom working in my host of choice, again in #81.

from surge.

@baconpaul oh, btw I realized the way I used to color the SVGs is apparently only supported in affinity designer. To get vector SVGs of the sliders I would have to recolor them by hand. However, I have no time for this for a while. Currently, I have the same Icon for every type and just recolored them on a group level via a color adjustment with which is neat for a sustainable workflow (but not for non-affinity designer users).

If you need them for #81 then I can make (correctly colored) scalable assets within a week or so.

from surge.

Hi

So just a quick update before on this. I have a version in my fork which can read and draw SVGs somewhat well, and so when you zoom up to 5x looks smooth still on the element I tested.

What I need, though, is vector versions of the elements.

I now understand how the UI works better, and all the elements that have "all 3 states" in them are needed in basically exactly that layout. The app pans around the document based on state.

And @cyanit yeah the SVGs in your repo have some tricky features in them. I sort of can only handle pretty basic -flat-ouf-of-inkscape-with-text-flattened-to-path plain svgs. And even then still have some bugs.

But: If someone wanted to take a couple of the BMPs and generate spacing-identical simple SVGs I could use those to test. Maybe some good ones are bmp 113, 114, 144, 125, 126? Something like that. You know easy enough ones to make. I'm pretty useless with inkscape and graphics programs in general so tricky for me to replicate those assets.

But most importantly we need parsimonious SVGs without font references and with text turned into path if my trick is going to work I think.

Oh and if this works, the way I've implemented it would allow for skins too, as long as the skins didn't move any assets. Moving or respecting assets will require C++ changes still.

If you can and want to check this out, baconpaul/surge branch svg-drawing-91 has all the code and has the hacked around version of @cyanit 's bmp 114 I used for testing. The code isn't perfect as you'll see. And i've only run it AU Mac. May not even compile on other hosts right now. Not mergeable. etc.

from surge.

@baconpaul ill look into inkscape and how to optimize my svgs. Also, I can get you the 400% png's for #81

from surge.

@cyanit over on #81 @kurasu makes a very compelling case for using multi scale bitmaps. He also checked in some assets on a branch of the original affinity file I think and somenzoomed backgrounds

I’m not going to look at this til January but I think I will give multi bitmap a try before continuing my svg work.

Which in short means: thank you! But you may want to hold off on Inkscape since the code may end up looking for each bitmap at a couple of zoom levels. Don’t want to you chase a dead end.

If I do get that code working I will do it so skins have names so your different look and feel could work well though.

from surge.

@cyanit

It seems you have deviated a bit from the shipped GUI in your Affinity Designer file. My intention was to simply replicate the resources folder .png's 1:1 in vector and provide the scaled .pngs per the conversation @ #91

Since you have done so much work in this area already would you like to do that instead of me? You have done a fair bit of work and I don't want to step on toes.

from surge.

Also @kurasu checked in some assets on a branch: https://github.com/kurasu/surge/tree/assets/assets

Some time in the next week or so I will collapse all these zoom/vector/svg/etc... issues into one referring to these also. We seem to have these a bit disorganized - and that's my fault!

from surge.

@cyanit

It seems you have deviated a bit from the shipped GUI in your Affinity Designer file. My intention was to simply replicate the resources folder .png's 1:1 in vector and provide the scaled .pngs per the conversation @ #91

Since you have done so much work in this area already would you like to do that instead of me? You have done a fair bit of work already and I don't want to step on toes.

Ohhh, okay. So I thought it would be better if someone made a new "2018" style UI. I just started to do it out of fun and the possibility to have an appealing UI myself. It would need some code adjustments to implement mine correctly.
So if the goal is to just get it working, recreating the old one is the way to go (in my humble opinion!). However, personally, I would suggest to redo it. It takes time and effort, but everyone loves it when the tools they use sound AND look good, so sooner or later someone will ask for a new UI.

Heres an idea: I recolor what I've already done (my blue/white/black scheme to the "old" orange/blue/grey one) for a temporary working version, you recreate the missing parts as SVG. This way we should have a scalable version very soon (that also looks decent).

These are the ones that are missing (because of my lack of skill and time -_- ):
bmp00 112 (Filter Config)
bmp00 137 (FX Routing)
bmp00 151 (FM Routing)
bmp00 108 (Filter Type)
bmp00 145 (Envelope Stuff)

from surge.

I think colors and stuff are easy to change; but shapes and sizes are hard. I think for the first vector release going for everything in the same place but maybe looks a bit tighter is as ambitious as we should be.

But I'm not a designer!

from surge.

I think colors and stuff are easy to change; but shapes and sizes are hard. I think for the first vector release going for everything in the same place but maybe looks a bit tighter is as ambitious as we should be.

The shapes and sizes are correct in all my files. Haven't it tested though, cause stupid me can't get compiling to work in VS 2017. In my opinion, it looks "tighter" but that's personal preference, I don't know about you guys. (Its my first "public" design project, only have done it for a few months and have no clue if its up to the standard of this project...)

Id be happy if someone of the core contributers (like paul, kzantow, esaruoho and claes) would state an opinion about what path to choose, cause after all you guys are doing most of the work shaping this synth.

from surge.

@itsmedavep yes the drawing code I have read. Every element has to be pixel where they are in the current bitmaps for it to work. The way a background of a slider changes color is to pan within the multi-background png. So we just need those bitmaps scaled up and smoothed

I could do it with a script and image magick tbh then just let designers fix the resulting aliases and stuff but if we have the original vectors it seems a render path is so much easier.

from surge.

@baconpaul

Agreed. We'll get the vectors sorted from the jump.

I'll have to come back to this stuff later but, I have fair bit of the filter type file knocked out already.

from surge.

@cyanit

I've knocked out the bmp00108.png as an individual vector asset now. I will be moving on to bmp00112.png to vectorize next.

I can churn through each file you listed as individual affinity designer files. Then we could just copy and paste those into a master file and then check that in along with the loose scaled .png's.

Does that work for you?

@baconpaul @esaruoho @kurasu

Does anyone have any other suggestions?

from surge.

@itsmedavep

copy and paste those into a master file

I have one with export set up correctly, symbols for most stuff (currently checking every asset to be a symbol), etc. If i sorted that out, I can duplicate it, recolor the symbols and make the classic skin from it.

I just worked till late night and can import the assets into the “master file“ in a few hours if you send them. Or make a pull request on my surge-reskin repo.

from surge.

@itsmedavep can you attach the vector assets that you do?
or do you guys have some way of collaborating with this so the files are present or linked on github somehow?

from surge.

@cyanit looks like https://github.com/cyanit/Surge-reskin is still talking about reskinning as opposed to doing the surge classic look?

from surge.

@esaruoho
Yes, but its easier to modify this (recoloring, adjusting the font, maybe modify the sliders etc) than starting complete over again since there are a lot of repetitive assets in there. But luckily you can make symbols (they are like variables just for graphic assets). If you then edit one, you edit the style of all existing copies of a symbol. -> easy transformation of the look.

from surge.

So I'm not sure what workflow is best for you guys. Like I said, I'm a coder not a designer. But it seems to me that what we really want is to make an "assets" directory which contains each of your master files. I have no opinion on one-by-one vs master-file. But if you do one-by-one I would be happy to merge the pull requests and could set up an empty directory structure in master now which you could start populating and PRing into. Just let me know.

from surge.

Honestly, I think I start to like it. Maybe a few tweaks here and there, but if feel like this can be a really solid skin.

from surge.

first batch of stuff is kinda done.
https://drive.google.com/open?id=1QIjYwmEnIWbu9QFzDfWQrO_7ysfBhZTY

Im sorry, but I cant sort it right now.

from surge.

I also like that a lot; as I'd mentioned on the other issue about 136 tho, at small size the contrast is a bit low on those buttons. I'm not a designer, but as a user, it was rather tricky to tell text from background on things like "send + master"

from surge.

So I'm not sure what workflow is best for you guys. Like I said, I'm a coder not a designer. But it seems to me that what we really want is to make an "assets" directory which contains each of your master files. I have no opinion on one-by-one vs master-file. But if you do one-by-one I would be happy to merge the pull requests and could set up an empty directory structure in master now which you could start populating and PRing into. Just let me know.

Good morning! Just getting up and started this AM. Unless @cyanit has a strong objection please do what you are suggesting here. This is likely the cleanest way to do this moving forward and the way I have typically done this in the past. Create assets directory. Have master file. Have directory for @ whatever sizes. Build and include only @ whatever sizes directory. Etc.

That way we can just start populating the directory with stuff. Ill continue to work on these files as individual files and add them and submit pr's. Then if Leo is agreeable he could sync then merge my documents into his master.

The master should be the source of truth!!!!!

Then after everything is all in one file with all correct states etc. we can either leave the loose files around in a deprecated dir or remove them. Do nothing with them? IDK what the desired IA is here ultimately.

from surge.

Honestly, I think I start to like it. Maybe a few tweaks here and there, but if feel like this can be a really solid skin.

Nice!

I do also agree with @baconpaul 's comments about the contrast levels on those buttons. (It's the old squint test. Squint and zoom. rinse repeat.)

The potential usability issue from my perspective being:

Button background is very low contrast from surroundings. (I don't remember if it was that way in the synth or not)

Since that is the case, your eye has labels and button strokes to identify hit targets. That means the largest part of the hit target isn't standing out really strongly against it's surroundings.

Depending upon zoom level and stroke size used in the source those strokes may or may not be thick enough to help see the borders for the buttons. That may well be true for both people with and without good eyesight.

Oh boy. Sorry. Im trying to be helpful and I just realized I might be coming off as a know it all or jerky.

Everyone tell me to be quiet if I sound preachy. Not my intention.

This is really looking good. I also agree with you Leo. This is really starting to shape up nicely. A couple little tweaks here and there this "old NEW" take on the UI will be awesome.

from surge.

Designers: I have a PR with a tentative directory structure here

https://github.com/kurasu/surge/pull/207

I also merge in @kurasu original assets he checked in on a branch.

Let me know if that looks like something you can work with?

from surge.

@itsmedavep you don't sound jerky to me!

The current UI has a higher contrast between button backgrounds and element backgrounds on these switch buttons. While I think these subtle grays look great at big zooms I agree we probably need a tighter contrast at lower zooms. When I drop the bitmaps into the UI they look sharper but also less easy to read with the current revs.

But other than that, I think these look great!

from surge.

Designers: I have a PR with a tentative directory structure here

#207

I also merge in @kurasu original assets he checked in on a branch.

Let me know if that looks like something you can work with?

I like what you did there! If @cyanit can roll that way, I believe we are good.

from surge.

@itsmedavep you don't sound jerky to me!

The current UI has a higher contrast between button backgrounds and element backgrounds on these switch buttons. While I think these subtle grays look great at big zooms I agree we probably need a tighter contrast at lower zooms. When I drop the bitmaps into the UI they look sharper but also less easy to read with the current revs.

But other than that, I think these look great!

Thanks for the screen grab. I gotta get the project building for this Mac over the weekend. Some of this UI stuff is a whole lot easier to understand once I can see a GUI!

Im over here just copying what I see in these files for now. lol. I'll fix that up this weekend. I want to wade into the drawing code for AU and take a look as some things as well.

from surge.

@cyanit

Thinking about the organization of these design files:

What would you like to see WRT layer naming and organization?

I want to facilitate an easy incorporation into master for you. Thus far, because Paul only really needs the scaled versions at this point I havent been organizing these files much.

From experience, that one sux when you come along later and work on another Designer's file. Im not trying to be "that guy" over here.

I've done things recently like attempting to organize my design files like BEM. I tend to think that way about this stuff now (for better or worse).

Im happy to conform to what makes sense for you. If Im not mistaken your master file had done some of this organization already. Should I look at that for guidance on how to organize my stuff

from surge.

The drawing code is tricky. I should write a small primer on what it does and put it somewhere. I had to stare at it a while to figure out exactly how things like button swaps happened. If you do wade in and get stuck feel free to just put questions on this issue and I'll do my best. But I'm also only 3 weeks ahead of you - not like I'm an expert on Surge or anything!

Is that native Mac code or the VST C++ part? Either way they both kinda hurt a bit. Unfortunately, if the predominance of the drawing stuff is C++I probably cant be of use much. Objective-C and Swift all good. Even a bit of C# (but thats rusty).

Button swaps with sprite sheets? IDX_Blah....

Normal is the first stacked control at the top of sprite sheet, then maybe hover is the second one, pressed next, etc.

Code walks the sprite sheet and because the size of controls are explicitly defined (somewhere), the drawing code just swaps bitmaps based on state pulling IDX from a list? Something like that?

Regardless, I gotta drop off for a bit this AM. Ill be back later.

from surge.

It’s all vstgui c++ which is not super well documented - but which has the source code there so you can read headers to figure stuff out. Feels a lot like the c++ portability ui frameworks of the first part of the decade. Think wx.

And yeah except there is no hover. So it’s like “you map an lfo to an element and it knows to add an offset of +1 vertical because that’s what mapped things do and this one is already +2 horizontal because it is zero based with ticks” but there’s not a lot of comments explaining that and pixels and logical dimensions are close to each other in the code base.

It’s not that it’s bad - I mean the code works super well - but it’s not exactly reader friendly at first glance.

from surge.

If we are worrying about what to do with the original bitmaps, I think we can declare victory!

I'll set up some directories in a bit, do a PR, and update this issue.

Oh also, while you guys are at it, over in #182 @esaruoho notes that the "Asymetrical wave shaper" is abbreviated as "ASSYM" (two ses) rather than "ASYM" (one s) in the bitmap.

Im not sure if this exists in the stuff Im working on but ill take a look and update accordingly. If I do Ill also chime in on @esaruoho stuff.

from surge.

It’s all vstgui c++ which is not super well documented - but which has the source code there so you can read headers to figure stuff out. Feels a lot like the c++ portability ui frameworks of the first part of the decade. Think wx.

And yeah except there is no hover. So it’s like “you map an lfo to an element and it knows to add an offset of +1 vertical because that’s what mapped things do and this one is already +2 horizontal because it is zero based with ticks” but there’s not a lot of comments explaining that and pixels and logical dimensions are close to each other in the code base.

It’s not that it’s bad - I mean the code works super well - but it’s not exactly reader friendly at first glance.

Yup. Ive been there. And don't get me wrong. I don't purport myself to be a developer. I have no formal education in it. It's a hobby and sometimes a necessity.

Ill dig in though and perhaps at least minimally attempt to help document what is happening there.

from surge.

The visual part
Okay, so again I'm not a professional, so I'm really happy about the honest feedback. Will work on the contrast. I'll get you the project files asap, but I'm working on an important project where I'm getting really afraid cause the deadline is in a week. This is what I procrastinate with cause it's so fun to do. ^^

Organization
@itsmedavep Pew, this is a hard one. I have to confess, I have no real consistant layer organization scheme (right now). Anyway, BEM reads like its a good thing, but isnt it slightly overkill? I mean it was designed for HTML/CSS and its structure.
Currently im migrating to creating (reusable) symbols, but they can't be easily reused/modyfied like a class. Also, I found no way to tell Affinity Designer to export different sizes to different directories, so I have to manually sort them, which sucks.

If would be so kind, I'd be happy to talk with you about this via discord or something (cant find any contact detail on your side via google), shoot me a dm via twitter/soundcloud and ill get you my discord name. Imo its the quickest to work out via voice in a few minutes than via texting back n forth.

from surge.

@cyanit - what does affinity designer naturally export? I set up directories since I figured it would be easy but I'm just as happy for you to have an export directory with bmp-scale100-00132.png or whatever and then I can move them around with a little shell script at the right time. Lets adapt the workflow to what the computer does, not adapt our manual tasks to what the computer doesn't do!

Since the directories are a pain I'll withdraw that PR on them for now. If you two can connect on whatever medium you want and let me know the sort of thing that works easily with your toolset, I'll just do that.

And good luck with your deadline project!

from surge.

@cyanit - what does affinity designer naturally export? I set up directories since I figured it would be easy but I'm just as happy for you to have an export directory with bmp-scale100-00132.png or whatever and then I can move them around with a little shell script at the right time. Lets adapt the workflow to what the computer does, not adapt our manual tasks to what the computer doesn't do!

Since the directories are a pain I'll withdraw that PR on them for now. If you two can connect on whatever medium you want and let me know the sort of thing that works easily with your toolset, I'll just do that.

And good luck with your deadline project!

I think im bad at explaining it, heres a picture. Im shure youll understand it:

This is how you configure your export "slices". A slice can be created for anything, an idividual layer, group ortboard or the whole document.

It automatically gives the files appropriate name suffixes or prefixes (which are configurable). Then you select a destination where itll dump all files. The output looks like this:

AFAIK its not possible to organize the output in folders by sizy, only a folder per slice would be possible (which imo is a horrible idea).

from surge.

Only problem is: To use these, you would need to rename them. Every. damn. time.

from surge.

Its already pretty late, but feel like I'm (pretty much) done. Was a big chunk of work (at least for me ^^ ). Here are the changes:

Contrast
Regarding the contrast/eyesight problem:
I have really bad eyesight. Easy testing, taking my glasses off. ^^ Dunno why I haven't done this earlier.
Heres what I did so far:

• Decrease brightness of BG text (now L: 20 [HSL] respectively 52/52/52 [RGB])
• Choosing a uniform, good readable font (Lato, Medium) (Also, I realized that I might have missed some places. Let me know if you spot ROBOTO text anywhere!)
• Increasing its thickness (Type: Bold) where I had trouble ("Keytrack", "Filter EG", "LFO EG")
• switching to a dark BG for the bitmap 123 (as seen in screenshots above)
• slightly adjusted background brightness for a higher contrast

Style
I think I derived a bit from the original, but In my opinion, it looks decent. If you have any feedback and suggestions, please let me know. I think its quite flat, so I have a few shadows here and there.
The filters and the mixer route switch are colored accordingly for easier user experience.

Pixel Graphics

• All slices exported at 1x, 1.5x, 2x, 3x
• if one is looking horrible, let me know (either it isn't vectorized yet or I just missed the export setting). In case of the filter stuff, sorry. Could get that done, also AFAIK dave is working on them.

Vector Graphics
All slices (not individual assets!) that I vectorized already are available as vector graphics. If you miss one, its not done yet. Some stuff like the sliders where made with affinity only tools for a speedy workflow and easier changes. Sorry. You can have a Nx export if you want higher res sliders.

Organization
Well, I realized that I fucked this one up halfway though. But that's something else. It should be working now, this is my personal priority.
So, if the filter models/switches are ready, I'm gonna make a pull req with the graphics and SVGs. Since I don't have unlimited time, I didn't go through the assets and exported them.

EDIT: realized if forgot to post the link... Here you can view/download the assets

I hope I didn't miss anything. Sorry for the long post.
Have a nice one!

Heres a frankensteined mockup. It gives you a vague idea of what it looks like.

(One more thing: I feel deeply sorry for all the people getting emails on this one. Just checked mine, not a tidy inbox... What about a SLACK/discord/whatever group for just bouncing ideas back and forth?)

from surge.

Right on everyone! Sorry I flaked there for a bit. School is still out and I had Dad duties. Glad you came to a resolution for the directory structure. Im about to get started on this again now.

@cyanit Looks like great progress. I didn't really consider the export issues earlier.

I was entirely happy to just export everything and then hand sort it. BUT I was just using 1 file. The master would be super painful to do that with. Glad you identified that and worked out a solution with Paul.

WRT style I think your mockup is looking pretty good. Ill have to give it a better look once I get some forward progress on these graphics tonight.

Quick question:

Can we change the fonts in these source files to something other than fonts common to all systems?

Meaning, as long as all of the labels for things are cooked into the background (bad practice for localization) we're all good going with using a non system font.

If we're doing calls into the system for system font to do any labels (a much better pattern for localization concerns) then changing them in the sources will potentially look bad because somewhere in the UI there is label being drawn with a differing font.

If we are to install our own font we can use whatever we like for a font but that may or may not be easy.

I raise the issue because the bg image Claes added did have some labels cooked into the background but not all of them. I haven't looked at the source to see if the GUI is using standard labels. Leo mentioned above he changed it to Lato in his mock up. Ive been using Arial because I thought it looked the most like the ones in the bitmap graphics Im copying them from to make vectors.

We should normalize on a solution.

The TL;DR version:

It's not fun as a designer but, using Arial for UI mockups of desktop applications (not services or SaaS) is a safe choice because it's common to Mac, Windows, Linux.

The web has webfonts. PC's not so much.

It may not be wise to use a font other than ones that come installed on Mac, Windows, or Linux for GUI.

from surge.

The visual part
Okay, so again I'm not a professional, so I'm really happy about the honest feedback. Will work on the contrast. I'll get you the project files asap, but I'm working on an important project where I'm getting really afraid cause the deadline is in a week. This is what I procrastinate with cause it's so fun to do. ^^

Organization
@itsmedavep Pew, this is a hard one. I have to confess, I have no real consistant layer organization scheme (right now). Anyway, BEM reads like its a good thing, but isnt it slightly overkill? I mean it was designed for HTML/CSS and its structure.
Currently im migrating to creating (reusable) symbols, but they can't be easily reused/modyfied like a class. Also, I found no way to tell Affinity Designer to export different sizes to different directories, so I have to manually sort them, which sucks.

If would be so kind, I'd be happy to talk with you about this via discord or something (cant find any contact detail on your side via google), shoot me a dm via twitter/soundcloud and ill get you my discord name. Imo its the quickest to work out via voice in a few minutes than via texting back n forth.

BEM is just a way of considering all of the elements of your designs for our context. It can be a lot of overhead initially. If you're new to it you can be a bit of a head scratcher.

Examples are usually helpful but Ill keep it brief.

Block = Combined elements into a section of functionality. Edit box, label, button placed in close proximity to one another and combining into a form.
Element = Small individual elements. Edit box, label, or button for example.
Modifier = States of things. Button hover, pressed. Or hidden, etc.

Happy to chat. I have slack if that would work. Just would need a little advanced notice.

from surge.

About 95% of the labels are in the bitmaps, not drawn by the drawing code. The exceptions are patch names basically and a couple of other super tiny things, and of course pop ups when you slide LFOs.

In other projects I’ve shipped .ttf files as a resource and loaded them to render fonts stopping the “is it installed” problem but adding the “can I redistribute this font file” problem. CFont in vstgui doesn’t seem to have an obvious direct way to load that font form a streamed resource file.

The fonts used to draw patch names are Lucida Grande on Mac and Arial on windows if I remember. Look in CPatchBrowser.cpp

@jsakkine and I had a chat about internationalization and the fact that labels are baked into the graphics makes it way too hard for our immediate release goal, so I think for now lets leave them in the images. If affinity designer can include the font file then that makes the choices pretty broad I guess?

Hope that helps.

Whack a mole! Always fun. That all sounds good to me.

from surge.

@cyanit

Let's please decide on a font. Then let's stick to the decision *edit until everything is in the master file. Im bad at communicating tonight.

It triggers changes for me when you change them. Im kerning things to match as closely as I can the bitmap images I'm copying and switching up fonts can trigger lots of downstream work.

To illustrate the issue:
Im redoing things now to account for the different font because the letter spacing is different. Arial is spaced differently than Lato. Also, I am kerning things to get the letter spacing to be as close to the bitmap files as possible. That will need to be redone.

That is all meant as illustrative. I jumped in and rolled with Arial without even bothering to consider the implications that would have for collaboration with other designers on design files. Derp. Ive been doing this a long time. I should have asked. Sorry about that.

Can we agree to use Lato?

Welcome to working with other people on design!

from surge.

@cyanit @baconpaul

I have wrapped up creating the vectors I committed to. I also rendered the scaled .pngs.

You can check this out now because I made PR for this.

PR#213

(Leo) It's in my fork now in assets. Presumably, if you wanted to look at stuff before Paul can review the PR just download my fork and you should be good to go.

Im out for the night!

from surge.

Volume scope: when audio peaks please use bright red. Mockup seems to use.. grey?

from surge.

Volume Color
@esaruoho the volume bar is actually drawn by code, so i just needed something there as placeholder that fits remotely. Don't worry!

Filter Files
@itsmedavep awesome! Do you have the afdesign file? Its just way easier to integrate than SVG.

Fonts
Bitwig is using Lato, so I had it (partially) installed. The vector bg of claes had also lato stuff on it, so I just went with it because it looked better than Roboto. Didn't even think about platform dependency because after all its all rendered as bitmap or converted to a curve (in case of svg). Lato it is.

BEM
I tried, but as written in the original post.... Halfway through I just forgot about it. Sorry.

PR
@baconpaul Id rather wait a few days and see a working beta and be shure that everything looks good in every state than making a fast pull request. However, I can't get it to compile on my pc. So could anyone just build a quick test version? Id go through and test it...

from surge.

On building if I have the assets I can build Mac versions. Windows has a trick or two in the build pipeline to reuse the assets. But if you check in to a “classic-vector” subdir in assets on the assets branch as a pr (or if Dave does) I can look probably tomorrow and try a Mac build.

from surge.

@itsmedavep made great filter and routing assets, importing them over the pixel stuff was oddly satisfying. I think im done with the UI, checked labels and text again (should be all Lato now) and updated the about screen to be compatible with the dynamic generation of text. Also made a custom
little GNU Icon. In which folder should if dump affinity designers output?

from surge.

@cyanit @baconpaul

Sweeeet!

Please review #213 (I just updated it again to be entirely flat)

Also, Leo I have grabbed the older ones you posted for now. They are the ones being added into that PR above.

If Paul accepts the PR all you wold need to after that is:

sync assets/branch

in your fork, under assets/classic-vector/exported is where you would export all your slices. Then commit those changes to the branch. Once your done with that open a PR you are good to go.

Additionally, please get your Affinity Designer source file into a PR. That way I can review the GUI much easier (better than posting images somewhere) and we can begin to track changes and work that needs to be done.

Also, I would hate to get blocked if for some unforeseen reason you weren't able to contribute any longer.

from surge.

I swept in the PR!

Thanks again!

Also @cyanit

Thank you for all your efforts too. You certainly did the heavy lifting on this. You should feel really good!

Kudos sir!

from surge.

okay, back again. I'll update the repo now....

from surge.

looks like Assym is still there (and not Asym :) )

from surge.

OK so I have it now that with master you can try these yourself on mac. They are off by default (that is, if you do the standard build process, you get the original bitmaps). To do it, you just need to run a build/install cycle with the environment variable SURGE_USE_VECTOR_SKIN set to true.

For instance, here's two commands which build and install assets without and with the new assets.

  577  ./build-osx.sh --build-and-install
  579  SURGE_USE_VECTOR_SKIN=true ./build-osx.sh --build-and-install

from surge.

The problems are there are a couple missing:

paul:~/dev/music/surge$ (cd resources/bitmaps/; ls -1 bmp?????.png ) > /tmp/resbmp
paul:~/dev/music/surge$ (cd assets/classic-vector/exported/; ls -1 bmp?????.png ) > /tmp/newbmp
paul:~/dev/music/surge$ diff /tmp/resbmp /tmp/newbmp 
29d28
< bmp00153.png
31d29
< bmp00157.png

153 is the slider handles
157 is the vertical slider handles

That explains why there's no slider handles!!

If you want to do a PR with those assets I can add them.

Also seem the LFO Selection dialog is still in the old UI.

Very close!

from surge.

Also, and may just be me, but I still think the multi-selector button contrast drop is too much.

Take a look at the FX Bypass controls in the images above, for instance. In the old one it is a pretty bold black on near white. In the new one it is a more subtle dark gray on light gray. I think bringing that up a bit would be super useful.

Also the choice of white text for octave selection - was that on purpose?

And the underline on key track and retrigger on the oscillator is way too subtle for that control I think.

Hope you don't mind these comments. This is so cool!

from surge.

Few more:

The background image for the store dialog is incorrectly sized

Switching the envelope digital -> analog means the envelope is no longer displayed. I actually couldn't figure out how that code worked the other day in another bug but just an FYI that something is different.

I love the new about screen, but need to reposition the text, of course.

We still need the AU and VST icons on the about screen, is my understanding.

And with that, I'm really off for the evening!

from surge.

Okay, seems like I forgot to move the slider handle Artboards over to the new project and to deactivate the original vertical sliders. -_-

Personally I quite like the subtle underline, but if it doesn't resonate well with you guys, I'll change that.

So, let me fix that stuff. Good to see how it looks though, will change a few more things.

Edit: wow, these are strange issues. I wonder where I messed up the save dialog size. That must have been really early, maybe during the initial project creation of the reskin...

No clue whats up with the envelope.

from surge.

There is some mysterious drawing code on the envelop\e thing. It stymied me on another bug earlier in the week. Let’s not worry about that one until I have a better idea what’s happening.

from surge.

@cyanit hi!

here's some "this is how it feels" feedback:

i'm weirded out by the "which filter is it going into" not being pale green + dark green :)
and feels like digital/analog is not as perceivable. and the "M" red is somehow bothering / daunting. the original colour felt better.
not sure why the pitch "ramp" has the lines on the bottom (for up) instead of on the top (fitting into the lifting diagonal image)

also feels like the dark line that the original classic sliders used has been replaced with a gray-er line, which leaves the plugin feeling less crisp

the fonts are too close to the sliders, and some of the sliders are missing the "+" type "end/beginning", which feels comfortable and familiar.
there's a line missing from both sides of the Patch browser, same with Output and FX Bypass / Character
Portamento diagonal line is not "full" (instead gets cut off "in the middle" - so following with the design language of the original, this new design would only allow for 50% portamento, not 100%). there are others like that there, but here's some feedback for now.

from surge.

Filter explaination
The idea was that you can easily see in which filter the Signal is going to.

Okay, little to-do list so far

• check the save dialog size
• more subtle red (mute)
• better visible orange (solo)
• make higher contrast sliders
• maybe bring back the “+“ slider endings
• adjust the faders triangle fills
• brighten up the “off-gradient“

A code adjustment request
Please move the oscillator display slightly down. Currently, I would have to make every header small again, which isn't looking very nice.

Test Request
How does it look when you assign modulations? (Maybe a GIF/short video?)

from surge.

@itsmedavep ha! I was just thinking the same but then thought ‘that’s too issue management obsessive’. Chuckle. Seems like we both agree. So go for it.

I think the previous 10 comments here from me and @esaruoho give a list of bugs. So why not open a new issue called “classic-vector skin bugs” and transcribe em over referring to this issue. And then add another issue called “use the scalable skin” which just references this one tags me, and then we can close this massive issue. Fine with me. I’ll fill in some details on my plan to use the scalable skin later on.

from surge.

Test Request
How does it look when you assign modulations? (Maybe a GIF/short video?)

yar wish is my command, @cyanit

from surge.

Ah. Maybe we don't want to work this way, but I was thinking there should be individual bug/improvement reports. That way ANY designer can hop in and pick things off. When its put all under a single issue its a bit more difficult to manage collaboration.

@cyanit Has now created a bug/improvement list in a single issue. 🤷‍♂️ We now have to parse a bug/feature list to find an issue then inquire about the state of the items on it to take on items to fix?

Seems much less collaborative. ;-[ Or is the intent to only have a single person do this?

from surge.

Oh I don't think we want one issue for each bmp. But @cyanit suggests using GitHub projects which have a task feature. I'm fine with that.

I basically use "issue for chunk of work I plan to do which should be a branch and maybe 1-2 PRs" and then tag em.

We definitely don't have a well defined workflow. We're just sort of doing what seems reasonable / amalgams of what we've done before. Kinda fun but probably not that scalable. But I don't think we are going to scale to hundreds of developers either.

from surge.

Sounds good.

As someone new and wanting to contribute, I just want to know what I can work on. I dont want a requirement of asking what state things are in and waiting for a response in order to take on tasks. That's all really.

Ideally I'd like to grab a task and get it done. Then get a review of a PR from the relevant parties.

Im really flexible about the tooling so if @cyanit suggests using Github projects to break work out into reasonable size tasks, let's do that.

from surge.