Vember Audio Surge is now open-source

[crickey13]

Maybe it's just me, but I kind of dig the old-school, retro and, dare I say, vintage look of old softsynths, including Surge.

All that truly matters at the end of the day is the sound, stability and some sound engine improvements. With that being said, I wouldn't mind a new skin, especially something with more subdued colors to make it easier on my eyes during long tweaking hours.

[EvilDragon]

There's the dark skin in there already, which is much easier on the eyes.

[ENV1]

You cannot define fonts in the skin engine. Lato is used everywhere, AFAIK.

Everywhere except for the 'label text' items. (On the screenshot, compare the font used for the wavetable name with the rest of the labels. The wavetable name is Lato, the rest are the 'mystery font', (my guess is its Verdana or Tahoma or something), which means there has to be some place in the source where this font is defined separate from the rest.) So what we need to do is change the font used for the 'label text' items to use Lato as well, because the font thats currently used for them really sucks and is not really a usable option in my view.

BTW, if some of the parameter class dumps seem defective, it is probably more accurate to say that the functionality hasn't been implemented for them.

No, thats not it.

For example tag_osc_select is reported back like this:

Code: Select all

<control tag_value="2" tag_name="tag_osc_select" x="68" y="69" w="75" h="13" class="CHSwitch2"  bg_resource="SVG/bmp00000.svg"  bg_id="0"  subpixmaps="3" rows="1" columns="3"/>

Obviously thats a bum readout since there is no resource bmp00000.svg / bg_id="0"

IIRC this was also one of the items that didnt react to anything set in skin.xml, and ive seen at least 2 others like that while trying out stuff, i.e. also saying bmp00000.svg / bg_id="0"

Also I just checked the parameter dump, all the parameters seem to be there. Which ones are missing?)

EDIT: Yeah osc.osctype is missing in the dump, dunno why. Maybe because its class isn't being scanned (it's COscMenu).

osc.osctype is missing, osc.wave is missing, osc.topline is missing, osc.midline is missing, osc.wavename.foreground is missing, osc.wavename.background is missing, you get the picture. There are many that arent dumped into runtime.xml, thats why so much remains unclear.

EDIT #2: Got the answer from Paul. Snapshot menus (like COscMenu) are not in the components dump because they're not yet supported by the skin engine - which also means you cannot move osc.osctype anywhere, and would have to design around it. We need more C++ devs.

Well, this certainly sucks. Makes me wonder how many more there are like this, because id hate to have everything 99% done and then run into another item that cant be put in the right spot and thus stick out like a sore thumb.

(BTW, moving osc.osctype to a different coordinate is no problem, it works fine as long as a 'valid' class is defined. For example:

Code: Select all

<control ui_identifier="osc.osctype" x="154" y="200" w="41" h="18" class="CSwitchControl" bg_resource="SVG/bmp00119.svg" bg_id="119"/>

This will make the item go to the defined coordinates, but it will no longer be a dropdown but merely a 2-way toggle switch.)


PS: I hate creating accounts and logins and stuff so personally i would prefer to keep the discussion going here. The fact that answers might take a little longer is fine by me.

[EvilDragon]

Currently only colors queried by the skin at runtime can be dumped. I'm now working on a system that would dump all the defined colors regardless of them being used. Obviously, you have the list now, but it's a good thing to have everything nicely reported, at least for colors. For components it's trickier.

(BTW, moving osc.osctype to a different coordinate is no problem, it works fine as long as a 'valid' class is defined. For example:

Code: Select all

<control ui_identifier="osc.osctype" x="154" y="200" w="41" h="18" class="CSwitchControl" bg_resource="SVG/bmp00119.svg" bg_id="119"/>

This will make the item go to the defined coordinates, but it will no longer be a dropdown but merely a 2-way toggle switch.)

Yeah so obviously that won't work because you're changing that control from a snapshot menu to a switch. Switches can be moved, snapshot menus can't. Yet.

[ENV1]

Currently only colors queried by the skin at runtime can be dumped. I'm now working on a system that would dump all the defined colors regardless of them being used. Obviously, you have the list now, but it's a good thing to have everything nicely reported, at least for colors. For components it's trickier.

I still dont have a complete list though, only whats in the colors dump plus what i found out myself by going through the source. So a truly complete list of colorable items would be a great help.

Yeah so obviously that won't work because you're changing that control from a snapshot menu to a switch. Switches can be moved, snapshot menus can't. Yet.

