-
Notifications
You must be signed in to change notification settings - Fork 25
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
Should we remove the addition of tuples in music/audio play() pin argument? #30
Comments
@jaustin , @microbit-giles, @microbit-mark and I had a chat about this today and one thing that became clear is that it makes sense to move the An important idea we discussed was to change the concept of the speaker being controlled by a pin and think of it as being a built-in feature:
Another thing to take in consideration is that any issues with the pin argument can be addressed in the documentation, but:
Current implementation of the
Suggested change to the
Common uses cases:
|
Does |
Is there a function to configure the default pin when no pin is specified? |
Yes, pin_speaker still exists, but without the enable/disable, and now there would be a speaker.enable() and speaker.disable().
No, the default is for v1 compatibility, so if the users want to use a different pin they need to use the pin argument, as with V1. |
Discussed #30 (comment) in standup and we should go with on/off for consistency and for translation. For note, MakeCode also uses true/false for the display |
I probably wouldn't change a MakeCode block that's been available for years. For the MicroPython speaker API, we should mirror display with |
I think the whole 'led enable' block name would need changing to make sense, which feels like a breaking change to me. It would need to be something like 'set display on/off'. I think we should leave the MakeCode block as it is. |
The |
Audio, music and speech output are now changed to accept only a single pin (or None) as the argument to pin output selection. See 0c4287c |
We will not implement is_on() as there is little benefit and it's better to keep things lean and simple. The stop() functionality still to be covered in #31 and how it interfaces with the pin modes and sound coming from other modules in issue #50. |
Right now on V2 these functions can take a tuple for the
pin
argument:This can be a bit confusing because:
pin=(pin0, pin1)
would not workpin=(pin0, pin1)
will throw an error, even though both pins are available theremusic.play(music.PYTHON, pin=(pin_0,))
will also throw an error in v1 and work on v2audio
andmusic
stop functions also take the pin argument, this should probably mirror the same format asplay
, which it currently doesn't doSince we can control sound output on the speaker via
pin_speaker.enable()
andpin_speaker.disable()
, we could revert thepin
argument to be the same as V1, and then document that music, speech and audio always route the sound to the built-in speaker as well and how that can be enabled/disabled.If the user only wanted sound via the speaker, and not any other pin, they can still do
audio.play(..., pin=pin_speaker)
.Alternatively,
microbit.pin_speaker.disable()
could becomemicrobit.speaker.disable()
, and to only use the speaker, the user could doaudio.play(..., pin=None)
. In this case we would be removing the idea of the speaker being a pin, and becomes something that plays sounds, and then the pin argument is the "additional place to route the sound output into".Thoughts?
The text was updated successfully, but these errors were encountered: