THis all sounds very interesting, unfortunately this: http://funktion.fm/#post/present-and-future-of-webpd is still devoid of text on my machine (what the deuce!:)
On 8 September 2015 at 07:47, s p <seb...@gmail.com> wrote: > > When I handed WebPd over to you, one feature that was important to me > was to have WebPd work as a system where you could take an existing Pd > patch and be pretty sure it would sound and work the same > > And I agreed with this goal of yours! Only if you remember, these were > different times. Web Audio API had not fully landed, WebPd was firefox only > and working on Audio Data API, which provided a simple callback to write > audio to the sound card buffers and nothing else, so custom dsp was the > only way to go. With the deprecation of Audio data API in favor of web > audio API, and native nodes becoming the default thing (custom dsp being > only a second class citizen), I couldn't just ignore the option of > rebuilding it on native nodes. > > My hope was that : > 1) native nodes would be enough to implement a significant part of Pd's > functionalities, with ScriptProcessorNode complementing what couldn't be > implemented with a big !!!use these objects carefully : performance penalty > warning sign > 2) the difference in implementation in native nodes compared to pd objects > wouldn't be that significant. > > I think I was mostly wrong on both points ... However, the biggie, which > decided me on this, is that you couldn't really use WebPd on mobile devices > with custom dsp. ScriptProcessorNode would immediately choke, and make the > whole thing pretty much unusable. So this was basically a choice between on > one hand purity and sticking to desktop Pd, on the other hand usability and > cross-browser / cross-device -ness. And so I chose pragmatism over purity > (and that was a heartbreaking choice : after my first failed attempt at > reimplementing WebPd with native nodes I was totally gutted : > https://github.com/WebAudio/web-audio-api/issues/263 ). > > I think for now that was somehow the right choice, since I came up with a > version of WebPd which ... even if it parts from Pd on some points, is much > more useful than a faithful version which couldn't run on most devices. I > myself used WebPd to do things I coudn't have done before (live > performances on mobile phones). And I think that makes the library more > sustainable, since it becomes not just a fancy toy, but a serious > alternative to using plain Web Audio. > > I woudn't reconsider that decision if it wasn't for the fact that times > they are a changing again, with the arrival of AudioWorker to replace > ScriptProcessorNode... which MIGHT make custom dsp a viable option once > again. So this is really all this is about. Bloody specifications changing > every 6 months, and me trying to keep up ;) > > > I only hope to persuade you that faithfulness to Pd's output is probably > a feature that users will appreciate a lot. > > to conclude ... you don't need to persuade me of this :) I just think it > is more important to have something you can use at all. But the future > might be brighter, and maybe these two goals won't contradict each other > any more. > > > On Tue, Sep 8, 2015 at 5:00 AM, Chris McCormick <ch...@mccormick.cx> > wrote: > >> On 08/09/15 10:49, Chris McCormick wrote: >> >>> I am glad to see it live on with >>> somebody who codes as energetically as you >>> >> >> chr15m: 98 commits / 8,028 ++ / 1,712 -- >> sebpiq: 253 commits / 322,207 ++ / 250,725 -- >> >> Lol! >> >> Chris. >> >> -- >> http://mccormick.cx/ >> > > > > -- > > *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