[PD] Present and future of WebPd

s p sebpiq at gmail.com
Tue Sep 8 10:46:48 CEST 2015


dammit ... JavaScript bug on my website maybe?
This pure - and ugly - html version should work :
http://funktion.fm/post/present-and-future-of-webpd

On Tue, Sep 8, 2015 at 10:42 AM, Julian Brooks <jbeezez at gmail.com> wrote:

> 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 <sebpiq at 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 <chris at 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 at 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.puredata.info/pipermail/pd-list/attachments/20150908/30417e93/attachment.html>


More information about the Pd-list mailing list