6 ms·

It seems their goal is to make a full-fledged DAW in the browser, but they are not there yet (and far from it from what I can tell). How they would be able to f

It seems their goal is to make a full-fledged DAW in the browser, but they are not there yet (and far from it from what I can tell). How they would be able to fund all that for $2k is beyond me. That said, it's a really clever idea to have all the source editable, since js is an interpreted language anyway. One can imagine a future where the community not only shares songs and sounds, but the DSP units themselves. Unlike desktop DAWs, which rely on dylibs (dlls) to supply external synths and effects, a js-based DAW can load, re-compile and hotswap units on the fly.

JonnieCache 12y ago
This kind of thing has existed in desktop/native form for some years. Look up supercollider.
- fat0wl 12y ago
  & max/msp even included js but it operated at control rate, not audio, so you couldn't write synths directly as js
  - larme 12y ago
    Max now have gen[1] so you can write audio/sample rate code. [1]: http://cycling74.com/products/gen/ http://cycling74.com/products/gen/
    - fat0wl 12y ago
      yea want to try it but i'm stuck on max 5... max upgrades are more expensive than they're worth & now its splitting into multiple products (max4live,gen) so i'm kindof on an every other generation plan unfortunately. especially annoying when features you like get deprecated (pluggo, ms. pinky) though i understand gen & max4live both kinda serve as pluggo replacements. all in all its just hard for me to pull the trigger on a $250 upgrade for a few extra integration points on a tool that should be mostly open source anyway. http://puredata.info/ http://puredata.info/
      - fat0wl 12y ago
        And I should point out that I personally feel kinda guilty... I met Miller Puckette and he was so enthusiastic about PureData and how much more the community could grow. I realize the biggest reason Max is thriving is because of marketing and now integration with Ableton. I feel like if something were done to prevent Pd from being wiped off the map we could have had an open source community by now rather than Cycling 74. hm.... the media production world is complicated for open source tho.
        anigbrowl 12y ago
        There's a reasonably active community around PD, but it has the same problem as a lot of other open source software - it's hideously ugly. IIRC the user interface is done with TCL/TK. Given the large number of competing products in the same space, people who are not heavily committed to open source have little incentive to use it, unfortunately. I'd say a visual/UI makeover is a higher priority right now than extending the PD library or other tasks.
        saidajigumi 12y ago
        > I feel like if something were done to prevent Pd from being wiped off the map we could have had an open source community by now rather than Cycling 74. But we got another repeat of the scenario: the OSS project was unable to muster decent UI while the commercial variant was able to both fund the staff and draw out the needs from its user community to make continual UI improvements. (Speaking specifically to the vast improvements over time culminating in Max 6.) If I sound a bit testy here, it's because I've seen too many promising OSS projects killed by this same problem: terrible user experience. > I realize the biggest reason Max is thriving is because of marketing I strenuously disagree. It's because PD absolutely failed to deliver a sane user experience, period. Sure, marketing is important, but Cycling '74's work is what makes Max at all relevant today. About all that PD ever had going for it versus Max was being open source. As someone who used Max/FTS back on the ISPW[1], even that old UI was vastly better than PD's. I enthusiastically gave PD a go when it first came out, even going back from time to time to check in on it. Every time I found it nigh unusable due to huge UI issues. Especially for what amounts to a visual programming language, this is the death knell. For comparison, it's not like early ISPW Max didn't have its pain points. Max users owe Miller Puckette a substantial debt for his contributions to this excellent visual signal/event programming environment, so it's unfortunate that PD was never able to pull it together. [1] https://en.wikipedia.org/wiki/ISPW https://en.wikipedia.org/wiki/ISPW
thuuuomas 12y ago
Sharing Supercollider snippets was a thing for awhile on twitter. THE FUTURE IS NOW.
yconst 12y ago
Seems $2k is just one of their milestones... "development is split into milestones on which the features are discussed and decided upon in the mailing list with the help of the community. a funding campaign is then setup for each next milestone which supports development and keeps the project up and alive."
chrisdevereux 12y ago
Realtime audio DSP seems like about the last thing that in-browser JavaScript was designed to do well. Janky audio is unnacceptable in a way that janky visuals aren't. It totally kills the experience. Without very strong guarantees about GC latency and thread scheduling that are neither available nor on the horizon for in-browser js, it won't work for anything beyond fun hacks.
- deleted 12y ago
  [deleted]
