That's nice! Glad I own both products (VGA Graphics Sheild and the Quick Media Player). I've been busy this week but will look at it over the weekend for sure! Great job Rayman.
@tdg8934 How are you getting on with the QMP? I've been trying to extract the touchscreen code from the paint program but i'm running into obstacles have you managed to get the touchscreen to work with any of your applications?
I'm trying to marry the touchscreen control to the Wav player at the moment in order to use the buttons on the side to control the tracks and volume.
skylight, I'll try to make a wav player demo with touch buttons on the screen.
Since I'm calling this a "Media Player", seems that should be available...
Here's a start anyway... It shows a bitmap and defines 1 button, the play button.
(you need to put PlayBar.bmp on your uSD card).
It waits for you to hit the play button.
Then, it plays all the .wav files on the uSD card.
Looks Impressive so far Rayman thanks for this, I'll study the code as I will like to adapt it like I did the old code to show the artist and track playing
Edit: Just tried it with the SD card I used before with the old player which contains an album consisting of 8 tracks named Test1.wav to Test8.wav
and noticed in the PST that the tracks are listed in a random order 1,3,8,2,5,6,7,4 , I'm presuming that the playlist portion of the code looks at address locations on the SD card in order?
This will take some thinking as the previous code allowed me to order the tracks in acending order with the PlayWav method call and I was using an indexing system to identify files to corresponding tracks as the Wav Header doesn't contain that info,I will have to think of a different method of identifying the tracks.
Also noticed a problem with the player only playing the first three files, it stops at the end of the third file no matter what that file is (tried different wav files), Where the previous two files play to the end and PST shows the "Played time(s)" as changing from the track size to -5 then the next track plays, the third track plays through but freezes at the end with PST showing the original "Played time(s)" and doesn't change to -5 and play the next track.
Apart from that it's looking good for starters, great work Rayman!
skylight, thanks for testing. Looks like there's a ways to go...
Yes, right now it just takes the files in the order they are given from the SD driver, without sorting. I'll think about how we might sort them...
Another approach would be to combine all the music files into one tarball, .tar file. Then, they could have directories, long file names, and (hopefully) the right order.
No idea why it only plays 3 files, I'll look into that.
Regarding the sorting of files perhaps a separate object could look at the files present, then allow you to enter artist name then associate each filename to a typed in track name.
this would save the associations that the main object can then play the files showing artist and what track is playing?
Alternately I'm not sure how long a filename fsrw allows for and what characters would be allowed in the filename to seperate artist,tracks other info etc that could be deciphered by the program looking for the terminating characters as it loads them?
Another thing I noticed reading the code, should the background colour be dark blue with a yellow font as it's showing a black font(nice font) on a white background?
Trying my best to understand the code with new found knowledge purged from the PE Kit Labs (great reading for beginners like myself) but get lost here and there
Edit: Sorted out the problem with the colours The comments didn't reflect the RGB values in the foregroundcolor and backgroundcolor variables
FSRW only allows filenames in 8.3 format (like old versions of DOS). This is fine for a lot of things, but not so great for
a library of music... Ideally, you'd want the filename to be the name of the song and the folder name to be the name of the albumn/artist...
That's ard to do with just 8 characters...
I'm thinking the tarball approach solves a lot of these problems. And, hopefully, the songs can be sorted on the PC side, saving the Prop some work...
The free Windows utility 7-zip can create the .tar files that can contain folders of .wav files.
Maybe we can decide on a structure where the first folder name is artist and sub-folders are albumns containing the .wav files...
Changed background colour to a light green, played with showing title of album(ignore what's shown this will later show the correct artist and album title)
Edited the play button control to lose the rectangle that shows when changing background colour and the play button glows green(may change this to a pause button for future?) when playing now (2 bmp files added, PlayBG is background changed file and PlayBP is the playbutton pressed file.
If you get the chance have a look at it Rayman as I'm sure I could tidy up the commented changes I made to the code, I copied and pasted what I thought was needed(2 lines) but maybe I could have used less?
Note: Still has playing three files problem from above post
Also answered my question about file length accepted by fsrw as had to rename bmp files to shorter names
What would be nice is to design a background bmp that frames the player window and controls, a nice enhancement for the future methinks
Tried it real quick and looks good here.
You know, the 3-file thing may be due to running out of cogs... Maybe something is wrong with the cog termination...
We're using 1 cog for lcd, 1 for sd, 1 for serial, 1 for Spin, leaving 4 free cogs. So, actually maybe that's not it...
I'll try to look into this tonight...
Actually, can you try adding a new variable, k, to PlayWav and then change the cognew line to this:
k:=COGNEW(@ASMWAV,@parameter1)
Then, at the end of the function, just before "return" add in this line:
cogstop k
That should tell us for sure if that is the problem...
Actually, can you try adding a new variable, k, to PlayWav and then change the cognew line to this:
k:=COGNEW(@ASMWAV,@parameter1)
Then, at the end of the function, just before "return" add in this line:
cogstop k
That should tell us for sure if that is the problem...
Made changes as above except cogstop k had to be cogstop(k) , no change still stops after the third file has played through then freezes PST shows played time(s) of file and doesn't change to -5
FSRW only allows filenames in 8.3 format (like old versions of DOS). This is fine for a lot of things, but not so great for
a library of music... Ideally, you'd want the filename to be the name of the song and the folder name to be the name of the albumn/artist...
That's ard to do with just 8 characters...
I'm thinking the tarball approach solves a lot of these problems. And, hopefully, the songs can be sorted on the PC side, saving the Prop some work...
The free Windows utility 7-zip can create the .tar files that can contain folders of .wav files.
Maybe we can decide on a structure where the first folder name is artist and sub-folders are albumns containing the .wav files...
Missed this post of yours, If the tar file route then the structure you suggest sounds fine for sorting out the artist and album names but track names may be an obstacle?
Ok, I'll look into coding up M3U. I think Windows Media Player can export playlists as M3U files...
Still can't find the trouble with yours stopping after 3 files... Mine's been playing for ~2 hours the same 7 clips over and over...
Maybe you can zip and email me 4 songs so that I can reproduce this?
Didn't know about the M3U format, it looks promising, so I adapted the code some more to look for the presence of an M3U file and aknowledge this to PST, Next task will be to read text from the file I'll have a go at that but it may be beyond my ability at present.
Still can't find the trouble with yours stopping after 3 files... Mine's been playing for ~2 hours the same 7 clips over and over... Maybe you can zip and email me 4 songs so that I can reproduce this?
I wonder if it's the length of the samples in this newly structured wavplayer? They all play ok in the original Wav player but that opened and then closed a cog each time a wav file played, This one leaves the cog running all the way through doesn't it?, So maybe that's the problem? Or something to do with the buffers, didn't they clear after each played file on the old player and maybe not so in this version?
According to PST:
File 1 #Samples: 16312296
Playtime (s) = 369
File 2 #Samples: 11583600
Playtime (s) = 262
File 3 #Samples: 16687440
Playtime (s) = 378 Freezes after playing this
Strangely though as mentioned before I changed the third file from a previous one that froze exactly the same after playing and that was a 5min+ file
I can send you the songs if you like, not sure if you'll appreciate the music though unless you like progressive rock from 1972
where should I send them?
On another note it crossed my mind as to how much current the wav player draws from the USB port as it's powering both boards and several quickstart leds and the display backlight, USB I think can supply a max of 500ma? Just wondering if it may be a good thing to get a powered hub?
Now the touchscreen is incorporated into the wav player at least the backlight can be turned on and off (not sure about the quickstart leds as I believe they are to do with driving the screen, is that correct?), I may include that into the code for when it's used on a battery supply.
Edit re touchscreen backlight on off: Noticed the I2C driver doesn't run in it's own cog, The touchscreen comms would need to be in a repeat loop to constantly scan for input at the same time the PlayWav routine/s are doing their stuff, should a cognew command be put in the I2C driver object or is that not the best place to put it? Trouble is a lot of code associated with the touchscreen is in the main program, Just wondering if all the touchscreen code and calls to the I2C driver should be in a seperate touchscreen object running under it's own cog?
If a parent object "Touchscreen" runs in it's own cog and calls "I2C" as a child from it's object list, would the call interrupt the wav playing? ie does "I2C" run in the cog that "Touchscreen" started? or will "Touchscreen" have to include all the "I2C" code in one parent and lose the call to the child?
My understanding is all following code after the cognew including calls to other objects is run in the new cog until the parent runs out of code to execute, then that cog shuts down, Is that correct?
It must be the file length... Mine are all short clips... I'll try with some longer files here and see what happens.
If I can't find the problem, please email your 4 files to ray@rayslogic.com so we can sort this out...
Ok, I just tested a full CD of music that was ripped with Windows Media Player into .wav and put on the uSD card. It's on song 9 of 10 right now with no signs of trouble.
One of the songs has 12663756 samples, close to yours.
So, I'm thinking it's something special with your hardware...
Just emailed a link to the zip file containing the first 4 tracks on Google Drive, Don't expect CD quality as the tracks were recorded off a 30+ year old vinyl album with crackles and pops between tracks Just seen your post above, One thing it does play all the tracks with the old player so wouldn't a hardware fault have shown up then?
Re Hardware issues my quickstart version is 40000 Rev A I do believe that when I bought it that Parallax said all boards sold from then had the 64K eeprom I bought it after this message so should have been sent the 64K version I wonder if there's a way of checking through the prop tool if this is the case and whether in my case an earlier board was sent to me? Would different size eeproms make any difference to the code in the latest wav player?
I've tried all sorts of things like changing the USB port and reloading to eeprom but it always gets stuck at the same place, I'll reload the original and try that again in case anything may have changed?
Edit: Just checked in the prop tool and the memory locations go up to 7FFF which looks like only a 32K version, I was robbed!
I've got another quickstart coming from PropellerPowered.com so hopefully it's the 64K version and I can do a comparison with the Wav Player
Do you have another uSD card? Or maybe you could take all the files off of this one and put back just the .wav files and the .bmp files.
Do you have a lot of other things on the uSD card?...
Maybe we could try re "mount" ing the uSD card between songs. Seems like it's getting stuck trying to open the next file.
Or maybe there's something in the filenames that is messing it up...
Can you try renaming your songs test1.wav, test2.wav, etc...
Also, maybe try with multiple copies of just one .wav file...
Just finished playing the album using the old wavplayer to check if there was a hardware issue since trying the latest player, all tracks played ok finishing with the "Play wav complete" message.
Maybe we could try re "mount" ing the uSD card between songs. Seems like it's getting stuck trying to open the next file.
I think that might be the solution as the old player did that
Or maybe there's something in the filenames that is messing it up... Can you try renaming your songs test1.wav, test2.wav, etc...
the files are already named test1.wav ..test2.wav..etc
Did you see the post above about eeprom size, could I have memory problems compared to your quickstart using the new player code?
Ok, please try remounting for each file... Maybe that's it, but don't understand why...
Eeprom size is not a factor here. I think it's something with the uSD card interface, but not sure what...
Tried placing the mount SD portion of code elsewhere after the PlayWav call but that just froze after the first track, been snipping code here and there and placing ser. calls to see what's going on around the code but frustratingly am no closer to solving the problem, I just don't understand a lot of the code, There are a lot of to's and fro's that end up in the Pasm code which at the moment is gobbledegook to me. In desperation I even substituted the entire PlayWav section with the old one, just kept getting error messages. Too tired to mess around with the code again tonight so will have a go tomorrow.
Tried you files on two different Quickstarts and can't reproduce the problem...
Starting to run low on ideas, but here's two things to think about:
1. Maybe there's something different in the way your card is formatted... Can you try reformatting the uSD and reloading the files?
2. There's a potential problem with starting and stopping the frsw driver in that when the driver is not running, there are no pullups
on the control lines and there's a chance that could driver the uSD card into a bad state.
Re-mounting the uSD every time should fix this. I'll try to add this to the code for you to try. This might be it, since as you said,
the other version didn't do this.
If it's #2, I do have some ideas about keeping the driver running all the time... That should also prevent the pops whenever a new song starts... Will take some time to develop that though...
2. There's a potential problem with starting and stopping the frsw driver in that when the driver is not running, there are no pullups on the control lines and there's a chance that could driver the uSD card into a bad state.
Re-mounting the uSD every time should fix this. I'll try to add this to the code for you to try. This might be it, since as you said,
the other version didn't do this.
Ray, would a few physical pull-up resistors be on order to prevent potential problems here?
Actually, I think I was up too late when I wrote that because it doesn't make any sense...
Only the wav playing cog is started and stopped, not FSRW... So, we never lose control of the CS signal on uSD card...
Still if the old player worked for skylight maybe this re-mounting between songs will fix whatever is going wrong there...
Thanks Rayman, trying version 2a now, just as a matter of interest did you test with your version or the adapted version I created? Just wondering if the problem was created by my additions to the code?
Edit : Ignore that, I remember it was playing up before I did the additions.
Just played using V.2a, and unfortunately no change, exactly the same problem freezes after the third track
never gets to execute this bit of code.
ser.str(string("Played time (s) = "))
ser.dec((cnt-PlayTime)/clkfreq)
ser.tx(13)
I'll try what you said about reformatting the uSD card, though I still wonder why it plays ok with the original player?
What option for formatting should be used FAT or FAT32?
PROBLEM SOLVED!!!!! Reformatted the uSD card as you suggested reloaded the files and voila it plays brilliantly and the audio quality is far superior, I was getting some mushiness now and again.
Even plays perfectly with my adapted code with the glowing play button so well pleased, Sorry to have put you to so much trouble when it was all down to a corrupted SD, what was throwing me was it still played ok with the old player??
Now we can move on!
Shall we stay with v2 as v2a with the remounting is probably not needed now.
I'm next going to look at creating a pause button in place of the green glowing play button
This is really strange, and a bit difficult to troubleshoot...
Are you still powered by battery? Can you try with USB cable for power?
I think you can format the uSD in just whatever Windows picks as default (just don't do NTFS).
Or, maybe you can try swapping the names between 1&2 and 3&4?
Seems like the trouble is with tracks 3 or 4. Maybe with the names swapped, the problem will stay with the files and not the file names or position?
Comments
Tim
I'm trying to marry the touchscreen control to the Wav player at the moment in order to use the buttons on the side to control the tracks and volume.
Since I'm calling this a "Media Player", seems that should be available...
(you need to put PlayBar.bmp on your uSD card).
It waits for you to hit the play button.
Then, it plays all the .wav files on the uSD card.
QMP_WavPlayer2 - Archive [Date 2013.03.17 Time 20.56].zip
Later we can add volume control and pause and skip and things like that...
Edit: Just tried it with the SD card I used before with the old player which contains an album consisting of 8 tracks named Test1.wav to Test8.wav
and noticed in the PST that the tracks are listed in a random order 1,3,8,2,5,6,7,4 , I'm presuming that the playlist portion of the code looks at address locations on the SD card in order?
This will take some thinking as the previous code allowed me to order the tracks in acending order with the PlayWav method call and I was using an indexing system to identify files to corresponding tracks as the Wav Header doesn't contain that info,I will have to think of a different method of identifying the tracks.
Also noticed a problem with the player only playing the first three files, it stops at the end of the third file no matter what that file is (tried different wav files), Where the previous two files play to the end and PST shows the "Played time(s)" as changing from the track size to -5 then the next track plays, the third track plays through but freezes at the end with PST showing the original "Played time(s)" and doesn't change to -5 and play the next track.
Apart from that it's looking good for starters, great work Rayman!
Yes, right now it just takes the files in the order they are given from the SD driver, without sorting. I'll think about how we might sort them...
Another approach would be to combine all the music files into one tarball, .tar file. Then, they could have directories, long file names, and (hopefully) the right order.
No idea why it only plays 3 files, I'll look into that.
this would save the associations that the main object can then play the files showing artist and what track is playing?
Alternately I'm not sure how long a filename fsrw allows for and what characters would be allowed in the filename to seperate artist,tracks other info etc that could be deciphered by the program looking for the terminating characters as it loads them?
Another thing I noticed reading the code, should the background colour be dark blue with a yellow font as it's showing a black font(nice font) on a white background?
Trying my best to understand the code with new found knowledge purged from the PE Kit Labs (great reading for beginners like myself) but get lost here and there
Edit: Sorted out the problem with the colours The comments didn't reflect the RGB values in the foregroundcolor and backgroundcolor variables
a library of music... Ideally, you'd want the filename to be the name of the song and the folder name to be the name of the albumn/artist...
That's ard to do with just 8 characters...
I'm thinking the tarball approach solves a lot of these problems. And, hopefully, the songs can be sorted on the PC side, saving the Prop some work...
The free Windows utility 7-zip can create the .tar files that can contain folders of .wav files.
Maybe we can decide on a structure where the first folder name is artist and sub-folders are albumns containing the .wav files...
Changed background colour to a light green, played with showing title of album(ignore what's shown this will later show the correct artist and album title)
Edited the play button control to lose the rectangle that shows when changing background colour and the play button glows green(may change this to a pause button for future?) when playing now (2 bmp files added, PlayBG is background changed file and PlayBP is the playbutton pressed file.
If you get the chance have a look at it Rayman as I'm sure I could tidy up the commented changes I made to the code, I copied and pasted what I thought was needed(2 lines) but maybe I could have used less?
Note: Still has playing three files problem from above post
Also answered my question about file length accepted by fsrw as had to rename bmp files to shorter names
What would be nice is to design a background bmp that frames the player window and controls, a nice enhancement for the future methinks
You know, the 3-file thing may be due to running out of cogs... Maybe something is wrong with the cog termination...
We're using 1 cog for lcd, 1 for sd, 1 for serial, 1 for Spin, leaving 4 free cogs. So, actually maybe that's not it...
I'll try to look into this tonight...
Actually, can you try adding a new variable, k, to PlayWav and then change the cognew line to this:
k:=COGNEW(@ASMWAV,@parameter1)
Then, at the end of the function, just before "return" add in this line:
cogstop k
That should tell us for sure if that is the problem...
Meanwhile, maybe another approach (with or without the tarballs) is to create a M3U playlist text file:
http://en.wikipedia.org/wiki/M3U
Nice thing here as that we can include the song name and albumn name in this file...
The M3U option may be the better option?
Still can't find the trouble with yours stopping after 3 files... Mine's been playing for ~2 hours the same 7 clips over and over...
Maybe you can zip and email me 4 songs so that I can reproduce this?
I wonder if it's the length of the samples in this newly structured wavplayer? They all play ok in the original Wav player but that opened and then closed a cog each time a wav file played, This one leaves the cog running all the way through doesn't it?, So maybe that's the problem? Or something to do with the buffers, didn't they clear after each played file on the old player and maybe not so in this version?
According to PST:
File 1 #Samples: 16312296
Playtime (s) = 369
File 2 #Samples: 11583600
Playtime (s) = 262
File 3 #Samples: 16687440
Playtime (s) = 378 Freezes after playing this
Strangely though as mentioned before I changed the third file from a previous one that froze exactly the same after playing and that was a 5min+ file
I can send you the songs if you like, not sure if you'll appreciate the music though unless you like progressive rock from 1972
where should I send them?
On another note it crossed my mind as to how much current the wav player draws from the USB port as it's powering both boards and several quickstart leds and the display backlight, USB I think can supply a max of 500ma? Just wondering if it may be a good thing to get a powered hub?
Now the touchscreen is incorporated into the wav player at least the backlight can be turned on and off (not sure about the quickstart leds as I believe they are to do with driving the screen, is that correct?), I may include that into the code for when it's used on a battery supply.
Edit re touchscreen backlight on off: Noticed the I2C driver doesn't run in it's own cog, The touchscreen comms would need to be in a repeat loop to constantly scan for input at the same time the PlayWav routine/s are doing their stuff, should a cognew command be put in the I2C driver object or is that not the best place to put it? Trouble is a lot of code associated with the touchscreen is in the main program, Just wondering if all the touchscreen code and calls to the I2C driver should be in a seperate touchscreen object running under it's own cog?
If a parent object "Touchscreen" runs in it's own cog and calls "I2C" as a child from it's object list, would the call interrupt the wav playing? ie does "I2C" run in the cog that "Touchscreen" started? or will "Touchscreen" have to include all the "I2C" code in one parent and lose the call to the child?
My understanding is all following code after the cognew including calls to other objects is run in the new cog until the parent runs out of code to execute, then that cog shuts down, Is that correct?
Sorry for asking so many questions.
If I can't find the problem, please email your 4 files to ray@rayslogic.com so we can sort this out...
Ok, I just tested a full CD of music that was ripped with Windows Media Player into .wav and put on the uSD card. It's on song 9 of 10 right now with no signs of trouble.
One of the songs has 12663756 samples, close to yours.
So, I'm thinking it's something special with your hardware...
I've tried all sorts of things like changing the USB port and reloading to eeprom but it always gets stuck at the same place, I'll reload the original and try that again in case anything may have changed?
Edit: Just checked in the prop tool and the memory locations go up to 7FFF which looks like only a 32K version, I was robbed!
I've got another quickstart coming from PropellerPowered.com so hopefully it's the 64K version and I can do a comparison with the Wav Player
Do you have a lot of other things on the uSD card?...
Maybe we could try re "mount" ing the uSD card between songs. Seems like it's getting stuck trying to open the next file.
Or maybe there's something in the filenames that is messing it up...
Can you try renaming your songs test1.wav, test2.wav, etc...
Also, maybe try with multiple copies of just one .wav file...
I think that might be the solution as the old player did that
the files are already named test1.wav ..test2.wav..etc
Did you see the post above about eeprom size, could I have memory problems compared to your quickstart using the new player code?
Eeprom size is not a factor here. I think it's something with the uSD card interface, but not sure what...
Starting to run low on ideas, but here's two things to think about:
1. Maybe there's something different in the way your card is formatted... Can you try reformatting the uSD and reloading the files?
2. There's a potential problem with starting and stopping the frsw driver in that when the driver is not running, there are no pullups
on the control lines and there's a chance that could driver the uSD card into a bad state.
Re-mounting the uSD every time should fix this. I'll try to add this to the code for you to try. This might be it, since as you said,
the other version didn't do this.
If it's #2, I do have some ideas about keeping the driver running all the time... That should also prevent the pops whenever a new song starts... Will take some time to develop that though...
I've added the "mount" before playing each file in this version (I'm hopeful this will fix it for you):
QMP_WavPlayer2a - Archive [Date 2013.03.21 Time 22.15].zip
Ray, would a few physical pull-up resistors be on order to prevent potential problems here?
Only the wav playing cog is started and stopped, not FSRW... So, we never lose control of the CS signal on uSD card...
Still if the old player worked for skylight maybe this re-mounting between songs will fix whatever is going wrong there...
Edit : Ignore that, I remember it was playing up before I did the additions.
Just played using V.2a, and unfortunately no change, exactly the same problem freezes after the third track
never gets to execute this bit of code.
ser.str(string("Played time (s) = ")) ser.dec((cnt-PlayTime)/clkfreq) ser.tx(13)I'll try what you said about reformatting the uSD card, though I still wonder why it plays ok with the original player?
What option for formatting should be used FAT or FAT32?
Even plays perfectly with my adapted code with the glowing play button so well pleased, Sorry to have put you to so much trouble when it was all down to a corrupted SD, what was throwing me was it still played ok with the old player??
Now we can move on!
Shall we stay with v2 as v2a with the remounting is probably not needed now.
I'm next going to look at creating a pause button in place of the green glowing play button
Are you still powered by battery? Can you try with USB cable for power?
I think you can format the uSD in just whatever Windows picks as default (just don't do NTFS).
Or, maybe you can try swapping the names between 1&2 and 3&4?
Seems like the trouble is with tracks 3 or 4. Maybe with the names swapped, the problem will stay with the files and not the file names or position?