rwpalmer / DFPlay

Enhanced Library for DFPlayer / FN-M16P. Runs as a state-machine. Fully built, partially tested, but shelved ... at least for now.
GNU General Public License v3.0
10 stars 5 forks source link

Feature request: prev #2

Closed FedericoBusero closed 6 years ago

FedericoBusero commented 6 years ago

I try to use the library in a setup with DFPlayer module, ESP8266 (or ESP32) controlled by an app. However, one feature is really missing: go to previous track.

rwpalmer commented 6 years ago

Okay, I had a back() method in my plans, but I dropped it because it adds complexity and I was not sure people would use it. I'll put it back on the list of possible enhancements for the next version.

I also dropped support for DFPlayer's random play option because it has no logic to prevent the same track from being randomly selected twice in a row. In fact, I had a track selected three times in a row during my testing with a folder that had 12 tracks. That makes me want to use a better randomization algorithm. That would be possible for media plays, but not for folder plays. Your thoughts?

FedericoBusero commented 6 years ago

The support for back() is more important than support for random. For a random mode, there seem to be 2 approaches: play all files once (and don't play anything twice) or play all files random forever.

rwpalmer commented 6 years ago

I'll take another look at the back() logic. Perhaps we can get it in this release. I started coding it once before and found the DFPlayer command behaved oddly. I wish I could remember the specifics.

Did you see my note about the logging issue that I found / fixed? You removed the blocking delay in begin(), which was a good thing, but the first few log entries were not recorded without a delay. So... I added non-blocking code to delay DFPlayer initialization. Essentially, it is the same logic used to give DFPlayer time to process one command before another command is issued. Particle now logs correctly. I'd appreciate it if you could review the code to make sure I did not create a problem on the Arduino side. If Arduino does not need this delay, perhaps we add an #ifdef SPARK. FYI: Logging is enabled in the current GitHub master code.

On Sun, Sep 2, 2018 at 3:52 AM FedericoBusero notifications@github.com wrote:

The support for back() is more important than support for random. For a random mode, there seem to be 2 approaches: play all files once (and don't play anything twice) or play all files random forever.

— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/rwpalmer/DFPlay/issues/2#issuecomment-417914901, or mute the thread https://github.com/notifications/unsubscribe-auth/AQ3oFhwUDGWZ5i6sYGcESZ5e11LanaCkks5uW5w8gaJpZM4WVzfI .

-- Rodney Palmer (rwpalmeribm@gmail.com) Tel: 218 834 6337 Cell: 218 260 2122

rwpalmer commented 6 years ago

I found some notes regarding issues I saw when when I tested DFPlayer's 0x02 command. Those issues relate to the command doing different things in different scenarios ... a trait not uncommon with DFPlayer commands.

So, I added the back() method to DFPlay.h and DFPlay.cpp. The logic only executes the 0x02 command when DFPlayer is PLAYING and when the media or a folder is being played. I believe that will produce consistent results.

I also updated playSelection.ino so we could test the command, and all looks good in my initial tests.

In the next day or two, I plan to go back to do a coder review. I'd like to see if I can eliminate redundancy in the skip() and back() methods, but I thought I'd post today's progress. I'll also change the begin() logic per your suggestion.

FedericoBusero commented 6 years ago

Works perfectly!