SD player UI development

[jkeny]

I researched WiFi SD cards to use with the SD player with the intention of getting a better user interface than the small screen & push buttons on the existing SD player.

Out of the many cards that now seem to offer WiFi (It's real purpose is to allow your camera to send photos/video via WiFi to a separate WiFi connected device or cloud for storage or processing i.e video files/ pics) I chose the Flashair SD card. it's the fastest & most capable I could find plus it has a developers site for app development https://flashair-developers.com/en/disc ... rview/w04/

As you can see this is a fairly rich resource with lots of info & the card can be programmed with Javascript or Lua scripting
Libraries for Android/ios app development prototyping etc. https://flashair-developers.com/en/documents/resources/
Fairly active developers forum https://flashair-developers.com/en/support/forum/
Apps showcase https://flashair-developers.com/en/appl ... /showcase/


Anyway to get everyone started who wants to use the Flashair SD I created a shareable folder (you can read write to this drive so if you find anything useful add it here) with instructions on how to set up the card for your WiFi LAN & a rudimentary ui that allows you to see & navigate through the SD card folder & tracks - displaying cover art found in the folder & allows you to delete/upload files from the SD card over WiFi


See here for files & instructions https://docs.google.com/document/d/14LN ... sp=sharing

Flashair folder with files & SD_WLAN sub folder here https://drive.google.com/drive/folders/ ... sp=sharing

[randytsuch]

Cool stuff.

I looked at the card yesterday, and was wondering how some of this stuff would work since it's designed to add wifi to a camera.
This answers most of those questions. I'll have to get one to play with.

Randy

[jkeny]

Mentioned this before but it probably got lost on the SD player thread - here's an open-source music playback app that runs in a browser written in Javascript https://521dimensions.com/open-source/amplitudejs
You can see it in operation at that link - I like its clean interface - very modern looking

It features:
- a fairly decent display of albums/tracks/cover art
- navigation through the above
- control window that shows track playing, cover art, progress bar, next track, previous track, random play, loop play

Functions it doesn't have or should be removed:
- don't need volume control
- don't know how playlists would work?
- need to substitute different methods for the navigation functions - sending relevant IR codes, instead of local play/stop/next/back/random/loop
- currently the track info (song object) is entered as text strings in the Javascript code - need to implement the building of this info from reading of data. Here's the format of the data needed for each track:

Code: Select all

{
        "name": "Song Name 3",
        "artist": "Artist Name",
        "album": "Album Name",
        "url": "/song/url.mp3",
        "cover_art_url": "/cover/art/url.jpg",
        "made_up_key": "I'm made up completely"
    }

The only required info is the url of the song i.e folder/trackname
At the moment I don't know how this list is built - it happens at initialisation stage?
We need a way to create this list by reading the directory list of files on SD card - this would be our initialisation stage.
A simple program/OS function can do this.

There's already code for binding key events which means we can trigger certain events (code) when a particular key is pressed back/next/play/stop, etc - perfect for slotting in IR transmit code.

Nice info on all this contained here https://521dimensions.com/open-source/amplitudejs/docs

Obviously this would be easier for a Javascript programmer to tackle but it's not that difficult just requires some time to familiarise with the existing Javascript code & remove/add relevant code needed

[jkeny]

This is the ui of AmplitudeJS & the working example here https://521dimensions.com/open-source/a ... e-playlist

[Fran]

My young lad is pretty good at lua John - but will you not need something else (arduino?) to issue the instruction to the player to make the player pick up the file and send it through for playback?

[Fran]

sending a write command under the i2c section to an arduino which then can simulate the physical buttons might be a start. You can get very neat micro arduinos now with low power consumption etc. They are very robust and you'd have to really try to kill one.

[jkeny]

My young lad is pretty good at lua John - but will you not need something else (arduino?) to issue the instruction to the player to make the player pick up the file and send it through for playback?

Great, I hadn't heard of Lua before - it seems to be a big thing in IoT (internet of Things) prototyping.
We might need to use it, not sure at the mo?

There are a couple of use cases as I see it - basically broken down into what is controlling the SD player:

- the simplest? is using an Android phone for navigating the music library as in amplitudeJS above & this is sending out IR commands to the SD player as if you were using the remote control that comes with some of the units. Some phones already have IR sending units built in but IR transmitter add-ons can be bought for those that haven't. In a way this is just an intelligent remote with a nice ui which substitutes for the existing remote & screen on the SD player. The problem with this is that you need line of sight for IR & if a navigation code doesn't get through to the SD player your screen navigation will be out of synch with the SD player navigation & you end up playing the wrong song & a bit of a mess to get back to synched

- a variation (actually, this is the simplest) on this is not to rely on synched navigation between phone & SD player so much - just using the SD card like a buffer - a buffer that holds the song playlist rather than the full 32Gb library of songs & the SD card only plays songs from this folder (there aren't any other music folders). How I envisage this could work would be that as you add songs to the playlist in AmplitudeJS (from your library of songs or from on-line downloads), these tracks are sent via WiFi to the playlist folder on the SD card. Then the only IR navigation codes needed to be transmitted to the SD player are to navigate tracks within a folder rather than the complexity that having multiple folders & navigating between them would entail. This has lots of advantages - one being that many people can access the SD card via WiFi & add audio files - party mode :) I've tested this & adding files to the SD card via WiFi does not affect the audio playback.

But the disadvantages - constant writing to SD cards can wear them out? Having said that we could use a smaller & cheaper Flashair card 8GB. Big disadvantage - where is the library of audio files stored that get added to the playlist? - Not on Android phone but maybe on networked storage? (remember the SD player is/can be a device on the network). So the AmplitudeJS app would allow building a playlist by providing a nice navigation through the song library on the network & selecting songs/albums from this to include on playlist. Any additions of audio files to the playlist (or deletion of files) would get synched to the SD card via WiFi

sending a write command under the i2c section to an arduino which then can simulate the physical buttons might be a start. You can get very neat micro arduinos now with low power consumption etc. They are very robust and you'd have to really try to kill one.

Nige will be glad to read that text in bold :)

- the scenario where the PC is the control device may well need an Arduino, etc - haven't thought about this too much but it may work out simpler & easier than the above scenarios I outlined?

I always find it best to build these sort of things in stages, starting with the simplest, workable solution first rather than the fully set of use cases which are often complex.

Keep the ideas coming - this could be a worthwhile group design effort which would provide a high quality digital front end & go nicely with the high quality Nige amp you guys have acquired

[randytsuch]

sending a write command under the i2c section to an arduino which then can simulate the physical buttons might be a start. You can get very neat micro arduinos now with low power consumption etc. They are very robust and you'd have to really try to kill one.

This was along the lines I was thinking. In the other thread, I said I had built a circuit with an optocoupler and a ESP8266 based board to push a button on a remote control. You could also use a little relay.
ESP's are basically arduinos with built in wifi. Cost less then $10 for a board, and its pretty amazing what they can do at that price point. I used ESPEasy, which is kind of a simple OS for the ESP, makes it easy to control it. You can send a command to ESPEasy with any web browser in the form of
192.168.x.xxx/control?cmd=event,switch_on or similar. You can also do a pulse command to simulate a button push.

John,
I think one of the early things is to do is agree on the platform (phone type) that makes the most sense. Many people may have IOS based devices.
I'm lucky in that I have an android phone and an older ipad mini. I also just got an iphone 8 from work. So I can do either platform.
But I would guess most people don't have both. You can get cheap android tablets, so that may be the ticket. I'm pretty sure its much easier to develop and distribute apps in the android environment. Apple has to control everything lol.

Randy

[jkeny]

sending a write command under the i2c section to an arduino which then can simulate the physical buttons might be a start. You can get very neat micro arduinos now with low power consumption etc. They are very robust and you'd have to really try to kill one.

This was along the lines I was thinking. In the other thread, I said I had built a circuit with an optocoupler and a ESP8266 based board to push a button on a remote control. You could also use a little relay.
ESP's are basically arduinos with built in wifi. Cost less then $10 for a board, and its pretty amazing what they can do at that price point. I used ESPEasy, which is kind of a simple OS for the ESP, makes it easy to control it. You can send a command to ESPEasy with any web browser in the form of
192.168.x.xxx/control?cmd=event,switch_on or similar. You can also do a pulse command to simulate a button push.

To my way of thinking this is possibly adding an unnecessary layer between control device & SD player. The SD player already has an IR receiver & the ARM processor firmware already handles these button events which the IR remote control sends. I'm not sure what the Arduino will do via I2C that can't be done directly with IR codes?

John,
I think one of the early things is to do is agree on the platform (phone type) that makes the most sense. Many people may have IOS based devices.
I'm lucky in that I have an android phone and an older ipad mini. I also just got an iphone 8 from work. So I can do either platform.
But I would guess most people don't have both. You can get cheap android tablets, so that may be the ticket. I'm pretty sure its much easier to develop and distribute apps in the android environment. Apple has to control everything lol.

Randy

One of the criteria that directed me to choose AmplitudeJS was that it was written solely in JavaScript - so imminently transportable between desktop/tablet/phone. I'm not really interested in Apple - if they don't conform to this too bad, let people use PC or tablet or whatever else.

The IR transmitter is part of some phones but an easy add-on/plug-in for all phones (maybe not Apple)
List of IR enabled phones https://www.tomsguide.com/us/pictures-s ... rs.html#s1
https://en.wikipedia.org/wiki/List_of_d ... IR_blaster

IR blaster plugin example http://www.tmart.com/Universal-IR-Infr ... pYEALw_wcB

[jkeny]

sending a write command under the i2c section to an arduino which then can simulate the physical buttons might be a start. You can get very neat micro arduinos now with low power consumption etc. They are very robust and you'd have to really try to kill one.

This was along the lines I was thinking. In the other thread, I said I had built a circuit with an optocoupler and a ESP8266 based board to push a button on a remote control. You could also use a little relay.
ESP's are basically arduinos with built in wifi. Cost less then $10 for a board, and its pretty amazing what they can do at that price point. I used ESPEasy, which is kind of a simple OS for the ESP, makes it easy to control it. You can send a command to ESPEasy with any web browser in the form of
192.168.x.xxx/control?cmd=event,switch_on or similar. You can also do a pulse command to simulate a button push.

A thought occurred to me which might justify an I2C approach - you no longer need line-of-sight between controller & SD player for IR code transmission - if the Arduino is situated at the SD player & it receives WiFi signals for button presses & convert these into what the SD card expects/can handle - I think IR codes will be the easiest signalling bridging to achieve this?

But in this setup we would then have 2 Wifi connections over which we are communicating - one for SD card & one for ESP8266 - does this unduly complicate matters?

We also have to be aware of the possibility that introducing more RF comms near the SD card may inject noise into the SD card player - the Flashair WiFi doesn't seem to introduce any noise issues, however