- chrislo 12y ago
  Are you aware of the Web Audio API? It's an API designed especially to address those concerns, and achieves low latency and high performance where it is available (Chrome, Firefox and some versions of Safari currently). https://dvcs.w3.org/hg/audio/raw-file/tip/webaudio/specification.html https://dvcs.w3.org/hg/audio/raw-file/tip/webaudio/specifica...
  - chrisdevereux 12y ago
    Yes, and it works by mostly avoiding realtime DSP in javascript. It provides a high-level API for wiring together prebuilt audio processing nodes. Much like using browser animation APIs vs programatic animation. My point is about the feasibility of JS signal processing, not the feasibility of using JS to glue together signal processors. The WebAudio API does provide a ScriptProcessorNode for JS processing, but it appears to suffer from the problems I described. The spec seems to warn against using this for realtime processing, fwiw.
    - notthetup 12y ago
      "The WebAudio API does provide a ScriptProcessorNode for JS processing, but it appears to suffer from the problems I described." Yup. That is being worked on by W3C and the WebAudio committee as we speak. WebWorker based JS processing is something being considered. https://github.com/WebAudio/web-audio-api/issues/113 https://github.com/WebAudio/web-audio-api/issues/113 http://lists.w3.org/Archives/Public/public-audio/2013OctDec/0073.html http://lists.w3.org/Archives/Public/public-audio/2013OctDec/... I am expecting this to be resolved in a few months. (hopefylly?) If the threading issues are resolved, then real time audio rendering doesn't take that much processing power and can be easily done in JS. Infact if there is nothing else contending for the EventLoop (like in this example of WavPot) the ScriptProcessorNode is able to meet the real-time guarantees pretty well, while still doing decent processing. Also going forward, with Technologies like SIMD.js and asm.js more can be done within a single onprocess callback.
squeaky-clean 12y ago
>a js-based DAW can load, re-compile and hotswap units on the fly. REAPER does just this. It has its own audio scripting language, JesuSonic (also abbreviated JS, which can get confusing), which is interpreted. It's not incredibly popular, but people do share code and modules for it. There are some who sell VSTs/AUs/etc (dlls), but give away the same plugin in a JS format in order to support Reaper.

JonnieCache 12y ago

This kind of thing has existed in desktop/native form for some years. Look up supercollider.

fat0wl 12y ago
& max/msp even included js but it operated at control rate, not audio, so you couldn't write synths directly as js
- larme 12y ago
  Max now have gen[1] so you can write audio/sample rate code. [1]: http://cycling74.com/products/gen/ http://cycling74.com/products/gen/
  - fat0wl 12y ago
    yea want to try it but i'm stuck on max 5... max upgrades are more expensive than they're worth & now its splitting into multiple products (max4live,gen) so i'm kindof on an every other generation plan unfortunately. especially annoying when features you like get deprecated (pluggo, ms. pinky) though i understand gen & max4live both kinda serve as pluggo replacements. all in all its just hard for me to pull the trigger on a $250 upgrade for a few extra integration points on a tool that should be mostly open source anyway. http://puredata.info/ http://puredata.info/
    - fat0wl 12y ago
      And I should point out that I personally feel kinda guilty... I met Miller Puckette and he was so enthusiastic about PureData and how much more the community could grow. I realize the biggest reason Max is thriving is because of marketing and now integration with Ableton. I feel like if something were done to prevent Pd from being wiped off the map we could have had an open source community by now rather than Cycling 74. hm.... the media production world is complicated for open source tho.
      - anigbrowl 12y ago
        There's a reasonably active community around PD, but it has the same problem as a lot of other open source software - it's hideously ugly. IIRC the user interface is done with TCL/TK. Given the large number of competing products in the same space, people who are not heavily committed to open source have little incentive to use it, unfortunately. I'd say a visual/UI makeover is a higher priority right now than extending the PD library or other tasks.
      - saidajigumi 12y ago
        > I feel like if something were done to prevent Pd from being wiped off the map we could have had an open source community by now rather than Cycling 74. But we got another repeat of the scenario: the OSS project was unable to muster decent UI while the commercial variant was able to both fund the staff and draw out the needs from its user community to make continual UI improvements. (Speaking specifically to the vast improvements over time culminating in Max 6.) If I sound a bit testy here, it's because I've seen too many promising OSS projects killed by this same problem: terrible user experience. > I realize the biggest reason Max is thriving is because of marketing I strenuously disagree. It's because PD absolutely failed to deliver a sane user experience, period. Sure, marketing is important, but Cycling '74's work is what makes Max at all relevant today. About all that PD ever had going for it versus Max was being open source. As someone who used Max/FTS back on the ISPW[1], even that old UI was vastly better than PD's. I enthusiastically gave PD a go when it first came out, even going back from time to time to check in on it. Every time I found it nigh unusable due to huge UI issues. Especially for what amounts to a visual programming language, this is the death knell. For comparison, it's not like early ISPW Max didn't have its pain points. Max users owe Miller Puckette a substantial debt for his contributions to this excellent visual signal/event programming environment, so it's unfortunate that PD was never able to pull it together. [1] https://en.wikipedia.org/wiki/ISPW https://en.wikipedia.org/wiki/ISPW

