Feature

[superblowball]

The -d (deterministic sound) parameter functionality has been changed. I replaced the image and sound arrays to dictionaries with filenames (without extensions) as keys. Matching filenames are played simultaneously.

[porridge]

FWIW, I seem to have found the source for one of the images, and it is in public domain, so perfectly acceptable. Unfortunately I do not have the time to track down all the other files, but I would gladly review any such contribution.

[wolftune]

Seems to me this PR should be split up between the code changes that allow more control over pairing of deterministic sounds and images (and actually, what about deterministic pairing while retaining random non-deterministic keys?) and the new image files.

Images and sounds are a separate type of thing than the code changes that support different functions.

[porridge]

Seems to me this PR should be split up between the code changes that allow more control over pairing of deterministic sounds and images [...] and the new image files.

I agree, good point. There is some more great rationale in your group post.

what about deterministic pairing while retaining random non-deterministic keys?

Can you please clarify what exactly you mean here @wolftune ?

[wolftune]

what about deterministic pairing while retaining random non-deterministic keys?

Can you please clarify what exactly you mean here @wolftune ?

I mean reliably play the same-named sounds with images (like sheep sound with sheep image) without deterministically setting which key goes with which image.

Obviously for letters, it would have to be deterministic (and actually sounds for letters deterministically would need a different code because what's being matched isn't images but characters)

[porridge]

I gave this some thought and came up with the following design draft.

For each keypress event, a sound and a picture is selected by consulting a configurable (for example defined in a config file) mapping of keycodes or unicode code points (individual or their classes) to an artifact selection policy.

There would be a few generic policies:

• single: given named file; if not found can fall back to another policy
• random: pick a random from a given pool of (possibly all) files
• shuffled: on first key press, map key to a file from a given pool (possibly all) at random and stick to it

A few sound-specific selection policies:

• silence
• deterministic (legacy): idx = files[event.key % len(files)]
• match picture: sound named the same as selected picture; fallback to different policy if picture tries the same

A few image-specific selection policies:

• no picture
• font: font representation of the key; fallback: another policy
• match sound: picture named same as selected sound; fallback to different policy if sound tries the same

Using the above, it should be possible to implement at least the following use cases:

• legacy:

  • picture: map alphanumerics to font; fallback to random
  • sound: no specific mapping, fallback to silence, random or deterministic_sounds, based on command line flag

• animals and sounds they make:

  • picture: no specific mapping, fallback to shuffled
  • sound: match picture; fallback to silence (unused)

• toy piano:

  • picture: no specific mapping; fallback to none or shuffled
  • sound: maps specific keys to specific single sound files; fallback to silence

• alphabet learning:

  • picture: map alphanumerics to font; fallback to random
  • sound: maps specific keys to specific single sound files; fallback to random

Please let me know what you think @wolftune .

[wolftune]

Sounds good to me, I haven't thought it through that deeply…

[porridge]

@wolftune it took much longer than anticipated, but I finally pushed experimental support for extensions. Please give it a spin and let me know what you think.

[wolftune]

@porridge wow, neat! The updated README has a minor error where in the mention of which zip to download, "or" is included in the ticked codeblock. More significantly, it mentions the 1.3 release, but that isn't showing in the releases yet. I've not built the code before. If a functional binary is easily enough available, I'm happy to try it sometime soon.

[porridge]

@porridge wow, neat! The updated README has a minor error where in the mention of which zip to download, "or" is included in the ticked codeblock.

Thanks, I'll take a look.

More significantly, it mentions the 1.3 release, but that isn't showing in the releases yet. I've not built the code before.

Yes, it's prepared but I haven't cut it yet.

If a functional binary is easily enough available, I'm happy to try it sometime soon.

Please try https://github.com/porridge/bambam/archive/refs/heads/master.zip

[wolftune]

I'm not figuring out how to run it from that zip. I tried the various .desktop files and didn't get it to work. Maybe lacking the --wayland-ok function? using ./ in terminal didn't work either.

[porridge]

I'm not figuring out how to run it from that zip. I tried the various .desktop files and didn't get it to work. Maybe lacking the --wayland-ok function? using ./ in terminal didn't work either.

Please do open an issue and provide any output you got in the terminal, and how it failed.