PBR for Audio Software Interfaces (2016)(auburnsounds.com)
auburnsounds.com
PBR for Audio Software Interfaces (2016)
https://www.auburnsounds.com/blog/2016-09-16_PBR-for-Audio-Software-Interfaces.html
7 comments
Oh. I was hoping it was a metaphor, and they were actually generating sounds based on the physical properties of a 3D environment. PBR for sounds as in "rendering" a sound wave.
1. Dplug is using software rendering not OpenGL. Get your facts straight before "calling out" people on the Internet. So the OpenGL driver doesn't matter in any way. By the way, many audio plugins now use OpenGL, just not those.
2. Do you think it's normal an audio plugins would weight more than 100mb of graphics, including memory? No, that's why Dplug uses rendering (in part). It uses less memory space AND installation space and with caching it's not any slower.
3. I do not thank you for calling this idiotic on a public forum, without reading the article. What has became of politeness?
4. Photo-realistic != rendering. We are not after photo-realism. Instead natural lighting effect can help getting into a software by making logical groups and also convey value. Dplug PBR system can be bypassed to support the subset of rendering that other framework do.
5. Many other brands use OpenGL. We don't, exactly for the reasons you outline. Please amend your comment and drop the hate speech.
2. Do you think it's normal an audio plugins would weight more than 100mb of graphics, including memory? No, that's why Dplug uses rendering (in part). It uses less memory space AND installation space and with caching it's not any slower.
3. I do not thank you for calling this idiotic on a public forum, without reading the article. What has became of politeness?
4. Photo-realistic != rendering. We are not after photo-realism. Instead natural lighting effect can help getting into a software by making logical groups and also convey value. Dplug PBR system can be bypassed to support the subset of rendering that other framework do.
5. Many other brands use OpenGL. We don't, exactly for the reasons you outline. Please amend your comment and drop the hate speech.
Re 1) Mea culpa - I saw the OpenGL part in the article and didn't read it carefully.
Re 2) Do you find it normal that an audio plugin now spends more time rendering its UI using a CPU renderer than processing audio? That physically based rendering, normal maps and what not are not free lunch!
Yes, 100MB disk space is a lot, but why to have that silly skeuomorphic UI in the first place? Drop it and you won't need those 100MB of textures.
Or do you believe that the user is so dumb that they won't recognize a knob from a button unless it is shiny, knurled and properly lit?
Re 3) This is not about being polite but about calling poor engineering decision out for what it is. So I am standing behind my comment.
Re 4) " We are not after photo-realism. Instead natural lighting effect can help getting into a software by making logical groups and also convey value. "
So not after photo realism but speaking about "natural lighting effect". Isn't that a bit of a contradiction?
And what value is being conveyed exactly? That I am getting a piece of nice, heavy, solid brushed metal? I am not a musician but the ones I know are pretty much all loathing this kind of stuff because it is only consuming loads of resources for no reason and in most cases makes the tools more difficult to use. It is a sound plugin, for heaven's sake, not something to exhibit in a vitrine!
Re 5) Well, you don't use OpenGL, correct. My mistake. However, you have reinvented the wheel using software rendering instead, which isn't even hardware accelerated. Not sure what is worse.
There is also no "hate speech" to drop. Hate speech has a fairly specific definition. Criticism is not hate speech, thank you.
Re 2) Do you find it normal that an audio plugin now spends more time rendering its UI using a CPU renderer than processing audio? That physically based rendering, normal maps and what not are not free lunch!
Yes, 100MB disk space is a lot, but why to have that silly skeuomorphic UI in the first place? Drop it and you won't need those 100MB of textures.
Or do you believe that the user is so dumb that they won't recognize a knob from a button unless it is shiny, knurled and properly lit?
Re 3) This is not about being polite but about calling poor engineering decision out for what it is. So I am standing behind my comment.
Re 4) " We are not after photo-realism. Instead natural lighting effect can help getting into a software by making logical groups and also convey value. "
So not after photo realism but speaking about "natural lighting effect". Isn't that a bit of a contradiction?
And what value is being conveyed exactly? That I am getting a piece of nice, heavy, solid brushed metal? I am not a musician but the ones I know are pretty much all loathing this kind of stuff because it is only consuming loads of resources for no reason and in most cases makes the tools more difficult to use. It is a sound plugin, for heaven's sake, not something to exhibit in a vitrine!
Re 5) Well, you don't use OpenGL, correct. My mistake. However, you have reinvented the wheel using software rendering instead, which isn't even hardware accelerated. Not sure what is worse.
There is also no "hate speech" to drop. Hate speech has a fairly specific definition. Criticism is not hate speech, thank you.
I had written another long reply but I felt like it added nothing to the discussion and removed it.
I'd like to adress only the technical issue of CPU usage, in which you are a bit right and perhaps we could agree. Software rendering need to be fast too as you guessed.
The optimizations performed is that only subparts of touched elements are redrawn in intermediate buffers (widgets receive the order to redraw in subrects of their positions), mipmapping (SSE2) is used to help with glow and shadows, tiling and multithreading are used, and the output of PBR is cached. For realtime feedback like spectrograms, the system has a bypass channel in which case the lighting calculation is just a copy. This is what is used for realtime feedback at 60fps, no PBR is computed then. That still leaves big PBR widgets which can be invalidated at once.
It's still not at the level of quickness I wan't it to be (Issue #127), you may have the problem that while turning a big knob - in which caching doesn't help - Crackles may occur. I'm pretty confident it can be solved completely when #127 is fixed and lighting is more SIMD and less shader-like.
So it's an ongoing process of making this rendering faster, however the rewards in my opinion are numerous (and there we get in debatable material so I won't disgress).
I'd like to adress only the technical issue of CPU usage, in which you are a bit right and perhaps we could agree. Software rendering need to be fast too as you guessed.
The optimizations performed is that only subparts of touched elements are redrawn in intermediate buffers (widgets receive the order to redraw in subrects of their positions), mipmapping (SSE2) is used to help with glow and shadows, tiling and multithreading are used, and the output of PBR is cached. For realtime feedback like spectrograms, the system has a bypass channel in which case the lighting calculation is just a copy. This is what is used for realtime feedback at 60fps, no PBR is computed then. That still leaves big PBR widgets which can be invalidated at once.
It's still not at the level of quickness I wan't it to be (Issue #127), you may have the problem that while turning a big knob - in which caching doesn't help - Crackles may occur. I'm pretty confident it can be solved completely when #127 is fixed and lighting is more SIMD and less shader-like.
So it's an ongoing process of making this rendering faster, however the rewards in my opinion are numerous (and there we get in debatable material so I won't disgress).
[deleted]
yes! you are CORRECT sir!
and this is due to the "END USER" who is fooled by such nonsense. There are studies showing respondents registering sonic differences when shown different UI... pathetic but true...
and 100% the fault of the golden-ears golden-cable audio mythology B$ that has already ruined any pretense of objectivity in the Hi-Fi world and has basically been milking the pro-audio market, thanks to cooperative reviews and an industry that has a lot at stake if it speaks up...
and this is due to the "END USER" who is fooled by such nonsense. There are studies showing respondents registering sonic differences when shown different UI... pathetic but true...
and 100% the fault of the golden-ears golden-cable audio mythology B$ that has already ruined any pretense of objectivity in the Hi-Fi world and has basically been milking the pro-audio market, thanks to cooperative reviews and an industry that has a lot at stake if it speaks up...
Nothing prevent you from opening plugins without UI if you are wary of the halo effect.
We spend a lot of time on audio algorithm, much more than the UI. In the end plugins have to sound good whatever their UI, it's just that when you work hard on a DSP algorithm it only makes sense to present it in the best way, and not spoil your chance.
We spend a lot of time on audio algorithm, much more than the UI. In the end plugins have to sound good whatever their UI, it's just that when you work hard on a DSP algorithm it only makes sense to present it in the best way, and not spoil your chance.
Does anyone have any experience with the DPlug framework? I've used IPlug for a few plugins and have been impressed (considering the lofty goals of the project) but D looks a lot more mature and well-thought-out. I found a comparison on their Github page (https://github.com/AuburnSounds/dplug#comparison-vs-iplug) but does anyone here have an opinion?
Dplug has two commercial users, you'll find the only opinion that is not mine here: http://www.modernmetalproduction.com/dplug-developing-vst-pl...
It's designed to be easier than Iplug in practice, however there are some missing features.
BTW the reception here on HN can be entirely explained by the first negative comment...
It's designed to be easier than Iplug in practice, however there are some missing features.
BTW the reception here on HN can be entirely explained by the first negative comment...
Obligatory OT comment complaining about the site:
I think this is one of the worst performing sites I have ever visited. When the gears in the top right are visible, my whole phone (oneplus one) stutters and when I scroll down, it takes up to a second for the page to follow and render in.
I understand the need to make your site special, but if it's at the the cost of this much performance you should really overthink it.
I think this is one of the worst performing sites I have ever visited. When the gears in the top right are visible, my whole phone (oneplus one) stutters and when I scroll down, it takes up to a second for the page to follow and render in.
I understand the need to make your site special, but if it's at the the cost of this much performance you should really overthink it.
Good point, I will perhaps remove it. On my phone tests if was okay.
Oh skeuomorphic hell in DAW software...
I love this rant/gallery:
https://theoutline.com/post/2157/why-are-there-so-many-knobs...
I love this rant/gallery:
https://theoutline.com/post/2157/why-are-there-so-many-knobs...
analog metaphors to physical world objects are INTENTIONAL here!
otherwise why would you pay MONEY for software when you already bought the computer and you could instead shell-out for a glorified paperweight ermmm a dedicated processor running the same software in a fancy box! (replete with slow knob-control response, just like the plugin running on a 486 and the worst midi interface the market doesn't even sell anymore, as it was made with desktop software tools and that guy who coded the original 6502 synth that ran 500 oscillators oversampled 5 million times retired last year and he's busy doing cobol for money anyway...but I digress)
otherwise why would you pay MONEY for software when you already bought the computer and you could instead shell-out for a glorified paperweight ermmm a dedicated processor running the same software in a fancy box! (replete with slow knob-control response, just like the plugin running on a 486 and the worst midi interface the market doesn't even sell anymore, as it was made with desktop software tools and that guy who coded the original 6502 synth that ran 500 oscillators oversampled 5 million times retired last year and he's busy doing cobol for money anyway...but I digress)
The article itself is very interesting but the skeuomorphic UI looks horrible to use - especially the knobs, because there is no intuitive AND practical way to emulate twisting stuff with a mouse pointer.
Can anyone with practical experience with this tool share their opinion?
Can anyone with practical experience with this tool share their opinion?
I hate skeuomorphic UI and wish it would die. The number of users that have ever used a hardware compressor, eq, gate, analog synth etc is much smaller than the number of users that have grown up creating music completely on their PC. I think it makes more sense to focus on the second group.
The plugins I work on tend to look more like software than any piece of hardware. I still use knobs because they are more efficient use of screen real estate. When you click / drag them, left is decrease, right is increase. You don't need to drag around like a physical knob.
Here is one set of plugins I did: https://www.tracktion.com/products/daw-essentials-collection
The plugins I work on tend to look more like software than any piece of hardware. I still use knobs because they are more efficient use of screen real estate. When you click / drag them, left is decrease, right is increase. You don't need to drag around like a physical knob.
Here is one set of plugins I did: https://www.tracktion.com/products/daw-essentials-collection
Its really nice to see your work, it does indeed represent the non-skeu way of going, but .. you lost me at knob.
I mean, it is a bit of a cop-out, and you can't go "skeu is the sux" and then .. just use it.
My question to you, then, is: how would you re-do the knob? It is a uniquely viable control; but lets say you -had- to get rid of it. What, then?
I mean, it is a bit of a cop-out, and you can't go "skeu is the sux" and then .. just use it.
My question to you, then, is: how would you re-do the knob? It is a uniquely viable control; but lets say you -had- to get rid of it. What, then?
Sliders. Tracktion Waveform, the DAW I also work on uses almost no knobs. (I think the only one is pan on the mixer). The problem with them is that they are big. When we don't have room we make them small and then a bigger one pops up when you click on it.
Check out the UI of Adobe Photoshop.
They use numeric text boxes which also pop a slider when given focus.
You can also let the users drag the textbox left and right directly (with some visual cue), thus achieving the same functionality as the current implementation, but still without getting in the way of someone who just prefers to use the textbox normally.
They use numeric text boxes which also pop a slider when given focus.
You can also let the users drag the textbox left and right directly (with some visual cue), thus achieving the same functionality as the current implementation, but still without getting in the way of someone who just prefers to use the textbox normally.
No experience with this exact tool, but I use Reason which is a DAW with a Skeumorphic UI (right down to connecting components with virtual wires) and I find knob-fiddling to work just fine for me. The knobs read from my mouse scroll wheel when I hover the cursor over them. And in some (most?) cases, there's also a value field I can edit directly if I want to be precise.
Or if I want to automate a gradual knob change over time as the song plays, I can either record myself "scrolling" the knob or draw the change into an automation track (and again, can set precise values for knob values at precise times if I want to).
But of course, professionals own hardware that they connect to the DAW, which renders most of that stuff irrelevant.
Or if I want to automate a gradual knob change over time as the song plays, I can either record myself "scrolling" the knob or draw the change into an automation track (and again, can set precise values for knob values at precise times if I want to).
But of course, professionals own hardware that they connect to the DAW, which renders most of that stuff irrelevant.
Music plugins have to have skeumorphic UIs, nobody wants to twist generic looking knobs. C'mon man, these are artists, they are not the average muggle.
If designers from this world got ahold of the music scene from that world plugins would get considerably worse, as UI's would be the focus of intense simplification, leaving complex features and their power users by the wayside.
If designers from this world got ahold of the music scene from that world plugins would get considerably worse, as UI's would be the focus of intense simplification, leaving complex features and their power users by the wayside.
Is there any actual evidence that "nobody wants to twist generic looking knobs"? It seems like a widespread assumption, but I don't know to what extent it's been measured or tested.
I, for example, am a nobody (a hobbyist musician) who dislikes most custom VST UIs. Back in the day, FL Studio (nee Fruityloops) shipped with a bunch of plugins that looked like they had an autogenerated UI, with every parameter getting its own controls (a knob, numeric readout, and visual bar)... and I liked them. No cruft, and it was easy to systematically manipulate each control to determine its effect on the sound.
I, for example, am a nobody (a hobbyist musician) who dislikes most custom VST UIs. Back in the day, FL Studio (nee Fruityloops) shipped with a bunch of plugins that looked like they had an autogenerated UI, with every parameter getting its own controls (a knob, numeric readout, and visual bar)... and I liked them. No cruft, and it was easy to systematically manipulate each control to determine its effect on the sound.
I know exactly of that auto-generated UI (I also do hobbyist stuff with FL) and I hated it. Different strokes for different folks, I guess.
There's also the unintended side effect that now I know how to operate studio recording equipment because skeumorphic UI taught me how so many of these things work.
There's also the unintended side effect that now I know how to operate studio recording equipment because skeumorphic UI taught me how so many of these things work.
No they don't. Best audio software does not have skewmorphic UI's. I personally prefer minimalist looks. Ableton Live is a good example in the other direction.
Again, different strokes for different folks. Ableton is popular but so is FLStudio, iZotope plugins, Cubase, or ProTools. I am thankful this trend towards functional minimalism for ease-of-use is relatively contained in the music software scene.
I would disagree with regards to the usability of knobs. They represent the information that would otherwise be presented in a numeric text box or a slider in a much more compact space (since it's angular vs. linear displacement) and the mouse based interaction generally is the same as a slider (grab and then move vertically to change or move vertically with a modifier for fine grained movement).
There are applications out there which use angular drag/mouse information when grabbing knobs, but they are the tiny minority (and as you can guess there's all sorts of issues doing so).
There are applications out there which use angular drag/mouse information when grabbing knobs, but they are the tiny minority (and as you can guess there's all sorts of issues doing so).
As a bonus you get zero precision as manifested by endless fiddling to set the control just right. If it is digital, give a nice digital input. If you want, feel free to also give a clickable interface of the knob but please let dragging die, and always provide numeric input.
Yeah... audio software, especially VST plugins, have a tendency to 1) all invent their own UI styling and 2) use skeuomorphic designs. I wish this trend would stop, but it doesn't look at all likely.
It has its upsides, I guess - such as it would be instant to learn (if a bit cumbersome to use) for someone who already has experience with physical interfaces.
It's been a while since I used these UIs, but usually what happens is you click on the knob and it turns into a vertical slider. Not so bad really.
The skeumorphic UI lets you move between the physical panel and the GUI pretty seamlessly. Not saying there isn't a better option, but this at least is pretty nice for beginners.
The skeumorphic UI lets you move between the physical panel and the GUI pretty seamlessly. Not saying there isn't a better option, but this at least is pretty nice for beginners.
Except for a few emulations of hardware, most of these UI's don't correlate to a physical panel and the lack of consistency between the various virtual-only ones, IMHO, negates any benefit from a consistency point of view. Having something look like a physical knob is one thing, but when each plugin you have has its own different style of "physical knob" design, I find it gets messy personally.
Dragging knobs up and down is the standard way to interact with audio software.
Hi, author here. Just a reminder that we don't use OpenGL, and that it's not skeuomorphism if you don't have virtual screws :)
Am I the only person who considers this beyond idiotic? So now the audio processing machine doesn't need only a powerful CPU for audio but also a good GPU with good OpenGL drivers so that a plugin (not even the main application, but a plugin!) can draw its knobs?
Seriously, what were they thinking? Why does a plugin even need photo-realistic looking controls? It is not like they work any better than a regular button or slider ...
There is a saying in engineering - "That you can do something doesn't mean you should ..."
double facepalm