Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

PBR for Audio Software Interfaces (2016)

auburnsounds.com

Post reply on HN
Print view View original

21–30 of 35 posts

Re: PBR for Audio Software Interfaces (2016)

#21

Post by FigBug »

fit2rule wrote: post #13
FigBug wrote: post #11

Earlier quoted context omitted.

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 effic…

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?

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.

Re: PBR for Audio Software Interfaces (2016)

#22

Post by tomc1985 »

arximboldi wrote: post #14
tomc1985 wrote: post #9

Earlier quoted context omitted.

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.

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.

Re: PBR for Audio Software Interfaces (2016)

#23

Post by justaaron »

janoc wrote: post #19

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

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

Re: PBR for Audio Software Interfaces (2016)

#24

Post by justaaron »

AceJohnny2 wrote: post #18

Oh skeuomorphic hell in DAW software... 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)

Re: PBR for Audio Software Interfaces (2016)

#25

Post by infogulch »

janoc wrote: post #19

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

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.

Re: PBR for Audio Software Interfaces (2016)

#26

Post by Kuraj »

FigBug wrote: post #21
fit2rule wrote: post #13

Earlier quoted context omitted.

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?

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.

Re: PBR for Audio Software Interfaces (2016)

#27

Post by p0nce »

janoc wrote: post #19

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

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.

Re: PBR for Audio Software Interfaces (2016)

#28

Post by p0nce »

benwad wrote: post #2

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

Re: PBR for Audio Software Interfaces (2016)

#29

Post by p0nce »

Kuraj wrote: post #4

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?

Dragging knobs up and down is the standard way to interact with audio software.

Re: PBR for Audio Software Interfaces (2016)

#30

Post by p0nce »

justaaron wrote: post #23
janoc wrote: post #19

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

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 cooperat…

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.

Post reply on HN