janesconference

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.

It's a private repo; I will probably open parts of it in the future.

That's really good! I'll take a look as soon as I get home.

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.

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.

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.

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.

That's true, that's inaccurate. I'll change the message with the next deploy.

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/

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...

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.

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.

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)

What did you do to try it? How does it fail?

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...

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.

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.

Creator here, happy to answer any questions! Here's an example delay effect: https://dsp.audio/editor/QbQuSG8sMKsMnrqgf7NB/1 Please feel free to use the tool to prototype or show your creations around.

— 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...

Creator here, happy to answer any questions! Here's an example delay effect: https://dsp.audio/editor/QbQuSG8sMKsMnrqgf7NB/1

Please feel free to use the tool to prototype or show your creations around.

— 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...

The image doesn't exist anymore?

Wait - this person is subletting a room in a rented house? How is it even legal?

Document UX interactions other than UI design.

Don't forget unhappy paths both in the UI wireframes and UX interactions, because they'll absorb most of the development process (sad but true).

Ensure you have a contract draft ready for the web dev to sign. Ensure you're prepared to pay in line with the current industry rates.

Capping uploads for Wikipedia Zero to a reasonable limit per user wouldn't work?

No implementation = joke.

Ah cool, I didn't realize it was client-side only. Neat!

Hi, my tests were limited (I'm at work atm), but I liked it so far. I will probably use it more in the next days.

I appreciate your service is scalable, but surely you pay for CPU and bandwidth. Your application seems pretty bandwidth-intensive, as it's bound to be (80mb for a < 10-mins video off youtube), what happens if you hit gigabytes worth of downloads per day?

Hi! This also duplicates as a way to see videos behind proxies :)

Two questions:

- Are you using open source libraries to download the videos? if yes, what libraries?

- If lots of people start using 4vid, how do you plan to keep up with the costs of serving / running it?

You can build fairly complex apps because you own all the components. In real life, you don't always have the luxury: when you have an ecosystem, the core system must be able to support it. Imho you can't easily, and I'd love you to prove me wrong. These are not new problems: older frameworks lived or died trying to solve these issues already.

If cell apps need to be structured differently, how should they be structured? How do you plan to support single source of truth and a large number of third party libraries written with your framework without scope clashes? I appreciate I can avoid using your framework, but that's not the point :I'm trying to express my criticism in order for you use it (or to throw it away, if you like) - I suppose you submitted your software to HN in order to receive honest feedback.

> Just like you can build spaceships, police station, cars, and all kinds of complex things using lego blocks, you can build complex architecture using the simple building block that is cell

Except you cannot have a hierarchy of cells without the top level cell having responsibility of the whole world below in its own scope: that doesn't scale well and limits complexity to maybe a couple of levels.