Good catch. I just updated the manual! Thanks
Vember Audio Surge is now open-source
-
- KVRian
- 845 posts since 25 Dec, 2018
The font swap problem has a variety of technical issues (vstgui is way harder to make load a ttf from filesystem than juce is etc...) but there’s also the pragmatic problem that in the current skin the rendered assets (which is all the switches and buttons) are SVGs with paths that are generated from the Lato font, so switching the font around will only modify a subset of the UI (the stuff where we draw a string). If you really want to change surge font to something else you need to re-generate and re-render all the svg assets also.
-
- KVRAF
- 2802 posts since 31 Aug, 2011
Yeah, thats somewhat unfortunate. I actually meant to suggest making the SVG skin use the 'live' font for all labels since a font generally scales a lot better than a static image, but i forgot.baconpaul wrote: ↑Sun Aug 09, 2020 2:46 pm The font swap problem has a variety of technical issues (vstgui is way harder to make load a ttf from filesystem than juce is etc...) but there’s also the pragmatic problem that in the current skin the rendered assets (which is all the switches and buttons) are SVGs with paths that are generated from the Lato font, so switching the font around will only modify a subset of the UI (the stuff where we draw a string). If you really want to change surge font to something else you need to re-generate and re-render all the svg assets also.
The bitmap (PNG) skin on the other hand could theoretically use either. It could use a 'live' font for everything as long as all parameters like exact position, size, weight, etc. are definable by the skinmaker. (SynthEdit lets you do this in a great way, to name one example.) Or it could not have any font based text at all, (except of course the readouts), in which case the skinmaker prints all labels directly onto the images, which would be OK since these sets arent meant to be scaled anyway.
Heres an example of the latter. (Something i once made for Deducktion, nothing special.) All labels are printed directly onto the respective backgrounds, i.e. i had full control over sharpness, spacing, kerning, fractional widths, and so forth. The white text and the yellow text in the topbar are 'live' font. (Which i unfortunately could not change or i would have used the same that i used for the labels.)
If downscaled, rightclick and select View Image for fullsize.
You do not have the required permissions to view the files attached to this post.
-
- KVRian
- 845 posts since 25 Dec, 2018
So my first version of the skin engine that I abandoned tried to do that. Basically make a multi state button where the skin specified the labels. I could revive that code if you are serious about using it. It makes the skin a big exercise though and I rejected it as intractable since designers seemed to want more control than a simple draw label would allow.
It would let you internationalize though which would be nice.
Oh and the svg doesn’t contain strings. All the fonts are converted to paths. So it would be a rework of every asset like I said.
It would let you internationalize though which would be nice.
Oh and the svg doesn’t contain strings. All the fonts are converted to paths. So it would be a rework of every asset like I said.
-
- KVRAF
- 2802 posts since 31 Aug, 2011
Well given the choice, if you want my opinion, i would actually prefer a system where i can do everything myself, including the font for the readouts, which would then be bitmap based too.
Let me show you this example. All labels are printed directly onto the background/buttons while the dot-matrix readout fonts are hand-made, consisting of image strips which contain each individual glyph. The start/end coordinates (or dimensions or offsets) of the glyphs in the image strip are then defined via a definition section, which can either be a standalone file, (PPG wave 2V has it like that), or part of a global definition file where all UI related parameters live. (Thats how CamelSpace has it.) It would look something like this:
The advantage of this is that the UI designer has full control over every last aspect with regard to how text will look, plus it is guaranteed to look the same on any machine since its all bitmap based. (And it wont need any font files to be installed or packaged.) The only disadvantage, if you want to call it one, is that it will look perfect only as long as it isnt being scaled around, but then youve said you wanted to make the bitmap based UIs non-scalable anyway, so it wouldnt really be a problem.
So thats what i would prefer because ive achieved good results with it. (And i like to work that way.) But the ultimate decision is of course yours, after all this will all require a lot of work and i certainly wouldnt want you to go to all this trouble if youre not convinced that this is the best way to go. Ultimately i will try to work with whatever you decide is best, ive tackled a lot of 'hard cases' (Albino3 springs to mind) and unless there is something that really makes it impossible for me to proceed i usually find a way to achieve what i want.
So ultimately just tossing ideas around...
If downscaled, rightclick and select View Image for fullsize.
Let me show you this example. All labels are printed directly onto the background/buttons while the dot-matrix readout fonts are hand-made, consisting of image strips which contain each individual glyph. The start/end coordinates (or dimensions or offsets) of the glyphs in the image strip are then defined via a definition section, which can either be a standalone file, (PPG wave 2V has it like that), or part of a global definition file where all UI related parameters live. (Thats how CamelSpace has it.) It would look something like this:
Code: Select all
FONTS
FontSelector
89
!#$%&'()*+,-./0123456789;=@ABCDEFGHIJKLMNOPQRSTUVWXYZ[]^_`abcdefghijklmnopqrstuvwxyz{}~
4 3 11 11 11 11 5 5 5 11 11 5 11 5 11 11 7 11 11 11 11 11 11 11 11 5 11 11 11 11 11 11 11 11 11 11 7 11 11 11 11 11 11 11 11 11 11 11 11 11 11 11 11 11 7 7 11 11 5 11 11 11 11 11 11 11 11 7 9 9 7 11 11 11 11 11 11 11 11 11 11 11 11 11 11 7 7 11
FontDisplay
89
!#$%&'()*+,-./0123456789;=@ABCDEFGHIJKLMNOPQRSTUVWXYZ[]^_`abcdefghijklmnopqrstuvwxyz{}~
7 6 20 20 20 20 9 11 11 20 20 9 20 9 20 18 12 18 18 18 18 18 18 18 18 9 20 20 18 18 18 18 18 18 18 18 12 18 18 18 18 18 18 18 18 18 18 18 18 18 18 18 18 18 14 14 18 18 9 18 18 18 18 18 18 18 18 12 15 15 12 18 18 18 18 18 18 18 18 18 18 18 18 18 18 14 14 18
FontVersion
12
v0123456789.
7 7 6 7 7 7 7 7 7 7 7 3
So thats what i would prefer because ive achieved good results with it. (And i like to work that way.) But the ultimate decision is of course yours, after all this will all require a lot of work and i certainly wouldnt want you to go to all this trouble if youre not convinced that this is the best way to go. Ultimately i will try to work with whatever you decide is best, ive tackled a lot of 'hard cases' (Albino3 springs to mind) and unless there is something that really makes it impossible for me to proceed i usually find a way to achieve what i want.
So ultimately just tossing ideas around...
If downscaled, rightclick and select View Image for fullsize.
You do not have the required permissions to view the files attached to this post.
-
- KVRian
- 845 posts since 25 Dec, 2018
I added png support back in the skin engine last week (an initial cut) so if I just turn off the sliders being labeled you could basically do what you want but...
How would you intend to deal with (say) patch name display? Or labels which change like when you swap fx
How would you intend to deal with (say) patch name display? Or labels which change like when you swap fx
-
- KVRian
- 845 posts since 25 Dec, 2018
Oh and you can do everything yourself now of course! Just write the c++! The question I keep asking myself is how much to expose to runtime configuration vs code. And it’s all trade offs.
Right now I’m coding up an mseg lfo type and I think that’s probably more useful (and is definitely more fun to code) than micro detailed skin stuff (but if you want to sling ui c++ we would love the help!!! And you are totally welcome!!)
Interesting convo
Right now I’m coding up an mseg lfo type and I think that’s probably more useful (and is definitely more fun to code) than micro detailed skin stuff (but if you want to sling ui c++ we would love the help!!! And you are totally welcome!!)
Interesting convo
-
- KVRAF
- 2802 posts since 31 Aug, 2011
Well, before i can say anything definitive i would first have to see how it all works. So far i have only seen the skin.xml that accompanies the SVG UI, (and the embedded resources in the DLL), and i didnt understand how thats supposed to work at all since this is by no means the typical 'this image/item has such and such dimensions and goes to that coordinate' structure that i am used to and know how to work with. For instance are all items freely positionable? Can i define their dimensions? Do i have to? Can/must i specify how many frames an animated item has? That sort of thing. Once i had the opportunity to check this all out i can say what works and what doesnt and maybe make suggestions.baconpaul wrote: ↑Sun Aug 09, 2020 8:18 pm I added png support back in the skin engine last week (an initial cut) so if I just turn off the sliders being labeled you could basically do what you want but...
How would you intend to deal with (say) patch name display? Or labels which change like when you swap fx
- KVRAF
- 23103 posts since 7 Jan, 2009 from Croatia
Defining dimensions isn't yet possible for all widgets (main thing is the FX section, it has a really horrific way of positioning the sliders, it's a decent chunk of work to unscrew that and make it fully skinnable, another thing is the LFO type switch, and oscillator waveform display IIRC). Positioning elements is possible for most elements (again except FX section).
If you right-click the Menu button you can see test skins in the Skins submenu, you can also open them up and investigate. Currently the recommended scenario is to just tweak assets while retaining their current dimensions - this is how the dark skin was done. Work is underway to make some improvements for 1.7.2 when a new skin will be showcased (and it's a beauty!).
There's also skin dev guide (very much WIP) here: https://surge-synthesizer.github.io/skin-manual.html
But yeah, definitely investigate the dark skin (or even better - my own tweak of the dark skin) to get more clues.
If you right-click the Menu button you can see test skins in the Skins submenu, you can also open them up and investigate. Currently the recommended scenario is to just tweak assets while retaining their current dimensions - this is how the dark skin was done. Work is underway to make some improvements for 1.7.2 when a new skin will be showcased (and it's a beauty!).
There's also skin dev guide (very much WIP) here: https://surge-synthesizer.github.io/skin-manual.html
But yeah, definitely investigate the dark skin (or even better - my own tweak of the dark skin) to get more clues.
-
- KVRAF
- 2802 posts since 31 Aug, 2011
Well im in no hurry.
I will give it a shot as soon as you say it makes sense, i.e. when no substantial changes are to be expected anymore.
PS: These resources are for the SVG, i take it?
I will give it a shot as soon as you say it makes sense, i.e. when no substantial changes are to be expected anymore.
PS: These resources are for the SVG, i take it?
- KVRAF
- 23103 posts since 7 Jan, 2009 from Croatia
Yes it's all SVG.
-
- KVRist
- 283 posts since 17 Feb, 2014
baconpaul wrote: ↑Sun Aug 09, 2020 8:21 pm Oh and you can do everything yourself now of course! Just write the c++! The question I keep asking myself is how much to expose to runtime configuration vs code. And it’s all trade offs.
Right now I’m coding up an mseg lfo type and I think that’s probably more useful (and is definitely more fun to code) than micro detailed skin stuff (but if you want to sling ui c++ we would love the help!!! And you are totally welcome!!)
Interesting convo
Would it be possible at some stage to implement an option to interpolate between single cycles in a wavetable and the ability adjust the degree of that interpolation ?
Regarding GUI and letters, I never had any problems with it in the original Surge (1.5.2).
In my view, features and sound quality are much more important !
-
- KVRAF
- 9133 posts since 6 Oct, 2004
I got the vst3 effects rack version this morning, very nice and easy to use...would it be possible for that to popup or reside on a tab, being made a config option replacement/alternative/extra of the current effect panel?
Using recent Ubuntu Studios and Reapers, the delay part of the effect rack defaults to adding massive latency, rather than some standard string of delay taps, and I can't get it to act like a standard delay plugin at all. I might be missing the obvious, it's a skill I've developed
The chorus, phaser, rotary, and reverb make a nice E Piano
or guitar team!
Cheers
Using recent Ubuntu Studios and Reapers, the delay part of the effect rack defaults to adding massive latency, rather than some standard string of delay taps, and I can't get it to act like a standard delay plugin at all. I might be missing the obvious, it's a skill I've developed
The chorus, phaser, rotary, and reverb make a nice E Piano
or guitar team!
Cheers
- Banned
- 7624 posts since 13 Nov, 2015 from Norway
Wow that is a beautiful skin. Is it available for download?ENV1 wrote: ↑Sun Aug 09, 2020 6:48 pmYeah, thats somewhat unfortunate. I actually meant to suggest making the SVG skin use the 'live' font for all labels since a font generally scales a lot better than a static image, but i forgot.baconpaul wrote: ↑Sun Aug 09, 2020 2:46 pm The font swap problem has a variety of technical issues (vstgui is way harder to make load a ttf from filesystem than juce is etc...) but there’s also the pragmatic problem that in the current skin the rendered assets (which is all the switches and buttons) are SVGs with paths that are generated from the Lato font, so switching the font around will only modify a subset of the UI (the stuff where we draw a string). If you really want to change surge font to something else you need to re-generate and re-render all the svg assets also.
The bitmap (PNG) skin on the other hand could theoretically use either. It could use a 'live' font for everything as long as all parameters like exact position, size, weight, etc. are definable by the skinmaker. (SynthEdit lets you do this in a great way, to name one example.) Or it could not have any font based text at all, (except of course the readouts), in which case the skinmaker prints all labels directly onto the images, which would be OK since these sets arent meant to be scaled anyway.
Heres an example of the latter. (Something i once made for Deducktion, nothing special.) All labels are printed directly onto the respective backgrounds, i.e. i had full control over sharpness, spacing, kerning, fractional widths, and so forth. The white text and the yellow text in the topbar are 'live' font. (Which i unfortunately could not change or i would have used the same that i used for the labels.)
If downscaled, rightclick and select View Image for fullsize.
Producktion.png
EnergyXT3 - LMMS - FL Studio | Roland SH201 - Waldorf Rocket | SoundCloud - Bandcamp
- KVRAF
- 23103 posts since 7 Jan, 2009 from Croatia