Randomized samples + new recordings of full QWERTZ layout, 3 samples for each key

[vain]

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

[zevv]

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

[vain]

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.)

[zevv]

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

[vain]

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

[zevv]

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

[vain]

Okay, I'm sorry, there's something wrong. After a while, buckle exits with this message:

source generation
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.

[zevv]

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: https://github.com/zevv/bucklespring/pull/56#issuecomment-309345787

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

[vain]

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.)

[zevv]

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

[zevv]

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

[vain]

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:

OpenAL error at buffer binding
AL lib: (EE) alc_cleanup: 1 device not closed

[zevv]

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

[blinry]

I'd love to see this merged! :)

[zevv]

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: https://github.com/zevv/bucklespring/pull/56#issuecomment-337941591

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

[returnDanilo]

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.

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.

I'd include both sets of samples, letting the user decide which to use.

(I wonder if more people are going to do some recordings.)

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.

[returnDanilo]

Also, before merging this, remember to add the missing samples:

And I don't have keys for 0x5b and 0x7d.

When I press the left win key I get a Failed to open file error.