Randomize sounds

[blinry]

This is the one feature which would make bucklespring perfect in my eyes, I think I already suggested it some time ago over another channel.

When tapping the same key repeatedly, for example Return or Backspace, it becomes apparent that it's always the same sound. A tiny variation in pitch, or a small lowpass filter with varying cutoff frequency would probably improve this. @zevv, I think you said you tried that once, and didn't like it? Any other ideas on how to avoid the repeating sound?

[Natureshadow]

Any other ideas on how to avoid the repeating sound?

Don't repeat pressing the same key ;).

Seriously, when I hit my enter key ten times in a row, I don't hear a difference in reality.

I am strongly against introducing this bug.

[zevv]

Quoting Sebastian Morr (2017-06-16 10:07:12)

This is the one feature which would make bucklespring perfect in my eyes, I think I already suggested it some time ago over another channel.

When tapping the same key repeatedly, for example Return or Backspace, it becomes apparent that it's always the same sound. A tiny variation in pitch, or a small lowpass filter with varying cutoff frequency would probably improve this. @zevv, I think you said you tried that once, and didn't like it? Any other ideas on how to avoid the repeating sound?

IMHO the only proper solutioun would be to provide multiple samples for each key. The mechanical process pushing a bucklespring key is too complex and subtle; you won't fool your ears by simple changing things like pitch or filters.

Some keys are more prone to repeated pressing then others: space, enter, arrows, etc, so it would probably make sense to provide multiple samples only for those keys to reduce the sample set size. Buckle could then simple check for each key press if there is more then one sample avaialble, and choose one from the pool at random.

-- :wq ^X^Cy^K^X^C^C^C^C

[blinry]

This sounds like a very good solution! :) Yeah, the keys I think it's most important to do this for are space, enter, backspace, and the arrow keys. I assume even two different sounds would make it much more realistic.

[zevv]

Quoting Sebastian Morr (2017-06-17 15:32:33)

This sounds like a very good solution! :) Yeah, the keys I think it's most important to do this for are space, enter, backspace, and the arrow keys. I assume even two different sounds would make it much more realistic.

This will require me to make a complete new set of recordings though, since I'll never be able to get the exact same studio setup of the original recordings. I'll see if I can find the time and quiet to do this on the short term.

(Considering the case of the missing numpad sounds: this might be a good time to record a full-size Model M with all the keys, instead of my limited Space Saver. But I'll have to find one first, of course.)

-- :wq ^X^Cy^K^X^C^C^C^C

[vain]

Maybe I could provide raw recordings of the full keyboard soon-ish, if that's an option. Of course, that's only the easy part. :-) It's all the audio editing that takes forever ...

I suspect, though, that this task is not going to be easy at all. Like @Natureshadow said, I can hardly hear any difference (in the real world) when hitting the same key multiple times in a row. This means that all samples for one key should only differ slightly as well.

Here's some demo stuff:

https://github.com/vain/bucklespring/tree/random-demo

It contains six different samples for the backspace key (three "up" samples and three "down" samples). It randomly chooses one sample. (Don't ever use this code, it's ugly, bad and wrong. It's just a demo.)

Now, it took me four attempts to record these samples. My previous attempts resulted in samples that were indeed too different and that didn't sound natural at all. They must differ only a tiny bit. Or, maybe, you must provide like 30-50 different samples per key. You see, if one sample is too different from the others and if you only have ~3 samples, then your brain will recognize this particular sample instantly. That feels very weird.

[zevv]

Quoting vain (2017-06-17 19:17:06)

Maybe I could provide raw recordings of the full keyboard soon-ish, if that's an option. Of course, that's only the easy part. :-) It's all the audio editing that takes forever ...

That's why I don't edit: just way too much work.

In the github repo there's a crude tool (rec.c) I use for recording: it records the audio and reads keyboard events, detecting key presses and automatically cuts the audio at the right places and writes it to the appropriate file name. Recording the complete keyboard should take no more then 5 minutes.

I usually hold the mic in one hand, hovering it over the keys I'm pressing with the other, while trying to maintain a constant distance between mic and keyboard. This makes sure all keys are recorded at a a similar level, and minimizing reflections and ambient noise.

It should be trivial to change the tool to save multiple recordings of each key.

The only postprocessing I do is to amplify all samples by the same gain so that the loudest hits -3dB. IIRC that was just some sox cmdline magic.

I suspect, though, that this task is not going to be easy at all. Like @Natureshadow said, I can hardly hear any difference (in the real world) when hitting the same key multiple times in a row.

