Thank you for your request. It is noted and I agree that it makes a lot of sense.
We actually internally discussed a .play() function already but there is one caveat: For MOVI to be able to play audio files, the file would have to be transferred over the serial connection between the Arduino and MOVI. This connection, in order to be compatible with Arduino UNO, is currently at 9600bps. So even short audio files would probably take several minutes to upload.
In fact, the SD card already has a FAT32 partition. It is called "MOVI UPDATE" and it is meant to be used for firmware update images. We could use it for other data as well. My concern would be that putting stuff on an SD card is significantly more difficult on the user than just playing around with an Arduino IDE. So this feature would be a harsh change of philosophy and breaks the ease of use. But if there are enough people requesting, it might happen...
brettpound said Jan 24, 2016 00:21:02
I'd be happy to have an increased baud rate (I saw the other thread that says its on the cards), which would help throw sounds to it, or the ability to play WAV directly off the SD (I'm smart enough to put my static files there and not wipe other stuff out; but I agree, it makes it less "consumer" and requires a bit more nous for updates etc.)
A higher bitrate certainly helps. But keep in mind that with a perfect transmission (no errors), even at 115200bps, 1MB of wav files (which is not a lot) will take about 70 seconds to transfer. This is more waiting time than ever experienced with MOVI now. So one way or the other it's a trade off in usability. The SDCard solution is therefore more of a consideration and also because many older Arduino's really can't handle higher bitrates.
I agree that the SD Card solution is much better.
1. Less bitrate issues
2. SD card has much more space to include as many files we like, or larger files
3. If we plan carefully in the file naming convention or structure, we can just swap SD cards for different sounds.
email@example.com said Feb 09, 2016 21:55:37
3. is difficult. Taking out the SD card internally unmounts all the partitions on that card. Even if you plug the same card in again, the partitions won't get mounted again. So MOVI will stop working until reboot.
HOnestly things like the DFplayer are better for things like this, you can get like 255 tracks or maybe more by folder.
Depending on your project or the microcontroller(s) your using, there is no need to limit yourself to just a single module either. In fact they are cheaper in bulk.
There are other variant out there as well. Have to be careful though, some only play .wav files, which is fine for most people, but the *mp3* is not mp3 and requires a special program to convert and its not mp3, usually on ebay or alibaba known as U-disk or WTV020-SD-16P.
The best ones I found are the DFplayer I mentioned above and play mp3 natively without conversion junk, I think they play .wav files too, realy small form factor for projects.
My use-case for the Movi is to create a sort of "Jarvis" home-automation robot. I am using various RF and IR outputs to control devices in response to sentences (through the Movi).
There are various situations however where I want the response to my command to be a pre-recorded .wav or .mp3, or even a short clip of music. Since the movi already has an SD reader and an audio output (which I am running through a PAM8403 chip for amplification), it makes sense to be able to play(filename) through the same hardware.
I have used other hardware/libraries before for playing .wav files (the file conversion is tedious), but my concern with Movi is having to have two separate speakers and/or amplifiers.
I understand the Movi dev's concern with users messing around with the SD card content, however surely the documentation can emphasize that this is an advanced-user function, and the instructions on how to restore the Movi's SD card back to factory defaults can't be that hard?
A quick update: I am currently working on feature to record() and play() audio, so MOVI can be used a telephony voicebox and similar applications. So would this help you guys? It would require you to record the file through the microphone input line. Also, maybe I can unofficially release the documentation on how the filenaming scheme on the SD card for record() works :-)
[Last edited Mar 31, 2016 02:15:44]
dmworking247 said Mar 31, 2016 05:20:32
Any expansion to using the Movi to play additional sounds than TTS is welcome, and the ability to record a message would be an unexpected bonus!
Regarding playing audio, from my experience being able to directly name the file to be played (rather than requiring specific naming conventions other than conforming to legacy 8.3 length format) would certainly be welcome, as would the ability to play wav/mp3 files of various bitrates. I've found other implementations like TMRpcm.h libraries using generic SD card modules to be quite sensitive to the format/bitrate of the wav file.
Thanks for your quick responses and for the encouraging work that is continuing on Movi, I'm surprised there aren't already more people participating in this forum!
Maybe in some days/weeks I could talk with all people here about my MOVI - its on the way :)
Iam very pleased that SVOX Pico is addtitional to espeak - because I like the sound of espeak
Thanks for creatinbg such a device :)
[Last edited Jan 27, 2017 19:59:09]
Status:Playing with MOVI :) The Call Sign is "Joshua" :)