Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Feature #30

Open
wants to merge 4 commits into
base: master
Choose a base branch
from
Open

Feature #30

wants to merge 4 commits into from

Conversation

superblowball
Copy link

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.

Copy link
Owner

@porridge porridge left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thank you for this contribution, this is really awesome, I'm sure my youngest one will appreciate the nice animals :-)
It would be great if you could make a few changes:

  • please make sure the checks pass
  • please try to ensure that individual commits are well-formed, i.e. please squash the last cleanup one with the first one
  • please address the comments inline

I also noticed that images no longer display for me when I run the program without installation, from the current directory. How about yourself, does it still work?

I'm also wondering why you decided to get rid of the old images and sounds? Some of them I do not miss, but there were some which perhaps could make sense when showing letters for example?

Finally, we need to take care of some legal considerations to make it possible to distribute the new files in Debian. Please briefly describe (in the commit message or PR description/comment is fine) who is the copyright holder for each of them, what is the time of their initial creation, and what is the license.

if event.type == KEYDOWN and self.args.deterministic_sounds:
self.sounds[event.key % len(self.sounds)].play()
if event.type == pygame.KEYDOWN:
# show self.images
Copy link
Owner

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Please remove this comment, it makes even less sense now.

@@ -0,0 +1,4 @@
[Dolphin]
Copy link
Owner

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

What is this file for? I don't think bambam uses it? In that case please add it to .gitignore and remove from PR.

@porridge
Copy link
Owner

porridge commented Oct 5, 2022

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
Copy link

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
Copy link
Owner

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
Copy link

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
Copy link
Owner

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
Copy link

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

@porridge
Copy link
Owner

@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
Copy link

@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
Copy link
Owner

@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
Copy link

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
Copy link
Owner

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

3 participants