Show HN: Web DSP audio editor(dsp.audio)
dsp.audio
Show HN: Web DSP audio editor
https://dsp.audio/editor/
48 comments
Sorry for the dumb question as I'm not in the field, but is this meant for actual midi/audio in? I tried clicking the keys on the midi to no avail, so I would assume I would use this with an actual midi (or midi file)?
Audio in is supported - it just uses your computer's audio in. Just press on the "Line In" checkbox on the left to allow your browser to access your audio. Alternatively, you can send a pre-set sample to the worklet by selecting it from the dropdown menu and pressing "Play"
Midi in is not supported yet, i.e. you can't press a key on your connected MIDI keyboard to send a MIDI message to the worklet yet. You can simulate it with the keyboard on the left. Quoting the Help page (accessible with the "?" button on the top right):
"The MIDI IN keyboard will send MIDI messages to the worklet's MessagePort. Messages are objects of the form {type: ['noteon' | 'noteoff'], value: { note, octave, midi, frequency } }"
Using physical MIDI controls will be supported in future releases, though.
Midi in is not supported yet, i.e. you can't press a key on your connected MIDI keyboard to send a MIDI message to the worklet yet. You can simulate it with the keyboard on the left. Quoting the Help page (accessible with the "?" button on the top right):
"The MIDI IN keyboard will send MIDI messages to the worklet's MessagePort. Messages are objects of the form {type: ['noteon' | 'noteoff'], value: { note, octave, midi, frequency } }"
Using physical MIDI controls will be supported in future releases, though.
Have you considered using Open Sound Control[0]? There is a nice JS package for it. I've put together a couple demo web apps using OSC as both client and server. Bonuses include that you get midi with it, it creates RESTful 2 way interfaces for your endpoints, can be shared over the internet (WebRTC), and it's universally easy to hook to other stuff! Also there is a FANTASTIC customizable interface app for iOS and Android called TouchOSC[1] that only costs $5. I use it for music and robotics.
[0] https://github.com/colinbdclark/osc.js/
[1] https://hexler.net/software/touchosc
BONUS OSC STUFF:
* https://github.com/sebpiq/rhizome
* https://github.com/attwad/python-osc
* https://github.com/thomasfredericks/UnityOSC
* https://github.com/automata/osc-web
* https://github.com/mhroth/tinyosc
[0] https://github.com/colinbdclark/osc.js/
[1] https://hexler.net/software/touchosc
BONUS OSC STUFF:
* https://github.com/sebpiq/rhizome
* https://github.com/attwad/python-osc
* https://github.com/thomasfredericks/UnityOSC
* https://github.com/automata/osc-web
* https://github.com/mhroth/tinyosc
shameless self-promotion: I work on a free software OSC sequencer: https://ossia.io
I have been looking for this for years. Awesome self promotion.
That's really cool and I'll surely consider it for future releases. I'm trying to sort out the priorities for this project and the feedback on HN is amazing. Thanks.
No problem. Your app is really cool! I really have to compliment you on the design/ux too. Clean, easy to look at, and minimal futuristic. I look forward to seeing more!
Do you have a github or a blog I can follow? I didn't see anything in the info on your site.
Do you have a github or a blog I can follow? I didn't see anything in the info on your site.
Thanks! The UI is something I came up with, and that normally I use in my side projects. I'm separating it from my business logic code and maybe I will share the components sooner or later. I just don't know if the world needs another set of React components, and if I have time to maintain them :)
The blog is a WIP, I would like to blog about Audio DSP with maybe code examples hosted on the worklet editor. I just need to find the time.
My GitHub repo is cristiano.belloni, but I don't really use it - I normally use GitLab these days, and most of my repos are private for one reason or another. I'll probably open some of them, but only if I know there is interest and I can maintain them properly.
The blog is a WIP, I would like to blog about Audio DSP with maybe code examples hosted on the worklet editor. I just need to find the time.
My GitHub repo is cristiano.belloni, but I don't really use it - I normally use GitLab these days, and most of my repos are private for one reason or another. I'll probably open some of them, but only if I know there is interest and I can maintain them properly.
This is a good introduction to worklets: https://developers.google.com/web/updates/2017/12/audio-work...
These are a bunch of demos: https://googlechromelabs.github.io/web-audio-samples/audio-w...
These are a bunch of demos: https://googlechromelabs.github.io/web-audio-samples/audio-w...
Creator here - thanks for the feedback!
For anyone interested on the stack, the visual part is React / Redux SPA. I use Firebase's Firestore as a DB (I wanted to try it and so far it's really cool) and Google Cloud Functions for the APIs. The repo is hosted on Gitlab and is a Lerna monorepo, which is amazing.
For anyone interested on the stack, the visual part is React / Redux SPA. I use Firebase's Firestore as a DB (I wanted to try it and so far it's really cool) and Google Cloud Functions for the APIs. The repo is hosted on Gitlab and is a Lerna monorepo, which is amazing.
Very cool! Is there a link to the repo? I didn't see one...
[deleted]
It's a private repo; I will probably open parts of it in the future.
This is great! I really hope developers keep pushing the webAudioApi. Its not hard to imagine serious browser based DAWs within 5yrs. I've been doing my webaudio experiments here: http://treblemaker.ai
That's really good! I'll take a look as soon as I get home.
This is cool and looks promising! If you want some DSP functions in JS, I had made some[0] in the past. They're all MIT licensed and sometimes you would need to adapt the code a bit because of the imports and globals that are implicit as these were domain specific.
[0]: https://github.com/opendsp
[0]: https://github.com/opendsp
That is a goldmine, thanks!!
Hey glad you like them! There are some more on my personal account you can browse from here[0]. Feel free to reuse/modify, all MIT.
[0]: http://wavepot.com/stagas
[0]: http://wavepot.com/stagas
(Chrome only)
For now, yes. But, since the app is based on a standard spec, other browser will hopefully support Web Audio Worklets soon.
> — Please note that the app runs only on Chrome > v66, for
> now, because Chrome is the only browser implementing the
> Audio Worklet[1] spec. Other browser will follow suit
> (hopefully) soon
[1] https://developers.google.com/web/updates/2017/12/audio-work...
> — Please note that the app runs only on Chrome > v66, for
> now, because Chrome is the only browser implementing the
> Audio Worklet[1] spec. Other browser will follow suit
> (hopefully) soon
[1] https://developers.google.com/web/updates/2017/12/audio-work...
Just to be clear, Audio Worklet is not "a standard spec". It's an earlyish-stage spec proposal which might well change as it goes through the standardization process.
Absolutely - see my answer here: https://news.ycombinator.com/item?id=17610784
Yeah, 'It seems you're trying to run the editor with an old or unsupported browser' is kinda odd given it just runs on Chrome...
As soon as browser support the standard, the message will be shown less and less. Chrome was an early adopter, but Audio Worklets are part of a W3C working draft, which is the de facto standard for web audio:
https://www.w3.org/TR/webaudio/
https://www.w3.org/TR/webaudio/
Qualifying browsers that don't follow an early adopter in implementing a working draft of being "old" is kind of odd and disparaging. A simple message like "Sadly your browser does not seem to support spec foo yet, but you can try one of those: browser X v>42, Y, Z".
Sorry if I hurt any browser's sensibility. Hope no browser was offended by my app :)
However, I didn't refer to "browsers that don't follow an early adopter in implementing a working draft" as "old", though; if you read the compatibility message carefully, you'll find I referred to them as "unsupported" (which might be a bit inexact but not disparaging).
Non-evergreen browsers, instead, are correctly referred to as "old", because they are.
However, I didn't refer to "browsers that don't follow an early adopter in implementing a working draft" as "old", though; if you read the compatibility message carefully, you'll find I referred to them as "unsupported" (which might be a bit inexact but not disparaging).
Non-evergreen browsers, instead, are correctly referred to as "old", because they are.
There’s an “or” in that sentence: “old or unsupported browser”
The term unsupported browser sounds like it's intentionally only for Chrome.
That's true, that's inaccurate. I'll change the message with the next deploy.
I’m not saying that the message sounded good, I’m just saying that it’s technically accurate. Other browsers don’t support the bleeding edge features the site needs and therefore they’re unsupported.
Nitpicking cool projects is also pretty disparaging.
Calling it a standard might be jumping the gun. from your very link
> Publication as a Working Draft does not imply endorsement by the W3C Membership. This is a draft document and may be updated, replaced or obsoleted by other documents at any time. It is inappropriate to cite this document as other than work in progress.
> Publication as a Working Draft does not imply endorsement by the W3C Membership. This is a draft document and may be updated, replaced or obsoleted by other documents at any time. It is inappropriate to cite this document as other than work in progress.
I guess so. But then again, there's a bunch of people who are taking care of the draft and browser vendors will probably implement it soon. In the ever changing world of web development, that's as close to a standard as you get, if you don't want to wait years. But yep, technically it's a W3C draft, which might change and which I'm actively monitoring.
Looks great!
Any chance of adding a piano roll for playing short melodies(and perhaps chords with the proper processor)?
Any chance of adding a piano roll for playing short melodies(and perhaps chords with the proper processor)?
Might be! I would also like to add MIDI files drag and drop, so that you can "play" your pre-made MIDIs. There are a lot of features I would like to add, and more support for MIDI is one of them.
You may like too this single file midi player that comes with a one line synthesizer
https://github.com/aguaviva/SimpleMidi
https://github.com/aguaviva/SimpleMidi
This is great!
I especially like that you've included a share mechanism. I built an audio dsp playground before, but didn't spend enough time on it to provide that.
Are you going to add a discovery page to browse people's creations?
I especially like that you've included a share mechanism. I built an audio dsp playground before, but didn't spend enough time on it to provide that.
Are you going to add a discovery page to browse people's creations?
Thanks! It's definitely a possibility, but first I would like to see how people use it. Not sure if it should be an hand picked mechanism (easy but time expensive) or an automatic one - people tag their creations, possibly vote them, and the most popular are shown (harder but once it's there it just works on its own)
Nice. The only thing I don't like about it is that its browser based, because - as a musician with a room full of hardware - its hard to get over the conclusion that browser-based music tools are simply not ready for production - i.e. I would never use this on stage or in the studio. Cute experiment though...
I understand your point of view, although there are people I know who managed to run Web Audio API plugins as VSTs :)
This particular app is meant more as a playground / sketch / sharing tool for DSP techniques, and imho it makes sense for it to be on the most immediately accessible platform, the Web.
However, it's possible to add Faust or C support to it in the future (using WebAssembly), a feature which will allow exporting your snippets directly to executable / VST.
This particular app is meant more as a playground / sketch / sharing tool for DSP techniques, and imho it makes sense for it to be on the most immediately accessible platform, the Web.
However, it's possible to add Faust or C support to it in the future (using WebAssembly), a feature which will allow exporting your snippets directly to executable / VST.
I think this is a good way to look at it. It reminds me of shadertoy except for dsp audio.
It could be compiled with a webassembly backend and loaded, but... you could almost copy/paste the process() js function into c++ and it would compile, almost.
It could be compiled with a webassembly backend and loaded, but... you could almost copy/paste the process() js function into c++ and it would compile, almost.
> run Web Audio API plugins as VSTs
Nice, I have thought about this before! Got a link?
Nice, I have thought about this before! Got a link?
I don't have a public link to the method they used, but I heard of this technique on the Web Audio Slack channel, which you can join here: https://web-audio.slack.com/. Basically, as I understood it, they found a way to wrap the Chrome runtime in a VST plugin and load it in a DAW. I guess the process can be optimised, but I'm no browser internals expert. The community is quite friendly, so if you're interested you could join it and ask, I'm sure they'll be happy to share with you.
A sound engineering illiterate here. But, both the project and the new API from chrome looks like something very interesting that I'd not want to miss.
Can somebody ELI5 to me, what this is about? Or point me in the right direction perhaps.
Can somebody ELI5 to me, what this is about? Or point me in the right direction perhaps.
In short, Audio Worklet is a new API which allows you to write code to generate or modify an audio signal in real time. The key point is that it runs in a separate browser thread, i.e. it doesn't have to wait for the browser painting the screen or loading stuff from the network to do the calculations necessary to generate the audio signal. This allows much smoother and continuous sound, something that was not possible before. Worklets share the interface with normal audio nodes, which means that they can be connected with other nodes (such as pre-made sample players, oscillators, filters) and even microphone / line in inputs.
This application allows you to write, test and save / share them. The idea is to have an online playground to share DSP code, like a sort of JSFiddle, but for audio.
This application allows you to write, test and save / share them. The idea is to have an online playground to share DSP code, like a sort of JSFiddle, but for audio.
Doesn't seem to play on Android 6, Chrome.
What did you do to try it? How does it fail?
— Please note that the app runs only on Chrome > v66, for now, because Chrome is the only browser implementing the Audio Worklet[1] spec. Other browser will follow suit (hopefully) soon
[1] https://developers.google.com/web/updates/2017/12/audio-work...