Vmusic2... getting it to talk to the picaxe

N

nbw

Senior Member
Hi all, I have my vmusic module playing ok from a 28X1. I can get it to play a track, skip next, skip previous, and grudgingly, pause and start again.

I have a wee problem though - to make a random function or simply to play all tracks, I need to know what's playing so I can display the title on the 16x2 LCD. I'd like the vmusic2 to notify the picaxe somehow when a track has finished playing, or even just tell me what is the name of the MP3 file it's playing? Does anyone know how to get the Vmusic2 to do this? I've wired it up as per the diagram in the July 07 SChip mag, and it kind of hints that you should be able to send a command to the Vmusic and it should be able to send something back... it just doesn't elaborate too much.

Ultimately it would be kind of neat if I could get the vmusic to tell me the trackname, and time remaining in the track (this is for a 3 year old's MP3 player).

All suggestions gratefully received (and tested!)
 
I don't have a VMUSIC2 yet but I identified both issues as potential problems; no end of track / end of album indicator, no indicator of which track is playing.

Assuming all albums are each in their own directories ( the only way I could see of being able to play a whole album and only that album ), one solution is to keep a .TXT file in the directory which holds track names and lengths, and read that before issuing the first 'play this track' command.

The PICAXE then does its own track time left counting down and updates the display as appropriate, and issues a play track command for the next when the time expires. It should be accurate enough and most players give a 3 second inter-track gap.

You could use 'play all tracks' but if you want to allow skip track forward or backwards or have track restart each has to be selected and played individually as needed.

The filenames have to be <i>8-dot-3 </i> ( correct me if I'm wrong ) so you'll need an additional file holding album, artists and track name if you want to display that.

If the file is large ( 15 track x 16 chars = 240 ), then the PICAXE is going to have trouble reading this, even a 28X1, so that means either using SPI for comms so it can read one char at a time and pace the incoming data rate, or a separate .TXT file per track.

Finally, 'play all' will, as I understand it, play all .MP3 in the order they are in the directory, which may not be numerically sorted order, so either play one track at a time must be used or it must be ensured that .MP3 files are loaded in an empty directory in the order required.

My plan is to write a VB application which builds up play lists, creates a 'virtual disk' as a temporary directory tree, populates that and creates the .TXT files, then the whole lot is copied over to an erased USB stick.

I have two VB apps which I use - my Ambient Music Player for the bathroom and a Hi-Fi/Car MP3 Player - but converting each to VMUSIC2 and PICAXE looks a lot more complex than I first thought it would be. I believe it's fair to say that neither VMUSIC2 nor PICAXE are ideal for either applications. I may be proven wrong.

Another problem there may be ( I cannot recall who noted it ) is that communicating with the VMUSIC2 can cause stutter/glitching of the playback. I was hoping to do a fast fade-out and fade-in when pause/un-pause is used, and may have to do that with digital pots rather than by sending VMUSIC2 commands.
 
VMUSISC2 does have end of track on later firmware versions, have a look at page 51 of

http://www.vinculum.com/documents/fwspecs/Vinculum%20Firmware%20User%20Manual%20V2.1%20Rev%202.pdf

Basically whilst playing it outputs a second counter (and then 'stopped' / S) over the serial link, so you know when it has finished the track.

As MP3 files are normally named with the song title, this is not compatible with the 8.3 filename (12 ascii characters) restriction of the VMUSIC2. Therefore, as Hippy suggests, it is probably better to name the files numerically e.g.

001.mp3
002.mp3
etc.

and then have a text file also on the drive that has a lookup table of the title

001=songtitle1
002=songtitle2
etc.etc

You can read this text file using the SEK, RDF type commands - you don't have to read the entire text file at once. It's not that easy, but definitely possible, and you could make life easier, by, for instance, if you are using a 20 character LCD always making the song titles 20 characters long (ie extra padding spaces at the end if needed). This would make the SEK command much easier to use (ie SEK offset = song number * desired multiple) whilst stepping through the text file to find the correct title.


For random play, e.g. assuming you have 256 tracks, use the PICAXE random command (ideally calling it multiple times in a loop) and then use one of the bytes of the random word as the filename.


Edited by - Technical on 24/08/2007 11:49:11
 
thanks Hippy and Technical, I'll print out your posts and digest them once my neighbour's stopped screaming abuse at me over the fence *sigh*
 
Hi hippy and technical, thanks for the replies. I have taken the advice of numbering the mp3s - all are numbered 01 - 25.mp3

Because I only have 25 tracks, and a 16x2 LCD, I have ensured that all tracknames are 16 characters long - no more. What I've done for now is, because I have tonnes of memory in the 28X1, simply have 25 very short subroutines that display the title on the LCD. All the LCD screen set-up (clearing, pausing etc) is done outside of these 25 routines - so it's semi-efficient.

I like technical's point about the second counter and the /S , and I know the answer is probably very simple, but how do I &quot;get&quot; these values into a variable I can detect in my picaxe program. I even got stumped trying to work out what firmware my VMUSIC2 is. I sent the VMUSIC2 module a 'fwv' command before it occurred to me I didn't know how it was going to tell me what it was! I thought about using 'opw' and 'wrf' etc to write it to a file, but then couldn't figure out how to &quot;get&quot; the variables into the file. In fact, if I can get them to a file, I may as well put them directly on the screen!
I read the Vinc pdf - and could kind of see what they were getting at. But I'm still a bit lost.

Ultimately it would be great as technical suggests to have a file with the proper song names, and scrolling LCD ability.

If someone could provide suggestions or help as to how I can 1, easily tell what firmware I have, 2, how to easily read from the VMUSIC to detect a /S (stop-track) and 3, read the seconds counter, all into variables, that would be a huge help.

And if anyone's interested in the final code and pix of the MP3 player, I'd be happy to post them.

Kind regards and thanks,
barney
 
A much simpler short cut in your case may to be to cut the filename to 10 characters. 25x10 =250, which will fit into the table (readtable command) of the 28X1. You can therefore store the names in the PICAXE and forget about the VMUSIC2 all together

If you wanted 16 charcaters you can split bewteen eeprom (read) and table (readtable) - gives you 512 bytes in the PICAXE to play with.
 
I see what you mean. Of course, I will still need the VMUSIC2 to play the mp3 files, but storing track info internally would save writing to a logfile on the VM2.
 
I guess the only bits that are still over my head technically are getting the vmusic2 to tell me, in picaxe variable form, what song number is playing / if its stopped / the seconds that have elapsed / what firmware version of the VMUSIC2 I have. I can sort of understand the /S for stopped etc... I'm just struggling with how to get that info back into my 28X1. If anyone can explain to me how to bridge the gap, I'd be really grateful. I'm hoping it might be something simple, I don't mind if it is and I just missed the boat completely ha ha.

thanks
Barney
 
The status information for which track (filename) is playing or stopped and elapsed time reported is described in &quot;Vinculum Firmware User Manual V2.1 Rev 2.pdf&quot; in section 6.8 ( page 51 onwards ).

Hooking the VMUSIC2 via a suitable interface to a PC and using a terminal emulator should give a clearer idea of what is going on.

How to get the information into PICAXE variables I've no experience of. For the 28X1 I presume you will have to use HSERSETUP, buffer the data in the background, then parse the data and move whatever you've extracted into variables to use.

The alternative is to use SPI which would allow parsing to be done on the fly as data bytes are read in, but the problems with not currently knowing how to use SPI are described elsewhere. An important mystery to solve is how to handle unsolicited SPI bytes which need to be read without waiting for such bytes which may not be there.

Determining track number could be a bit harder. If you are using &quot;V3A&quot; to play all tracks and they were written in track order to disk, you could just count the &quot;Playing&quot; responses. If playing one file at a time I expect you already know the track number in order to have decided which filename to play. If you've named the track as track number it's just a conversion job, otherwise you will have to match the filename to the database you hold to determine the track number.

On a PC using Visual Basic I'd split my VMUSIC2 player program into two and be event driven. Commands are issued then the program waits for flags to be set, or reads the flags / status information and updates display. A background thread would handle all received data and update the flags / status information as data arrived.

How that translates into 28X1 code I'm not sure, because data is still be being received while you are trying to determine what you have ( or even responding to the data received interrupt ). I think you will have to note characters received until a CR is found, then handle from the start of those characters to the CR as a command to parse.

That's going to require interrupting on every character received ( 'hserinflag' ). To clear that flag within the interrupt and return from the interrupt without missing any intervening interrupt should work but I've not tried it. I'm also assuming that background receive uses the scratchpad as a circular buffer, because otherwise there's a problem of resetting the pointer and losing data being received at that time. Again, it's something I've not tried.

Another thing to consider is that you cannot use any command which will disable internal Firmware background receive interrupts for any significant time or you can lose incoming characters. Hopefully, if you are using them ( esp. for debugging or LCD control ), SEROUT/SERTXD only disable interrupts during the sending of each byte, not for the whole command, otherwise you will have to send everything a byte at a time to ensure no disruption to the incoming data. I'm presuming that background receive will catch data received while interrupts are disabled when they are re-enabled, but it's yet another thing I've not tried. I presume you will be using HSEROUT to communicate with the VMUSIC2 so that should not present a problem.

An alternative to all this is using a polling loop after every command sent which expects a response and in the main program loop. This is the way SPI would probably have to be done.

It still looks to me that a full-spec MP3 player using the VMUSIC2 is quite complex and requires a considerable amount of thought given to its design and implementation.
 
Hi there Hippy,
yes - I've named my 12 tracks as 01.mp3, etc, so they're all on the disk in a predictable order. I have a variable 'maxtrack' which I set at the start of the program in the picaxe (although I could technically store this in a txt file on the USB disk).

One interesting point you've solved: I thought the play-all command was 'w3a' (as printed in the SC mag) not 'v3a' as you mention... that might be why play-all was doing nothing for me.

I've read the VMusic pdf doc and it makes sense at that end... it's just that *little* bit in between figuring out how to get the track info I want into those darn variables, without disrupting playback.

I've discovered too that my VMusic2 doesn't like jumping to the next track or the previous if one's playing - I have to issue it with a stop command, then it works fine. One thing that doesn't work are the pause and resume commands, hserout 0,(&quot;e&quot;,CR) and hersout 0,(CR). Just had a thought... wonder if that 'e' needs to be 'E'. Hmm.

I've decided I'm going to concentrate on the what track is playing, and when it stops functionality. The actual tracktime I can live without.

I'll keep poking and prodding away, thanks for your thoughts Hippy, if anything else jumps to mind I'd be grateful to hear it. I'll have a little play around with the sertxd side of things to study the VMusic language a bit more :)

regards,
Barney
 
nbw : <i>I've named my 12 tracks as 01.mp3, etc, so they're all on the disk in a predictable order. </i>

Note that it's the order the tracks are created in the directory which specifies the order they will play on a 'play all' command, not their numbering.

For a PC, leading zeroes are useful so the files are sorted into order when displayed in Explorer / File Manager, but not having the leading zeroes makes it a little simpler to use &quot;#&quot; in SerOut. If the track number sending is in a routine it probably doesn't make a lot of difference, and leading zeroes help when the USB drive is connected to the PC. Swings and roundabouts.

It's a matter of personal preference, but I re-number multi-disc album tracks into a single album, and that can sometimes mean more than 99 tracks, so I went for a three digit track number.

<i>I have a variable 'maxtrack' which I set at the start of the program in the picaxe (although I could technically store this in a txt file on the USB disk). </i>

You could also determine the max track number by doing a 'directory listing' for a specific file and see what the highest numbered file found is. Using the .TXT database is probably the easiest and quickest solution.

Ideally, once debugging and prototyping is over, the player should be able to determine everything it needs from the USB drive with nothing hard-coded into the PICAXE software.

It's quite a multi-faceted project, and I've got all this fun to come :-)
 
Oh right, pause without the CR. I'll try that. Got a bit of time tonight so I'll be back into it for sure.

When you say, in the order they were created, does this mean the date/time of the file creation?

I'll also try the 'v3a' instead of 'w3a' tonight. I'm pleased to say some functions are coming along really well. I can press a number 1 - 25 followed by the # key, and it plays that song. Or, you push a number then the * key and it will:

1* skip to next track
3* skip to previous
2* restart current
5* stop
4* 6* pause / resume - not working yet but Technical's CR point noted
7* random - not working yet
8* play all - not working yet but hippy's v3a point noted
0* help

It displays song title nicely on the LCD too.
I haven't quite got the Vmusic's volume control working yet - it seemed simple. I had a pot feeding a picaxe ADC, taking that value and passing it to the VM2, no joy so far. I'll keep plugging away!

thanks for all your suggestions :)
 
You must log in or register to reply here.
Back
Top