Show HN: A 64-step drum sequencer I built using React and Redux

Keep up the good work !

Consider having the space bar toggle playback - would make it so much smoother to use! (used to that from all kinds of music software)

I also wish I could save a pattern as a long link. (MIDI slave sync support would also be nice, but I’m not sure browser sound libraries support that)

edit: since you came up with this project with less than 1 year of learning how to code, I'm very curious about your music.

Some dnb fun (174bpm), nifty to see how useful a fresh look can be uniquely effective with the tools of the days.

I've tried helping career-stuck people learning to code and build apps, but I've found it difficult teaching them everything from the ground up.

As a mostly self taught developer, I do believe it's just matter of dedication and sheer will though, and thank you for proving that right.

It would be a fun challenge for me to programmatically figure out if the user is experiencing issues and disabled features to improve performance...

I think the flows of React and Redux are just not built for timing-sensitive applications like these. A lot of allocations and deallocations are taking place without any user input. Looking at the source code, the many selectors and other hooks probably has something to do with that.

Redux is also very explicit about treating objects as immutable, causing a lot of duplication as a result. For a simple web application this shouldn't be too much of a problem but again, this application is very sensitive to timing issues where 50ms of GC can cause a noticeable performance degradation.

It's not that the code is bad, it seems quite well memo-ised to get decent performance; I think it's a result of using the wrong too for the job, nothing more. Quite impressive that a framework as heavy as React can be made this responsive in my opinion.

If you run into any memory troubles, check about:performance and about:memory, you may be able to find what's causing the memory leaks.

https://www.html5rocks.com/en/tutorials/audio/scheduling/ is an article written by my former fellow co-editor of the Web Audio API specification, that talks in length about this.

In 2021, with the AudioWorklet [0] being available in all major browsers (including Safari as of a few weeks ago!), arbitrary computations can happen on the real-time audio thread. It is now possible to send a copy of the sequencer data (which note when, what sample, what velocity, etc.) to the real-time thread, and let it play, unaffected by the load of the machine, be it from the browser or other programs (until everything breaks down because you're also overloading the audio thread).

I think this app is very good and does the best it can under the programming model it's using, considering the environment it's being run in, but if more robustness is needed, there is now a way !

On your last paragraph, it is still _absolutely_ critical. An audio software that doesn't use a real-time thread for rendering cannot render audio without glitches, even under no load, even on a fast machine. You don't need to tune the OS [1] and pick special hardware these days: today's computers (and even computers from 10 years ago or older) are perfectly capable or running reasonably complex audio processing workloads _if the software is written correctly_. This is regardless of the use case. When we disabled the real-time thread on Windows by mistake in Firefox (adjusting priority of the process level, and then that was inherited to all threads, very quickly reverted), we had reports in a matter of _days_ (if not the next day), and the Firefox Nightly population is not that big. This was I think playing regular videos on social media, not even anything complicated.

If the author of the app, or anybody, wants to profile the app with the right tools, I've written a blog post [2] about this as well. I hear this tooling is used by audio professionals, now, and that they're happy with it. Happy to hear about any suggestion though :-).

For your Firefox-specific question, you're right that increasing the content process count will make everything better, and we're constantly improving memory usage so that it's possible to do so even on lower-specs machines, maybe it's worth a try. Please look at the "resident memory" values, and not, say, virtual or shared, because we make heavy use of shared memory and copy on write facilities of the OS to limit the memory usage when using multiple process (which we need to do for origin isolation and avoiding Spectre issues and sandboxing various bits of the browser as hard as we can, for example).

[0]: https://developer.mozilla.org/en-US/docs/Web/API/AudioWorkle...

[1]: (but you can to improve robustness further, and it helps to have good drivers, such as Jack on Linux, WASAPI with MMCSS on Windows or ASIO, or just the normal stuff on macOS)

[2]: https://blog.paul.cx/post/profiling-firefox-real-time-media-...

Thankfully the timing is handled by the Tone.js framework. It allows you to sync events with a callback function which passes in a 'time' argument that keeps everything in line.

Re: pitch/velocity. Yes! Just toggle “apply all”. You set the value then tap or slide over cells to edit individually.

This section was a pain to figure out and there’s def room for improvement.

It was designed mobile first where I find the input to be very fast, but yes, on desk/lap the buttons are way slow.

If this doesn’t happen automatically edit the url. Sorry... Very weird.

It was an extreme challenge to make this thing work cross-browser/os/device. I may look into some performance diagnostics if playback isn't great for enough users. Thx for the report.