Awesome :D I need to put things in order with WebPd, as I was saying in previous posts. But then it'd be awesome to work on this with you!!! In fact I was talking with other people in the Web Audio community, cause there's no good JS dsp library. So basically that would really fill-up a gap in the JS ecosystem!!!
On Wed, Sep 9, 2015 at 12:28 PM, Joe White <[email protected]> wrote: > 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 <[email protected]> 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 <[email protected]> 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 <[email protected]> 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 <[email protected]> >>>> 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 <[email protected]> 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 <[email protected]> >>>>>> 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/ >>>>>>> >>>>>>> >>>>>>> _______________________________________________ >>>>>>> [email protected] mailing list >>>>>>> UNSUBSCRIBE and account-management -> >>>>>>> http://lists.puredata.info/listinfo/pd-list >>>>>>> >>>>>> >>>>>> >>>>>> >>>>>> -- >>>>>> >>>>>> *Sébastien Piquemal* >>>>>> >>>>>> -----* @sebpiq* >>>>>> ----- http://github.com/sebpiq >>>>>> ----- http://funktion.fm >>>>>> >>>>>> _______________________________________________ >>>>>> [email protected] 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 >> > > -- *Sébastien Piquemal* -----* @sebpiq* ----- http://github.com/sebpiq ----- http://funktion.fm
_______________________________________________ [email protected] mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
