Alright! I've added [until], [cos], [sin], [tan], [atan], [log], [exp], [sqrt], [abs] to WebPd. Please tell me if you have any problem! Also please share your experiments when you're done ;)
On Wed, Aug 26, 2015 at 2:51 PM, Julian Brooks jbeezez@gmail.com wrote:
Thanks for the info Seb - will do.
On 26 August 2015 at 11:52, s p sebpiq@gmail.com wrote:
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?
@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~]?
@Julian, [abs~] would be easy, [wrap~] isn't possible with nodes once again...
Out of curiosity how are the native nodes different from using the
ScriptProcessorNode?
@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)
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....
So @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
--
*Sébastien Piquemal*
-----* @sebpiq* ----- http://github.com/sebpiq ----- http://funktion.fm
Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list