Re: PBR for Audio Software Interfaces
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.
Re: PBR for Audio Software Interfaces
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.
Re: PBR for Audio Software Interfaces
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.
Re: PBR for Audio Software Interfaces
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.
Re: PBR for Audio Software Interfaces
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?
Re: PBR for Audio Software Interfaces
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).
Re: PBR for Audio Software Interfaces
thank you. it was interesting reading.
