Thanks for the info Seb - will do.
On 26 August 2015 at 11:52, s p <seb...@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.4.0 > > 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.j...@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 <jbee...@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 <zmoel...@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 > >
_______________________________________________ Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list