> 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.j...@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 <seb...@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 <ch...@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@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 >> >> > -- *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