Hi everyone, I would love to get some feedback on my drum machine project. I decided to take it a bit further and add a sequencer. Tech stack is just React with Zustand for state management.
It currently doesn’t pass the FCC tests (because they for example prevent you from having additional pads on the R/F/V keys), but I have an earlier version with a smaller feature set that does, for the sake of the certificate.
I think an important next step would be to work on best practices/performance. So I would be grateful if anyone has some points for what I’m doing wrong or good references on how to approach improving it.
The sound doesn’t seem to be working for me. I’ve got the volume cranked up to 100%. I know my sound is working because I just tested my own drum machine and it is working fine. I’m also seeing this error over and over again in the console:
“Uncaught (in promise) DOMException: The media resource indicated by the src attribute or assigned media provider object was not suitable.”
It appears to be coming from line 11 in playSound.js.
This looks very nice, much more appealing than mine (http://bbdrummachine.surge.sh/). But I think you should reconsider your decision about requiring a minimum width. The majority of people out there are surfing the web with phones. I understand why you did this but there are ways you can narrow the sequencer controls (see mine).
You’ve got outline: 0 set for all buttons which removes the keyboard focus indicator and makes it almost impossible for a keyboard user to use your drum machine. Always keep the keyboard focus indicator intact but definitely customize it so it fits your style.
Speaking of keyboard users, there is no way for them to start the sequencer because the start button is not actually a <button>. Putting a click handler on a div is not enough to make it keyboard accessible. Use a <button> like you did for the sound bank controls. Same goes for the trash cans.
There are some major accessibility issues for people using screen readers but I won’t go into those now. You can message me directly if you are interested.
But don’t get me wrong, I do like this a lot. Accessibility is my area of interest and so I always am always pointing out those issues. But this looks really cool and I can’t wait to hear it once the sound issue is fixed.
I figured out the sound issue. The <audio> element doesn’t actually take the ‘type’ attribute. If I get rid if that then the sound plays. If you were using the <source> element inside of <audio> then you could use the type attribute if needed.
Thank you for the thorough feedback! I would like to get this project to job application portfolio quality, so accessibility and just in general getting the details worked out is important to me.
A few notes:
Audio playback should work now in Chrome and Firefox. In addition to the type attribute there was a bug that caused the audio elements to get assigned their src before the component actually knew what the correct URI is, resulting in a broken audio element. For some reason this bug did not occur in Chrome or the FCC Test Suite, but did occur in Firefox. Either way it should be fixed now.
I’m still struggling to get playback working in Safari, both desktop and mobile. I think it’s related to this, which I will hopefully have time to test tomorrow javascript - HTML5 Audio tag on Safari has a delay - Stack Overflow
Your app works in Safari, do you remember what you did to achieve that?
Everything should be keyboard accessible now. I’ve also added an options menu that lets users turn off the focus indicator for some elements (but not those that are required to turn it back on). Do you think making it accessible by default, but giving the user the option to disable some of that to enhance aesthetics is an acceptable compromise?
I’ve added more keyboard shortcuts in general. So in addition to using tab to scroll through elements, everything except the sequencer pads/row delete buttons is now accessible with a single keypress.
I created responsive layouts that I’m happy with for every size down to iPhone 5, and layouts that I don’t love but are ok all the way down to 240px width. Thanks for linking to your project! 2x8 is indeed a good way to solve the sequencer, which was the main hurdle I faced in getting a mobile portrait layout with big enough touch targets.
Screen reader / aria is quite daunting at the moment, I’m trying to decide whether to implement it for this project or for the time being prioritize other stuff like getting better at React and learning TypeScript. Will definitely send you a message about this sooner or later as I think accessibility is important.
There’s still some performance-related stuff to do. I think I will spend some time over the upcoming holidays to learn about that.
Again, thank you so much for taking the time to look at my project
If you really want to make the sequencer accurate then you’ll need to do the following:
First, you will definitely need to use the Web Audio API instead of relying on <audio> tags.
Second, you’ll need to use a more precise scheduling method for playing the sequenced sounds. The gist of it is that you’ll want to use the Web Audio clock instead of the JS Clock. And you’ll also want to use a web worker to generate ticks for the sequencer.
The following article is a must read to understand this.
Switching to the Web Audio API will solve your Safari delay problems with the <audio> tag, but I did run into a few issues with iOS and the API. I don’t have time to go back and look but I do have these URLs with the code for specifically addressing these issues:
