• Guillaume Piolat (2/2) Sep 17 2016 In this post, I describe the software renderer available in Dplug:
• ketmar (1/1) Sep 17 2016 thank you. it was interesting reading.
• John Colvin (9/12) Sep 17 2016 Isn't that rather a lot of work to be doing? In my experience
• Guillaume Piolat (8/20) Sep 17 2016 Some customers use it on every track.
• ak (8/11) Sep 17 2016 Nice article! Interesting approach, but this is imho the triumph
• Guillaume Piolat (5/12) Sep 17 2016 7% seems a bit high, especially with the UI closed. I'll get back
• Guillaume Piolat (14/25) Sep 17 2016 So I've done some measurements in Live 32-bit:
• bitwise (3/6) Sep 18 2016 Looks good.

Guillaume Piolat <first.last gmail.com> writes:

In this post, I describe the software renderer available in Dplug:
https://www.auburnsounds.com/blog/2016-09-16_PBR-for-Audio-Software-Interfaces.html

ketmar <ketmar ketmar.no-ip.org> writes:

thank you. it was interesting reading.

John Colvin <john.loughran.colvin gmail.com> writes:

On Saturday, 17 September 2016 at 09:26:50 UTC, Guillaume Piolat 
wrote:
 In this post, I describe the software renderer available in 
 Dplug:
 https://www.auburnsounds.com/blog/2016-09-16_PBR-for-Audio-Software-Interfaces.html

Isn't that rather a lot of work to be doing? In my experience 
with audio work, reducing any and all cpu usage - even in low 
priority threads - was useful in getting stability at low 
latencies. Even when not considering latency, I was often limited 
by cpu throughput when getting towards the end of a mix (of 
course can render/freeze things, but that's not always possible 
or convenient).

Guillaume Piolat <first.last gmail.com> writes:

On Saturday, 17 September 2016 at 15:41:24 UTC, John Colvin wrote:
 On Saturday, 17 September 2016 at 09:26:50 UTC, Guillaume 
 Piolat wrote:
 In this post, I describe the software renderer available in 
 Dplug:
 https://www.auburnsounds.com/blog/2016-09-16_PBR-for-Audio-Software-Interfaces.html

 Isn't that rather a lot of work to be doing? In my experience 
 with audio work, reducing any and all cpu usage - even in low 
 priority threads - was useful in getting stability at low 
 latencies. Even when not considering latency, I was often 
 limited by cpu throughput when getting towards the end of a mix 
 (of course can render/freeze things, but that's not always 
 possible or convenient).

Some customers use it on every track.

A closed UI does not consume CPU.
Second, the data going from audio thread to UI uses a 
double-lockfree queue so the GUI can be arbitrarily slow without 
impact on the audio.
What happen on overload is that the UI will receive less repaint 
message from the OS.

ak <ak abc.de> writes:

On Saturday, 17 September 2016 at 09:26:50 UTC, Guillaume Piolat 
wrote:
 In this post, I describe the software renderer available in 
 Dplug:
 https://www.auburnsounds.com/blog/2016-09-16_PBR-for-Audio-Software-Interfaces.html

Nice article! Interesting approach, but this is imho the triumph 
of form over substance. Your GUI increases CPU usage from ~7% to 
~50% (idle open editor window) to over 100% (interacting with 
gui) -- tested with demo of Panagement AU in Live. BTW nice 
puzzle game in the corner;). Does it somehow influence sound 
processing?

Guillaume Piolat <first.last gmail.com> writes:

On Saturday, 17 September 2016 at 17:20:10 UTC, ak wrote:
 Nice article! Interesting approach, but this is imho the 
 triumph of form over substance. Your GUI increases CPU usage 
 from ~7% to ~50% (idle open editor window) to over 100% 
 (interacting with gui) -- tested with demo of Panagement AU in 
 Live.

7% seems a bit high, especially with the UI closed. I'll get back 
with the numbers in about the same setup here.

 BTW nice puzzle game in the corner;). Does it somehow influence 
 sound processing?

Not at all. The first user to solved it already won a free 
license.

Guillaume Piolat <first.last gmail.com> writes:

On Saturday, 17 September 2016 at 17:20:10 UTC, ak wrote:
 On Saturday, 17 September 2016 at 09:26:50 UTC, Guillaume 
 Piolat wrote:
 In this post, I describe the software renderer available in 
 Dplug:
 https://www.auburnsounds.com/blog/2016-09-16_PBR-for-Audio-Software-Interfaces.html

 Nice article! Interesting approach, but this is imho the 
 triumph of form over substance. Your GUI increases CPU usage 
 from ~7% to ~50% (idle open editor window) to over 100% 
 (interacting with gui) -- tested with demo of Panagement AU in 
 Live. BTW nice puzzle game in the corner;). Does it somehow 
 influence sound processing?

So I've done some measurements in Live 32-bit:

- Panagement: 5% audio processing 20% UI
- TDR Kotenikov: 9% audio processing 15% UI
- Compassion: 1% audio 4% UI
- Tritik: 1% audio 5% UI (though this one has no UI feedback)
- MJUC: 7% audio 18% UI

I'd say it's in the same ballpark of other products in the same 
space. The more CPU conscious plugins to display tend to have 
less visual feedback.

The numbers are better on Windows, I'm not sure why. I've 
suspected different processors but there is maybe something else.

Note that these measurements were done on the slowest MacMini you 
could buy in late 2012.

bitwise <bitwise.pvt gmail.com> writes:

On Saturday, 17 September 2016 at 09:26:50 UTC, Guillaume Piolat 
wrote:
 In this post, I describe the software renderer available in 
 Dplug:
 https://www.auburnsounds.com/blog/2016-09-16_PBR-for-Audio-Software-Interfaces.html

Looks good.