
PBR for Audio Software Interfaces (2016) - chicago_wade
https://www.auburnsounds.com/blog/2016-09-16_PBR-for-Audio-Software-Interfaces.html
======
janoc
So, now an audio plugin system has a physically based graphics rendering
engine using OpenGL - in order to save diskspace by eliminating pictures of
_KNOBS_?

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_

~~~
p0nce
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.

~~~
janoc
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.

~~~
p0nce
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).

------
benwad
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](https://github.com/AuburnSounds/dplug#comparison-vs-iplug)) but does
anyone here have an opinion?

~~~
p0nce
Dplug has two commercial users, you'll find the only opinion that is not mine
here: [http://www.modernmetalproduction.com/dplug-developing-vst-
pl...](http://www.modernmetalproduction.com/dplug-developing-vst-plugins-for-
linux/)

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...

------
ATsch
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.

~~~
p0nce
Good point, I will perhaps remove it. On my phone tests if was okay.

------
AceJohnny2
Oh skeuomorphic hell in DAW software...

I love this rant/gallery:

[https://theoutline.com/post/2157/why-are-there-so-many-
knobs...](https://theoutline.com/post/2157/why-are-there-so-many-knobs-in-
garage-band?utm_source=TW)

~~~
justaaron
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)

------
Kuraj
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?

~~~
tomc1985
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.

~~~
jpfed
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.

~~~
tomc1985
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.

------
p0nce
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 :)