No, of course it wont, not without being able to define the right class. (Like i said, trying CSwitchControl and some of the others was just to see if anything works at all.) But like i said, im not in a hurry. I can wait until it can be properly done. Aside from that i pretty much only need the 'label text' font to be Lato and i should be able to complete a skin which mainly uses realtime font, thereby reducing text that is printed onto images (which doesnt scale nearly as well) to practically zero.

(Although we would have to talk about items like the osc type selector. In my view it would be better to have this as realtime text in the first place, so that selecting different types would simply display a different text label rather than a slice of an image. That way there would be no discrepancy between it and the rest of the text items, (Keytrack, Retrigger, etc.), and everything in that box would look nice and consistent. But thats a decision youll have to make.)

[EvilDragon]

Just checked the code, the font used on labels IS Lato. For labels, the only properties you can adjust are: text, font-size and color.

[ENV1]

Edited.

The problem was on my end.

Turns out that the Lato font was not used in the sandbox im currently working in. Surge therefore used the fallback fonts, which i think is Arial for all regular labels and something like Tahoma or Verdana for the 'label text' labels. Thus the discrepancy. With Lato actually being used by Surge, all labels now use the same font.


PS: Thanks for the info on the label options. Too bad thats all there is.

[EvilDragon]

Making a skin engine is a full-time job. So yeah there's a lot of rough edges in there atm.

[ENV1]

Can imagine, im sure its not something you do in a day or two.

As to progress, sadly i will have to cancel the project. No doubt that realtime font looks a lot better than text on images, (because it scales much better), but that Lato font just doesnt work for me, (its very similar to that fallback font i didnt like), plus there is just no way to have the labels in the right spot at all scale factors. Because:

Lets say i have a piece of text centered in a rectangle. It may look perfect at 100%, but after going to say 150% it looks as if the text is positioned 1 pixelrow too high. Same thing the other way around. I move the text 1 pixelrow down, now it looks fine at 150% but not at 100%. Etcetera. And this happens all the time. There is just no way around it except using images, which again dont scale as well. Which brings me to the other problem:

The rectangles that im using as backgrounds themselves (i.e. the images) dont stay the way they are supposed to either. Because what the scaler does at a scale factor where it cannot add a full pixelrow is faking half a pixelrow by drawing it 50% transparent. This of course creates unsightly fringes around the image (where and what images depends on the scale factor) and this sorta drives me nuts. Its exactly the kind of stuff i always avoid like the plague because unsharpness totally turns me off.

So, unfortunate as it is, this attempt was a failure. But im still very much looking forward to the bitmap based skin system because this will (hopefully) allow me to go for the look i have in mind. Just let me know when its ready and i will get right to it.

[EvilDragon]

Yeh SVG is basically being rasterized to pixels before drawing on screen, and at some zoom levels it has to approximate things. It's a tradeoff for sure, but it does allow full scalability at any zoom level, which a bunch of people actually seem to appreciate (warts and all).

That said, the font thing runs pretty deep. VSTGUI framework really doesn't like you to use external fonts, they have to be either installed on the system, or a part of resources in the DLL. There seems to be no way of loading any random font from the skin folder apparently, so we're stuck with our choice of Lato for better or for worse. We make sure it's installed on the system along with the plugin, but that's as far as it goes. Custom skins cannot easily use other fonts unless they exist on the system (and bear in mind we support Windows, macOS, Linux and ARM, and they all differ in their choice of system fonts).

Even if you go full raster, some things will still be printed out in Lato. Just the way it is with VSTGUI.

[ENV1]

What i would do in your place, scaling and other things aside, is get rid of Lato and change the font to Ubuntu-R. Its a 100% free font that can be bundled/embedded/distributed freely, you can even modify it and make derivatives if you want. (Yes, i have read the license.)

In my opinion this would be a change worth your while since (at least in my view) Ubuntu-R just looks so much better.

[Jorgeelalto]

Or maybe load the font file from the skin folder?

Edit: I'm stupid

[EvilDragon]

That's exactly what I said VSTGUI doesn't allow.

[EvilDragon]

What i would do in your place, scaling and other things aside, is get rid of Lato and change the font to Ubuntu-R. Its a 100% free font that can be bundled/embedded/distributed freely, you can even modify it and make derivatives if you want. (Yes, i have read the license.)

Actually it wouldn't work across all platforms we support because that font is under Ubuntu Font License. Which makes it not includable in Fedora and Debian repos that we support (because those two don't think that font is free - don't ask why).

Only OpenSIL or GPL3 licensed fonts are to be used. But we all love Lato, so...

[ENV1]

Oh well...some things just arent meant to be.

(Im itching to ask anyway, but...never mind.)

Still looking forward to giving the bitmap system a shot.