thuuuomas 12y ago

Sharing Supercollider snippets was a thing for awhile on twitter. THE FUTURE IS NOW.

yconst 12y ago

Seems $2k is just one of their milestones... "development is split into milestones on which the features are discussed and decided upon in the mailing list with the help of the community. a funding campaign is then setup for each next milestone which supports development and keeps the project up and alive."

chrisdevereux 12y ago

Realtime audio DSP seems like about the last thing that in-browser JavaScript was designed to do well. Janky audio is unnacceptable in a way that janky visuals aren't. It totally kills the experience. Without very strong guarantees about GC latency and thread scheduling that are neither available nor on the horizon for in-browser js, it won't work for anything beyond fun hacks.

deleted 12y ago
[deleted]
chrislo 12y ago
Are you aware of the Web Audio API? It's an API designed especially to address those concerns, and achieves low latency and high performance where it is available (Chrome, Firefox and some versions of Safari currently). https://dvcs.w3.org/hg/audio/raw-file/tip/webaudio/specification.html https://dvcs.w3.org/hg/audio/raw-file/tip/webaudio/specifica...
- chrisdevereux 12y ago
  Yes, and it works by mostly avoiding realtime DSP in javascript. It provides a high-level API for wiring together prebuilt audio processing nodes. Much like using browser animation APIs vs programatic animation. My point is about the feasibility of JS signal processing, not the feasibility of using JS to glue together signal processors. The WebAudio API does provide a ScriptProcessorNode for JS processing, but it appears to suffer from the problems I described. The spec seems to warn against using this for realtime processing, fwiw.
  - notthetup 12y ago
    "The WebAudio API does provide a ScriptProcessorNode for JS processing, but it appears to suffer from the problems I described." Yup. That is being worked on by W3C and the WebAudio committee as we speak. WebWorker based JS processing is something being considered. https://github.com/WebAudio/web-audio-api/issues/113 https://github.com/WebAudio/web-audio-api/issues/113 http://lists.w3.org/Archives/Public/public-audio/2013OctDec/0073.html http://lists.w3.org/Archives/Public/public-audio/2013OctDec/... I am expecting this to be resolved in a few months. (hopefylly?) If the threading issues are resolved, then real time audio rendering doesn't take that much processing power and can be easily done in JS. Infact if there is nothing else contending for the EventLoop (like in this example of WavPot) the ScriptProcessorNode is able to meet the real-time guarantees pretty well, while still doing decent processing. Also going forward, with Technologies like SIMD.js and asm.js more can be done within a single onprocess callback.

squeaky-clean 12y ago

>a js-based DAW can load, re-compile and hotswap units on the fly. REAPER does just this. It has its own audio scripting language, JesuSonic (also abbreviated JS, which can get confusing), which is interpreted. It's not incredibly popular, but people do share code and modules for it. There are some who sell VSTs/AUs/etc (dlls), but give away the same plugin in a JS format in order to support Reaper.