I've been trying to design a keyboard that can be used with the feet - something that I can play like dance dance revolution, while playing something else with my hands (mandolin), thus making me a one man band. Figuring out what a good layout would be is the first step and so far everything I've thought of either lacks useful notes, is too big to reach useful notes, or the keys are too close together. If anyone has ideas on how to do this I'd love help. (or better yet do this as I don't have must time to work on it)
hippari2 · 1m ago
Piano layout is suprisingly robust, just use a bigger size key like organists do.
Y_Y · 35m ago
Organists have been using foot-keyboards (somehow) for hundreds of years.
An organ pedalboard MIDI controller would be an off-the-shelf solution albeit expensive. You could hook it up to a drum rack in a DAW in order to remap the pedals to a useful layout.
With a foot activated MIDI controller the number of keys will always be rather limited. Therefore, I think that the virtual layout should be customized to the music you play or even for each song. E.g. you could only map notes of a certain scale and range in order to save space.
If you consider building something custom; I have found that outputting to hardware MIDI from an Arduino is delightfully simple. (The hard part on my own project is finding motivation for figuring out how to read velocity from piezos and isolating vibrations.)
coldpie · 1h ago
Have you looked at existing MIDI foot controllers? E.g. Behringer FCB1010 or Yamaha MFC10 or Roland FC-300.
hobs · 1h ago
I'd probably be thinking foot pedals and chording if I needed a lot of options.
There's a few physical keyboards out there but many are super super expensive.
maxdamantus · 3h ago
I've kind of done this, just without the actual "build" part—I instead use a Wooting computer keyboard (which has the hall effect switches you're referring to), and I've written some program to emit MIDI based on key velocity.
I've been using it very frequently for a few years, and can confirm it's quite fun to use, though I don't have much experience playing other keyboard instruments and haven't tried to learn it seriously enough to make proper use of chords etc.
The layout I use is not a regular piano layout, but a B-griff layout, as used on a bayan (Russian accordion). I made a demo site for playing with the layout (keyboard or touchscreen), but without velocity sensitivity: https://maxdamantus.gitlab.io/bayan/
The B-griff/C-griff layouts naturally fit computer keyboards, and I'd argue they're better in general than piano layouts for various reasons. There's also this cool video of someone using two Commodores for similar effect: https://youtube.com/watch?v=EBCYvoC4muc
> I've written some program to emit MIDI based on key velocity.
nice! Is the velocity code on the firmware side? Is that why it's not included on the demo site?
maxdamantus · 1h ago
No, it's on the software (computer) side. It's not in the demo site because I created that in 2019 [0] for use with a regular keyboard (since I was having issues with the software I'd previously been using for playing MIDI). I only upgraded to the Wooting keyboard in late 2021.
I've been meaning to look into adding Wooting support, just haven't got round to it. This would require either WebUSB or WebHID which are still "experimental", and I'm not sure if there will be latency issues.
The program I created for computing velocity and emitting MIDI is here [1]. When it's listening for keyboard data it does it in another thread so that it can attach fairly accurate timestamps to the key events, without being subject to pauses from Gtk or something. If there's inconsistency between the key event times and the relative timestamps, the velocity detection can be noticably off. I've noticed this in Wooting's own MIDI application [2]. Hopefully WebUSB/WebHID includes timestamps in the data, so it doesn't have to be subject to JS GC pauses.
As well as the Rust program above (possibly Linux-only, though should be easily adaptable to work on Windows/macOS), I've written an Android app that does the same thing so I can use it without a computer (though in Android you have to take control of the USB device rather than just read the HID data), but I haven't uploaded the code anywhere.
[2] https://github.com/WootingKb/wooting-analog-midi ... as well as issues with timestamp jitter, this application seems overall a bit bloated for my taste (web-based app using Tauri), and it's inconvenient since it will continue to generate MIDI when you're focused on other applications, so you'd have to close and open it (slow startup time too) each time you want to use it. their timestamp jitter occurs because the Wooting SDK (at least at the time, haven't looked at it recently) worked by running a thread that would update a shared HashMap and you would have to poll that hash map; it wasn't possible to see all updates, and there were no timestamps attached. I avoided the SDK and instead just read the data directly from the "hidraw" device.
squircle · 4h ago
First thing I did when I started playing with LLMs was vibe code a bunch of shitty virtual instruments. Roll your own, folks! Good fun.
addandsubtract · 1h ago
TIL MacBook keyboards only send 6 key presses at once.
The article link is missing the scheme so the browser will default to https. I get an error about the CNAME mismatching the Host on https for example.
Aachen · 3h ago
I'm impressed how responsive the keys are! Will definitely be checking out on desktop if I can see how the audio rendering code works (unless someone here already knows). I presume the audio synthesis API and ontouchstart but maybe there's something clever in addition like prerendering the audio samples rather than synthesising them on press
Maybe it also helps that I've got a headphone jack plugged in instead of the Bluetooth I'm used to from listening to things during the day, but even so, my touchscreen just doesn't feel this responsive normally, including in games. It's on my list of things to check the delay of, but since my phone's 960 fps camera is the equipment I use to check that, it is a bit tricky
So nothing too special here: of course preloading server data but then simply creating a new sound source during ontouchstart is enough. I guess delay in other software comes from the extra cruft they have such as big libraries (and Bluetooth, in the cases where I use that), not from any actual delay in touchscreen or audio rendering
matteason · 2h ago
I had a quick look - it's sample-based (eg organ has 4 preloaded samples, http://terpstrakeyboard.com/web-app/sounds/organ440.mp3 plus 110, 220 and 880Hz variants), and different notes are created by adjusting the playbackRate of the closest sample
It's also all just vanilla JS which probably helps keep it snappy
dist-epoch · 2h ago
responsive, but there is a small click between notes. maybe they start mid phase
Aachen · 2h ago
What browser and OS is that? I experience no clicks on Android 10 with a chromium webview-based browser
mikepurvis · 2h ago
Butter-smooth for me on Window 11 + Firefox
steveBK123 · 3h ago
Pretty cool
Cthulhu_ · 3h ago
Fun fact, anyone with a surname that ends with the -stra or -sma suffix has their origins in Frisia [0], a region in current-day Netherlands and Germany that retained their independence in the Roman era. Terpstra specifically refers to someone living on a terp, an artificial hill (because there's no hills in the Netherlands lololol) that people would live on or retreat to with the intermittent floodings.
This in turn is why the Netherlands is so big when it comes to dairy and cheese; grass was one of the few things that would grow consistently and survive the floods, cows eat grass, cheese and butter can be preserved to last through winter, etc.
And you will forever have your name mispronounced by English speakers that can’t wrap their tongues around the -sma or -stra ending.
Things like TerpSON, TerpSmith, Terp….
One time while voting the lady working there butchered my name 8 times, she literally could not get it right.
jeroenhd · 2h ago
To be fair to an English speaker reading your name from paper: some native English speakers are taught to read by recognizing words by their first letter and their shape, and skipping the word to later fill in the blanks when they don't recognize the word. The lady may have simply never been taught how to sound out unfamiliar letter combinations, and may have been trying her best to make sense of the unrecognizable mess of letters she saw in front of her.
I always felt that many native English speakers can't really parse a text properly. They seem to react to certain keywords. When the text says something they didn't expect, they often miss it or get confused.
I thought it might be a side-effect of being monolingual and hence having a less explicit understanding of language but seeing how they are taught to read, things make perfectly sense.
It is crazy of much staying power bogus science has in education. Reminds me how the idea of individual learning styles is still popular and though it lacks empirical evidence.
cwbrandsma · 1h ago
She wasn't even reading it, I was telling her my name, all she had to do was repeat it and she couldn't do it.
mrarjen · 41m ago
Can confirm, usually misunderstood too.
quink · 2h ago
> she literally could not get it right
Eh, they get their revenge. As any Australian of a certain age can tell you TelSTRA could not get it right, for any value of right, without expending an equivalent effort to moving a mountain.
docdeek · 3h ago
Very interesting. The only Terpstra I knew of before this link was Niki Terpstra, one of only three Dutch winners of both Paris-Roubaix and the Tour of Flanders.
agos · 2h ago
I also recall one Brett Terpstra, maker of Marked app and kind of a known name in the indie Mac developer scene
futura_heavy · 1h ago
I thought this was him debuting a new project.
vintermann · 2h ago
I think this is a reference to the muse Terpsichore, though?
We also have at least one -stra river in Norway, Vinstra. Don't know if anyone has it as last name, though.
thechao · 3h ago
Dijkstra!
quotz · 2h ago
Another fun fact, from Wikipedia, the name Frisia "stems from Latin Frisii, an ethnonym used for a group of ancient tribes in modern-day Northwestern Germany, possibly being a loanword of Proto-Germanic *frisaz, meaning "curly, crisp", presumably referring to the hair of the tribesmen."
In German Frisur, and in south slavic languages Фризура, means hairstyle, which is also related to the english word Frizz
I'm personally fond of this one though: https://en.wikipedia.org/wiki/Moog_Taurus
See also this classic instrument, familiar from the late great FAO Schwartz on Fifth Avenue: https://en.wikipedia.org/wiki/Walking_Piano
With a foot activated MIDI controller the number of keys will always be rather limited. Therefore, I think that the virtual layout should be customized to the music you play or even for each song. E.g. you could only map notes of a certain scale and range in order to save space.
If you consider building something custom; I have found that outputting to hardware MIDI from an Arduino is delightfully simple. (The hard part on my own project is finding motivation for figuring out how to read velocity from piezos and isolating vibrations.)
I want to try to build a hardware midi keyboard using mechanical hall effect switches like this: https://mechanicalkeyboards.com/products/wuque-studio-dash-5...
There's a few physical keyboards out there but many are super super expensive.
I've been using it very frequently for a few years, and can confirm it's quite fun to use, though I don't have much experience playing other keyboard instruments and haven't tried to learn it seriously enough to make proper use of chords etc.
Demo of me playing here, though try not to mind the messy desk and bad recording setup (one-hand, MIDI going through phone due to lack of speakers): https://drive.google.com/file/d/1qZuFlK9GybX5aP5tGi54AvTTFKd...
The layout I use is not a regular piano layout, but a B-griff layout, as used on a bayan (Russian accordion). I made a demo site for playing with the layout (keyboard or touchscreen), but without velocity sensitivity: https://maxdamantus.gitlab.io/bayan/
The B-griff/C-griff layouts naturally fit computer keyboards, and I'd argue they're better in general than piano layouts for various reasons. There's also this cool video of someone using two Commodores for similar effect: https://youtube.com/watch?v=EBCYvoC4muc
EDIT: turns out the Terpstra keyboard is also able to work using B-griff: http://terpstrakeyboard.com/web-app/keys.htm?fundamental=261...
nice! Is the velocity code on the firmware side? Is that why it's not included on the demo site?
I've been meaning to look into adding Wooting support, just haven't got round to it. This would require either WebUSB or WebHID which are still "experimental", and I'm not sure if there will be latency issues.
The program I created for computing velocity and emitting MIDI is here [1]. When it's listening for keyboard data it does it in another thread so that it can attach fairly accurate timestamps to the key events, without being subject to pauses from Gtk or something. If there's inconsistency between the key event times and the relative timestamps, the velocity detection can be noticably off. I've noticed this in Wooting's own MIDI application [2]. Hopefully WebUSB/WebHID includes timestamps in the data, so it doesn't have to be subject to JS GC pauses.
As well as the Rust program above (possibly Linux-only, though should be easily adaptable to work on Windows/macOS), I've written an Android app that does the same thing so I can use it without a computer (though in Android you have to take control of the USB device rather than just read the HID data), but I haven't uploaded the code anywhere.
[0] https://gitlab.com/Maxdamantus/bayan
[1] https://gist.github.com/Maxdamantus/c5d5133cab1ef3596ac589d2...
[2] https://github.com/WootingKb/wooting-analog-midi ... as well as issues with timestamp jitter, this application seems overall a bit bloated for my taste (web-based app using Tauri), and it's inconvenient since it will continue to generate MIDI when you're focused on other applications, so you'd have to close and open it (slow startup time too) each time you want to use it. their timestamp jitter occurs because the Wooting SDK (at least at the time, haven't looked at it recently) worked by running a thread that would update a shared HashMap and you would have to poll that hash map; it wasn't possible to see all updates, and there were no timestamps attached. I avoided the SDK and instead just read the data directly from the "hidraw" device.
https://imgur.com/a/01OYs3o
Maybe it also helps that I've got a headphone jack plugged in instead of the Bluetooth I'm used to from listening to things during the day, but even so, my touchscreen just doesn't feel this responsive normally, including in games. It's on my list of things to check the delay of, but since my phone's 960 fps camera is the equipment I use to check that, it is a bit tricky
Edit: ontouchstart calls noteOn method https://github.com/wcgbg/terpstrakeyboard/blob/03d526a0ed5c7...
This eventually calls into audio api start with 0 delay https://github.com/wcgbg/terpstrakeyboard/blob/03d526a0ed5c7...
The data to play was retrieved from the server (based on the instrument you selected) and parsed ahead of time https://github.com/wcgbg/terpstrakeyboard/blob/03d526a0ed5c7...
It loads samples at four frequencies and plays the nearest one at the appropriate rate (proportional to the target frequency) https://github.com/wcgbg/terpstrakeyboard/blob/03d526a0ed5c7...
The settings.audioContext variable is simply an instance of the web audio API as expected (with a fallback to support Safari/webkit) https://github.com/wcgbg/terpstrakeyboard/blob/03d526a0ed5c7...
This gainNode it's connecting is just about playback volume it seems https://developer.mozilla.org/en-US/docs/Web/API/BaseAudioCo... and "audioContext.destination", MDN says, you can think of as a speaker device
So nothing too special here: of course preloading server data but then simply creating a new sound source during ontouchstart is enough. I guess delay in other software comes from the extra cruft they have such as big libraries (and Bluetooth, in the cases where I use that), not from any actual delay in touchscreen or audio rendering
It's also all just vanilla JS which probably helps keep it snappy
This in turn is why the Netherlands is so big when it comes to dairy and cheese; grass was one of the few things that would grow consistently and survive the floods, cows eat grass, cheese and butter can be preserved to last through winter, etc.
[0] https://en.wikipedia.org/wiki/Frisia
Things like TerpSON, TerpSmith, Terp….
One time while voting the lady working there butchered my name 8 times, she literally could not get it right.
https://www.apmreports.org/episode/2019/08/22/whats-wrong-ho...
I always felt that many native English speakers can't really parse a text properly. They seem to react to certain keywords. When the text says something they didn't expect, they often miss it or get confused.
I thought it might be a side-effect of being monolingual and hence having a less explicit understanding of language but seeing how they are taught to read, things make perfectly sense.
It is crazy of much staying power bogus science has in education. Reminds me how the idea of individual learning styles is still popular and though it lacks empirical evidence.
Eh, they get their revenge. As any Australian of a certain age can tell you TelSTRA could not get it right, for any value of right, without expending an equivalent effort to moving a mountain.
We also have at least one -stra river in Norway, Vinstra. Don't know if anyone has it as last name, though.
In German Frisur, and in south slavic languages Фризура, means hairstyle, which is also related to the english word Frizz