[PD] Present and future of WebPd

[Joe White]

The Heavy library part is all MIT licence for non-commercial projects.

Basically a modular asm.js dsp library?


Let's do it!

On 9 September 2015 at 11:24, s p <sebpiq at gmail.com> wrote:

> And when is Heavy open-source ;) so I could use all this niceness?
> Or what about open-sourcing something like this? Basically a modular
> asm.js dsp library?
>
> On Wed, Sep 9, 2015 at 12:18 PM, Joe White <white.joe4 at gmail.com> wrote:
>
>> Oh yes I see, you're right.
>>
>> However, all the low level operations are modular enough that I guess you
>> could compile each into their own asm.js modules and then reconnect them
>> (pretty much replacing the processing loop).
>>
>> It's likely due to lack of experience with javascript and the desire to
>> have a single bundle for the user to import that we compile the whole
>> program.
>>
>> On 9 September 2015 at 11:12, s p <sebpiq at gmail.com> wrote:
>>
>>> > This is the exactly what we do in Heavy.
>>>
>>> is it? I somehow thought that you compile a patch with emscripten to a
>>> monolithic asmjs piece of code?
>>>
>>> What I mean is that with asm.js you can have very small modular
>>> functions that are asm.js optimized and called by some JS code that is not
>>> asm. For example a dsp tick function could do :
>>>
>>> objects.forEach(function(obj) {
>>>     obj.tick()
>>> })
>>>
>>> and for example osc would be implemented like this :
>>>
>>> osc.prototype.tick = function() {
>>>     asmOptimizedSine(this.buffer, this.freq)
>>> }
>>>
>>> On Wed, Sep 9, 2015 at 12:01 PM, Joe White <white.joe4 at gmail.com> wrote:
>>>
>>>> > Also-- what about compiling libpd using emscripten?
>>>>
>>>> I think some people already did that (Martin Roth?)
>>>>
>>>>
>>>> I haven't heard of anyone doing that yet, but it's probably tricky for
>>>> reasons you pointed out.
>>>>
>>>> One other possible flavour of WebPd could be that the dsp is
>>>>> implemented as small functions in C compiled with emscripten.
>>>>
>>>>
>>>> This is the exactly what we do in Heavy.
>>>>
>>>> I guess there are two approaches; one being to replicate the Pd
>>>> environment (GUI + patching etc...) the other to use Pd as a way to design
>>>> audio implementations for different platforms, in this case the web. I like
>>>> the idea of people being able to create their own interfaces that don't
>>>> necessarily have to be dataflow-oriented and HTML+JS is really powerful for
>>>> that.
>>>>
>>>> On 9 September 2015 at 10:41, s p <sebpiq at gmail.com> wrote:
>>>>
>>>>> @Robert : yes ... nacl is dead. And plugins are problematic. Probably
>>>>> a plugin wouldnt work on iphone for a start, and you would need to
>>>>> implement the plugin for many platforms ... and people need to install it
>>>>> etc. Plugins are a bit 2000 ;) flash and java and friends .... they are
>>>>> going to disappear sooner or later
>>>>>
>>>>> > Also-- what about compiling libpd using emscripten?
>>>>>
>>>>> I think some people already did that (Martin Roth?) ! It would
>>>>> probably work fine, the only thing is there will be issues with all the
>>>>> parts where the code needs to cooperate with the browser. Typically :
>>>>> loading resources (sound files), updating some graphics, etc ... Also you
>>>>> probably couldn't script things with JS.
>>>>> But most of all I think (Chris tell me if I'm wrong), WebPd started as
>>>>> an experiment to see what could be done in the browser only. Myself, I like
>>>>> that idea of doing only JavaScript. Pushing JS forward, developing tools to
>>>>> do dsp, etc ... so giving back to the JavaScript ecosystem through
>>>>> developing WebPd is a nice thought to me. Also you know ... I no nothing
>>>>> about C/C++ :) and I know JS quite well ... and as they say "if all you
>>>>> have is a hammer , everything looks like a nail" !!! On the other hand,
>>>>> that's also why I like the idea I explained in the other post about
>>>>> removing the dsp implementation from teh core. One other possible flavour
>>>>> of WebPd could be that the dsp is implemented as small functions in C
>>>>> compiled with emscripten. Even maybe why not reusing some of libpd? But I
>>>>> probably can't do it myself ...
>>>>>
>>>>> On Wed, Sep 9, 2015 at 6:22 AM, Chris McCormick <chris at mccormick.cx>
>>>>> wrote:
>>>>>
>>>>>> On 09/09/15 11:13, Jonathan Wilkes via Pd-list wrote:
>>>>>>
>>>>>>> Also-- what about compiling libpd using emscripten?
>>>>>>>
>>>>>>
>>>>>> Do it!
>>>>>>
>>>>>> Chris.
>>>>>>
>>>>>> --
>>>>>> http://mccormick.cx/
>>>>>>
>>>>>>
>>>>>> _______________________________________________
>>>>>> 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
>>>>>
>>>>> _______________________________________________
>>>>> 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
>>>
>>
>>
>
>
> --
>
> *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/20150909/1a4cfdff/attachment-0001.html>