Hi Sébastien,
I’m curious, was a plugin (e.g., PPAPI) or Chrome native client ever considered? Such as how Unity encapsulates it’s projects in a NPAPI plugin. Most of these SDKs are C/C++ so it could theoretically circumvent the need for Web Audio API and also use some of Pd’s native code.
Anyway, I’m quite impressed with what you’ve done with WebPd.
-Rob
Robert Esler Co-Director urbanSTEW
Also-- what about compiling libpd using emscripten? -Jonathan
On Wednesday, September 9, 2015 1:00 AM, "puredata@11h11.com" <puredata@11h11.com> wrote:
I’m curious, was a plugin (e.g., PPAPI) or Chrome native client ever considered?
In 2013, Google announced that they would be deprecating and then disabling NPAPI. Don't know about PPAPI.
Cheers~
Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
On 09/09/15 11:13, Jonathan Wilkes via Pd-list wrote:
Also-- what about compiling libpd using emscripten?
Do it!
Chris.
@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@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.
Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
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@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@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.
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
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@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@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@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.
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
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@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@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@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@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.
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
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@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@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@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@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@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.
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
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@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@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@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@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@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@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.
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
--
*Sébastien Piquemal*
-----* @sebpiq* ----- http://github.com/sebpiq ----- http://funktion.fm
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 white.joe4@gmail.com 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 sebpiq@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@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@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@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@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@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
--
*Sébastien Piquemal*
-----* @sebpiq* ----- http://github.com/sebpiq ----- http://funktion.fm
Sounds totally rad!
On 9 September 2015 at 11:32, s p sebpiq@gmail.com wrote:
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 white.joe4@gmail.com 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 sebpiq@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@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@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@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@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@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
--
*Sébastien Piquemal*
-----* @sebpiq* ----- http://github.com/sebpiq ----- http://funktion.fm
--
*Sébastien Piquemal*
-----* @sebpiq* ----- http://github.com/sebpiq ----- http://funktion.fm
Hi,
On 09/09/15 17:41, s p wrote:
Plugins are a bit 2000 ;) flash and java and friends .... they are going to disappear sooner or later
Also Javascript:
https://brendaneich.com/2015/06/from-asm-js-to-webassembly/#buried-lede
At least, JS will probably become relatively less popular as the language for web browsers in the next 5 years in that you will get C compilers (and Java compilers!) targeting .wasm binary. When they get wasm VMs as efficient as the JVM then things are going to get very interesting.
Also LISPs, which everybody knows are about to take over at *any moment* between Recursive Functions of Symbolic Expressions and Their Computation by Machine in 1960 and now. Any moment now, I tell you!
[At this point it's interesting to ask why they didn't just integrate the JVM more tightly/correctly/seamlessly with browsers from about 2001, and, well, *facepalm*.]
Post-wasm browsers, compiling libpd (and maybe even Pd + tcl heh) for the browser becomes a no-brainer because you just tweak the Makefile to ask GCC to target wasm instead of x86 [please apply Hofstadter's law here]. "Won't Take Long" (tm) etc.
Cheers,
Chris.
Wow!!! I didn't know about web assembly!!!
This said, We're not there yet, there will be probably a lot of opposition, like there was with asm.js (people saying we should rather optimize JS engines, as there is apparently lots lots of room for improvement). Also, writing browser code fully in C++ would be a huge step backwards in terms of usability for software developers. Probably the thing that is going to happen is rather that JS will stay the go to language, and small CPU-intensive functions will be reimplemented using webassembly. And anyways, even if al of this happen, that won't be for another 5 years before it lands ... and in 5 years so many things can happen in software world (skynet etc ...)!
On Thu, Sep 10, 2015 at 6:29 AM, Chris McCormick chris@mccormick.cx wrote:
Hi,
On 09/09/15 17:41, s p wrote:
Plugins are a bit 2000 ;) flash and java and friends .... they are going to disappear sooner or later
Also Javascript:
https://brendaneich.com/2015/06/from-asm-js-to-webassembly/#buried-lede
At least, JS will probably become relatively less popular as the language for web browsers in the next 5 years in that you will get C compilers (and Java compilers!) targeting .wasm binary. When they get wasm VMs as efficient as the JVM then things are going to get very interesting.
Also LISPs, which everybody knows are about to take over at *any moment* between Recursive Functions of Symbolic Expressions and Their Computation by Machine in 1960 and now. Any moment now, I tell you!
[At this point it's interesting to ask why they didn't just integrate the JVM more tightly/correctly/seamlessly with browsers from about 2001, and, well, *facepalm*.]
Post-wasm browsers, compiling libpd (and maybe even Pd + tcl heh) for the browser becomes a no-brainer because you just tweak the Makefile to ask GCC to target wasm instead of x86 [please apply Hofstadter's law here]. "Won't Take Long" (tm) etc.
Cheers,
Chris.
On 10/09/15 14:10, s p wrote:
This said, We're not there yet, there will be probably a lot of opposition, like there was with asm.js (people saying we should rather optimize JS engines, as there is apparently lots lots of room for improvement).
Yep. These things tend to take relative ages (unless you happen to factor in 200,000 years of Homo Sapiens history before computers existed!) and then suddenly they are working and deployed everywhere. I feel like this particular development will be in browsers quicker than we expect because all of the major browser developers are on board already and it's such a no-brainer.
Also, writing browser code fully in C++ would be a huge step backwards in terms of usability for software developers.
Different tasks need different tools. Agree that C++ is unlikely to be a good choice for web apps. There is a lot of wonderful code written in C++ that people will want to deploy and use though, especially on the library side of things.
There are a ton of other languages that would be excellent in the web-app space though, and many will be quicker and safer to develop with than JS. Python & Go spring to mind. There are already Python interpreters that compile down to JS, so it's likely they will appear with wasm targets very quickly, especially given PyPy.
PHP is another one - as loathsome and offensive a language as it is there are huge number of developers with existing code in PHP who are just itching to deploy right into your browser (thus opening up a giant attack surface the size of the USA, China & Russia combined ha ha!). If somebody writes a wasm target for PHP just you watch how fast JS disappears off the radar of popular web languages*! :)
Javascript is an interesting and fun language but not the best for everything. I am very happy at the prospect we may have even better choices soon inside the browser. Already existing better choices** not withstanding. :)
[Aside: making everyone code everything callback-based-async was
probably a mistake which they have finally realised and are undoing with
yield and await. Other languages which don't do this are much more
pleasurable to code in for many tasks that require concurrency (Pd!).]
Probably the thing that is going to happen is rather that JS will stay the go to language, and small CPU-intensive functions will be reimplemented using webassembly.
We should make a bet with some quantitative constraints. :)
And anyways, even if al of this happen, that won't be for another 5 years before it lands ... and in 5 years so many things can happen in software world (skynet etc ...)!
True!
"It's hard to make predictions, especially about the future." -Niels Bohr.
Cheers,
Chris.
Obviously popularity does not imply quality.
** https://github.com/clojure/clojurescript = yet another way to understand the value of everything and the cost of nothing - now shinier & in your browser! :D
-
Chris McCormick -
Joe White -
Jonathan Wilkes -
puredata＠11h11.com -
Robert Esler -
s p