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

Clean-up and add fixed welcome jingle #80

Open
wants to merge 10 commits into
base: DEV
Choose a base branch
from

Conversation

christianix
Copy link

I've cleaned-up code a bit and added a fixed welcome jingle on start-up. Maybe you are interested in these changes.

First load settings from flash, than use volume setting.
This welcome jingle helps:

a. verify MP3 decode, main chip and speakers are connected correctly
b. tell users when they can start working with Tonuino
Names (macro defines) increase readability of code.
- remove unused parameter from voiceMenu()
- remove commented-out source lines
- remove unused FeedbackModifier
- remove config migration function (legacy)
- used memcmp() instead of home-brewn comparison function checkTwo()
- define only once
- use memcmp() to check cookie value
- use memcpy() to assigned cookie value
currentTrack = currentTrack + 1;
mp3.playFolderTrack(myFolder->folder, currentTrack);
return false;
}
Copy link

Choose a reason for hiding this comment

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

Did you change this on purpose? As I understand it, the idea behind "KindergardenMode" is that whatever the kids do, they cannot change a track while it's playing. They can only queue new tracks to be played after the current one has finished. That's why the nextButton and previousButton are locked in this mode. This is probably to prevent Wikipedia-style "edit wars" in Kindergarden. :)

I have never used KindergardenMode myself, but I believe the change to this button function should probably be reverted. Same for handlePreviousButton below.

Copy link
Author

Choose a reason for hiding this comment

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

In the context I've committed the change, it was an accident. But really, I don't like the Modifiers. I'll remove them in by Repo soon. The way Modifiers are implemented is the right approach - for Modes. But there is no reason for two mechanisms which basically do the same.

@mintar
Copy link

mintar commented Jan 5, 2021

I've just reviewed this PR, and I'm impressed. I'm definitely using this in my private fork, and I think it should be merged here, too. I'm not affiliated with this project at all however, so this is just my private opinion. :)

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.

2 participants