Randomized samples + new recordings of full QWERTZ layout, 3 samples for each key #56
Conversation
Postproc, read "Pk lev dB" and then apply gain:
$ sox *.wav -n stats
$ for i in *; do sox "$i" "$i.norm.wav" gain 6; mv "$i.norm.wav" "$i"; done
Couldn't record "Pause" using rec.c, so I had to do that using Audacity.
We now assume that a key either has MAX_NUM_SAMPLES samples or just one sample.
|
Quoting vain (2017-06-18 10:48:34)
I gave it a shot.
Some keys do indeed sound pretty different compared to your keyboard.
And I don't have keys for 0x5b and 0x7d.
Well, it's hard to say exactly why and how, but I must admit the result
tends to feel more natural then the single samples. As expected, the
noisy mechanical keys like the shift and the space bar benefit most from
this.
I tried to compare the resutls with MAX_NUM_SAMPLES set to 1, 2 and 3,
and it seems that having more samples is really better, because having
only 2 sounds still artificial, but with 3 it slowly starts fooling my
brain.
Your samples are quite different from the originals (a bit less highs,
mosty), but they're pretty nice and clean. My only critique is the
_terrible_ noisy space bar on your keyboard, and there's a nasty 12Khz
squeek in your 'V' samples that makes my dog bark! Both probably just
precise recordings of the actual sounds of a real Model M :)
…--
:wq
^X^Cy^K^X^C^C^C^C
|
The key has some "slack", so it always sounds as little bit "heavy"/"noisy". :/ Also tried to filter out that high-pitched noise. It's part of the real thing but quite annoying, yes.
|
Yeah, that space bar is noisy. The key cap doesn't sit tight anymore and there's quite some "wiggle room" (is that a word?), so there's a lot of vibrations going on. Can't really do anything about it, expect applying less force when pressing the key. That, however, doesn't fit the rest of the recordings. %) That 12 kHz squeek is nasty. It's present in a lot of keys. I can try to filter it out. I'll push some alternative versions. (You/I should probably rebase and squash if you decide to merge this PR, to avoid having duplicate recordings in the repo.) |
|
Quoting vain (2017-06-18 16:58:33)
Yeah, that space bar is noisy. The key cap doesn't sit tight anymore
and there's quite some "wiggle room" (is that a word?),
It two, but who cares :)
so there's a lot of vibrations going on. Can't really do anything
about it, expect applying less force when pressing the key. That,
however, doesn't fit the rest of the recordings. %)
Well, it's just the real thing, isn't it? Leave it in if it sounds like
that!
That 12 kHz squeek is nasty. It's present in a lot of keys. I can try
to filter it out.
If it weren't for my dog I should probably be pedantic and say you
should keep this in as well :)
I'll push some alternative versions. (You/I should probably rebase and
squash if you decide to merge this PR, to avoid having duplicate
recordings in the repo.)
What about if we just keep multiple sample sets? Don't replace the
original recordings, just create a new dir and let the user choose.
(for the purist we'll document the exact keyboard type with serial
number for each sample set. (Mine is a IBM Model M space saver, part
number 1391403, manufacturing date 1989-06-29 :) )
If package maintainers complain about too many WAVs, they can simply
pick and ship one.
Check my 'samplesets' branch - it's a merge of your and mine, with both
samplesets preserved. Choose which one to use with the '-p' option.
…--
:wq
^X^Cy^K^X^C^C^C^C
|
Yeah, sure, why not. :-) (I wonder if more people are going to do some recordings.)
Funny, mine was built on the same day. https://dump.uninformativ.de/v/Weemd-Bient-87/model-m-numbers.jpg |
|
Quoting vain (2017-06-18 20:15:54)
> What about if we just keep multiple sample sets? [...] Check my 'samplesets' branch
Yeah, sure, why not. :-)
(I wonder if more people are going to do some recordings.)
> for the purist we'll document the exact keyboard type with serial number for each sample set [...] Mine is a IBM Model M space saver, part number 1391403, manufacturing date 1989-06-29
Funny, mine was built on the same day.
https://dump.uninformativ.de/v/Weemd-Bient-87/model-m-numbers.jpg
Nah, my data is bogus; I read the wrong date and product number from the Git
log, which happens to be yours :)
…--
:wq
^X^Cy^K^X^C^C^C^C
|
|
Okay, I'm sorry, there's something wrong. After a while, buckle exits with this message: I guess that there are too many AL sources now. I naively assumed that we can safely use I'll look into this later today. Sorry. |
|
My solution was lazy to begin with. I think the proper way to do it
would be to pre-allocate a moderate set of sample slots, and reusing
those while loading samples on the fly, evivting the oldest sample when
a new one needs to be loaded. The OS file system cache will do the
caching for us so that the disk is not hit for each key...
Quoting vain (2017-06-19 07:58:18)
… Okay, I'm sorry, there's something wrong. After a while, buckle exits with this message:
```
AL lib: (EE) alc_cleanup: 1 device not closed
```
I guess that there are too many AL sources now. I naively assumed that we can safely use `512 * 3` of them.
I'll look into this later today. Sorry.
--
You are receiving this because you commented.
Reply to this email directly or view it on GitHub:
#56 (comment)
--
:wq
^X^Cy^K^X^C^C^C^C
|
|
You're probably right. It appears the maximum number of sources depends on the implementation/platform. This thread gives some ideas on how to "query" it. It probably boils down to "try allocating sources until it fails". Or maybe just limit the number to about 8, because it's rather unlikely that a person hits more than 8 keys at once while typing normally. :-) (Both options feel a little weird, if you ask me. There has got to be a way to properly query that value.) |
|
Quoting vain (2017-06-19 20:11:57)
Or maybe just limit the number to about 8, because it's rather
unlikely that a person hits more than 8 keys at once while typing
normally. :-)
Right, but that requires a bit more logic to know which samples are done
and which are still playing to know which slots can be reused.
(Both options feel a little weird, if you ask me. There *has got to be* a way to properly query that value.)
I'll have to look that up, in OpenGL there is usually some #define with
a max value for the implementation, but not sure how this works in
OpenAL
…--
:wq
^X^Cy^K^X^C^C^C^C
|
|
Quoting vain (2017-06-19 20:11:57)
Don't know if you're working on the same thing, but I got this working
in my 'samplesets' branch.
Or maybe just limit the number to about 8, because it's rather
unlikely that a person hits more than 8 keys at once while typing
normally. :-)
8 was not enough for me. You don't necessarily have to press them at the
same time, but the first one has to stop playing before you reuse it.
there's now 32 sources allocated at startup, which are reused round
robin.
…--
:wq
^X^Cy^K^X^C^C^C^C
|
|
No, I wasn't working on it yet, you beat me to it. :-) Your recent commit works fine for me, except for one thing: I think a source should always be stopped before rebinding it. diff --git a/main.c b/main.c
index a908fb5..8b569bc 100644
--- a/main.c
+++ b/main.c
@@ -376,6 +376,7 @@ int play(int code, int press)
}
/* Find a free source for the buffer. For now we just use round robin */
+ alSourceStop(src[src_idx]);
double x = find_key_loc(code);
alSource3f(src[src_idx], AL_POSITION, -x, 0, (100 - opt_stereo_width) / 100.0);This isn't required when typing normally, but some password managers generate artificial key events to enter passwords. Let's say the password is 64 characters in length, then there will be 64 events delivered to buckle almost at the same time. Buckle then aborts with the following message if the source has not been stopped: |
|
Quoting vain (2017-06-20 19:51:09)
Your recent commit works fine for me, except for one thing: I think a
source should always be stopped before rebinding it.
True
This isn't required when typing normally, but some password managers
generate artificial key events to enter passwords. Let's say the
password is 64 characters in length, then there will be 64 events
delivered to buckle almost at the same time.
Fair enough, fix applied.
So, this all feels pretty sane as it is. I wasn't too fond of your new
samples first, probably just because I was used to the original, but
I've grown to like them: no reason for me now to make new recordings,
let's just keep those.
I'm all set to merge the whole back to master and see if there's any
feedback from other people. If all is ok, I'll tag a 1.5 version in a
few days.
…--
:wq
^X^Cy^K^X^C^C^C^C
|
|
I'd love to see this merged! :) |
|
Yeah, me too, actually.
We asked for feedback from users, but got no responses at all. Maybe we
should just merge and then wait for complaints of package maintainers,
instead of just letting it just sit and get to waste...
Quoting Sebastian Morr (2017-10-19 17:18:57)
… I'd love to see this merged! :)
--
You are receiving this because you commented.
Reply to this email directly or view it on GitHub:
#56 (comment)
--
:wq
^X^Cy^K^X^C^C^C^C
|
|
To give you some feedback: I liked the new samples. I wouldn't say they are objectively better than the old ones, tough; it's a matter of taste. Personally, I prefer the old ones, even when taking into account the sample randomization.
I'd include both sets of samples, letting the user decide which to use.
It'd be fun if in the future people submitted patches with samples from all sorts of old keyboards ;) By the way, @vain appears to have abandoned this account, so I wouldn't expect to be hearing back from them, if not emailing them directly. |
|
Also, before merging this, remember to add the missing samples:
When I press the left win key I get a |
I gave it a shot.
Some keys do indeed sound pretty different compared to your keyboard. And I don't have keys for 0x5b and 0x7d.
CC #54