Description
Right now on V2 these functions can take a tuple for the pin
argument:
audio.play(..., pin=(pin_speaker, pin0))
music.play(..., pin=(pin_speaker, pin0))
speech.say(..., pin=(pin_speaker, pin0))
This can be a bit confusing because:
- Right now we cannot have any two pins.
- So in V2
pin=(pin0, pin1)
would not work
- So in V2
- In v1
pin=(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 v2
- This could be confused with the return pin feature in audio and speech for v1
- In a less important note, is harder to document methods that have different signatures in V1 vs V2
- The
audio
andmusic
stop functions also take the pin argument, this should probably mirror the same format asplay
, which it currently doesn't do- This could be updated in MicroPython, is CODAL ready for disconnecting pins from the mixer at any point?
Since we can control sound output on the speaker via pin_speaker.enable()
and pin_speaker.disable()
, we could revert the pin
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 become microbit.speaker.disable()
, and to only use the speaker, the user could do audio.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?