@Joe, I haven't made any benchmark, but from my experience the performance is very very poor for ScriptProcessorNodes. I have made some tests a while ago on a rather slow smartphone : while I could run several dozen native BufferSourceNodes (interpolated sample playback) without any problem, a single ScriptProcessorNode running a rather simple effect would make the whole page choke, and lots of audio glitches ... It is no wonder when you know that native nodes are optimized C++ running in a separate thread, while ScriptProcessorNode is JavaScript, running in the main thread of the page (which also does graphics, user events and pretty much everything else)> since it's really easy to build [cos~] with writing [cos] values to a table¹, wouldn't it make sense to add [cos] and [until] to the WebPd core?@Julian, [abs~] would be easy, [wrap~] isn't possible with nodes once again...
@IOhannes yes that's an option. Unfortunately, table lookups are not that fast in Web Audio API ... and they have some bugs in firefox. In fact there isn't even an object designed specifically for this. I have to use this bloody WaveShaperNode (http://webaudio.github.io/web-audio-api/#WaveShaperNode) and a few hacks. Web Audio API is really hopeless at times.
> is it the same situation with [abs~] and [wrap~]?
> Out of curiosity how are the native nodes different from using the ScriptProcessorNode?I am also looking forward to AudioWorkerNodes!!! But it has been a rather slow process ... And then when they arrive, there will be a question, which is whether it is more performant to implement the whole DSP in a single AudioWorkerNode (and forget about native nodes altogether), or a mixed solution which uses native nodes whenever possible and AudioWorkers when not. So the future is really uncertain. For this reason I plan to restructure WebPd so that it can support different distributions, with different implementations or different objects. So that it would be possible to choose between one or the other solution easily. Here are the tasks for the next milestone 0.4.0 which I plan to finish for end of September : https://github.com/sebpiq/WebPd/issues?q=is%3Aopen+is%3Aissue+milestone%3A0.4.0So @Julian, I'll go with the [osc] + [until] solution. Meanwhile, if you don't wanna wait, you can also fill-up the table with Pd, and save the table contents in the patch. Then just do table lookup as he suggested.
--On Wed, Aug 26, 2015 at 12:24 PM, Joe White <white.joe4@gmail.com> wrote:I'll have to use a slow ScriptProcessorNode.Here's to hoping for Audio Worker Nodes aye :(Out of curiosity how are the native nodes different from using the ScriptProcessorNode? For something simple like abs~ or wrap~ is performance that drastically worse?On 26 August 2015 at 09:53, Julian Brooks <jbeezez@gmail.com> wrote:Hi Seb,Thanks for having a go.While absolutely agreeing with IOhannes, is it the same situation with [abs~] and [wrap~]?Regards,Julian]On 26 August 2015 at 09:36, IOhannes m zmoelnig <zmoelnig@iem.at> wrote:_______________________________________________On 2015-08-26 10:25, s p wrote:
> Hmm ... actually I got carried away. I can't implement [cos~] or [env~]
> with native web audio API nodes.
> I'll have to use a slow ScriptProcessorNode. So if performance is not a
> concern for you I'll do it, but I won't integrate it to the core of WebPd.
>
since it's really easy to build [cos~] with writing [cos] values to a
table¹, wouldn't it make sense to add [cos] and [until] to the WebPd core?
fgmsdt
IOhannes
¹ assuming that table lookups in WebPd are as blindingly fast as
anyhwere else.
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
_______________________________________________
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
_______________________________________________
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list