Hitting at different speed/pressure of course gives bigger differences, but the velocity should not differ too much or the result sounds strange, your brain will notice right away that the sound is just not right.

This means that all samples for one key should only differ slightly as well.

Well, the difference is noticeable, but the question is if the result is worth the effort and extra megabytes of data. I guess that a good compromise would be just keep one sample for most of the normal keys, and only ship multiple samples for keys which have a high chance of being pushed repetitively. Large keys like the space bar also tend to sound different here, depending on where I hit it.

Here's some demo stuff:

https://github.com/vain/bucklespring/tree/random-demo

It contains six different samples for the backspace key (three "up" samples and three "down" samples). It randomly chooses one sample. (Don't ever use this code, it's ugly, bad and wrong. It's just a demo.)

Your recording is almost free of noise, about 80dB dB below the signal.

Did you do postprocessing to get the noise out or do you just have good gear?

Now, it took me four attempts to record these samples.

Ha, I recognize that!

My previous attempts resulted in samples that were indeed too different and that didn't sound natural at all. They must differ only a tiny bit. Or, maybe, you must provide like 30-50 different samples per key. You see, if one sample is too different from the others and if you only have ~3 samples, then your brain will recognize this particular sample instantly. That feels very weird.

Yeah, it is very hard to hit the right spot here. I've also tried mixing samples by random levels, but that's almost impossible to do because of the fast transients in the signal, the result sounds just like reflections and phasing.

If we feel brave, we could go way deep with this: the buckle sound has some characteristics which could probably be used to generate small differences. Play the slowed down key here:

http://zevv.nl/div/slowkey.mp3

There's a pre-click, then the spring going CLACK, and finally the spring going zoingggggggg. We could isolate these three events from a number of recordings, and use those to build randomization: for each key we store a number of pre-clicks, main clacks and reverbs, and slightly alter the timing and levels.

Also, I tend to spend too much time on ridiculous projects.

-- :wq ^X^Cy^K^X^C^C^C^C

[vain]

n the github repo there's a crude tool (rec.c) I use for recording

Ah, I missed that. That's nice. :-)

Did you do postprocessing to get the noise out or do you just have good gear?

Nah, that's Audacity's noise reduction magic. I have a Samson C03U which is not bad but still yields some noise.

Well, the difference is noticeable, but the question is if the result is worth the effort and extra megabytes of data.

Alure can read FLAC or OGG/Vorbis, IIUC. I guess you didn't go for compression to get better portability? Looks like Alure itself does not have decoders for those formats but relies on external libraries. Those libs are probably ubiquitous in the GNU/Linux world, but I have no idea about Mac or even Windows.

If we feel brave, we could go way deep with this [...]

That's ... that's too much. :-)

[zevv]

Quoting vain (2017-06-18 10:43:59)

Did you do postprocessing to get the noise out or do you just have good gear?

Nah, that's Audacity's noise reduction magic. I have a Samson C03U which is not bad but still yields some noise.

I used the same mic for my first sample set, but these never were made public. The current samples were made with a Zoom H2n, I found this mic a bit more sensitive, and it has a tad less noise.

Well, the difference is noticeable, but the question is if the result is worth the effort and extra megabytes of data.

Alure can read FLAC or OGG/Vorbis, IIUC. I guess you didn't go for compression to get better portability?

No, that was out of lazyness. The whole project was never ment to go public, I just put the code on Github for a friend, but for some reason it was picked up by HN one day. I just never bothered to finish things.

I'm fine with WAV's myself, because 6MB is next to nothing in a world were people don't complain about needing 16GB for a bare OS install only.

If we feel brave, we could go way deep with this [...]

That's ... that's too much. :-)

Yes but no but yes but no but... In the end we should go for a double blind trial where people will no longer be able to tell if they are typing on the real thing or not!

-- :wq ^X^Cy^K^X^C^C^C^C

[zevv]

Quoting Dominik George (2017-06-16 10:17:27)

Any other ideas on how to avoid the repeating sound?

Don't repeat pressing the same key ;).

Seriously, when I hit my enter key ten times in a row, I don't hear a difference in reality.

I am strongly against introducing this bug.

I was as well, but after some experimentation I changed my mind: using three random samples per key results in a much more realistic sound to me.

@vain recorded a bunch of samples and adjusted the code, you can find this in the upstream 'samplesets' branch. Give it a try and let me know what you think.

-- :wq ^X^Cy^K^X^C^C^C^C