Shop OBEX P1 Docs P2 Docs Learn Events
Changing the length of an array — Parallax Forums

Changing the length of an array

science_geekscience_geek Posts: 247
edited 2009-11-15 22:26 in Propeller 1
I am working on my mp3 player at the moment and was wondering if it were possible to be able to create an object that has an array that gets declared after the length is passed into it, this is for the track list, i plan on finding the names for the songs off of the sd card and then store that in an array, but i dont know the number of songs because it could change depending on sd card. Is something like this even possible with spin, I know with java we use an arraylist that will declare an array with the capacity of 10 and then when the size of the array needs to be something greater than 10 we add another array of 10. I have tried some basic experimenting but nothing works. Any answers out there?

Comments

  • Mike GreenMike Green Posts: 23,101
    edited 2009-11-13 03:00
    You can't do it. Arrays are static in Spin. What you can do is dynamically allocate storage between the top of the stack area and the end of memory and pass around the address of whatever area you allocate. Someone wrote a dynamic storage allocator as part of a string package in Spin. It's not hard to do. The big problem is that some other objects allocate storage the same way, like for display buffers, and there's no coordination between them. Long ago (in Propeller age), I wrote a Propeller O/S that would load up different I/O drivers and allocated storage for them at the end of memory. There was a call in one of the I/O drivers to allocate storage for a user area. There was no real way to "return" storage to the pool, but the user area was reclaimed when the program exited and the O/S was reloaded.
  • Phil Pilgrim (PhiPi)Phil Pilgrim (PhiPi) Posts: 23,514
    edited 2009-11-13 03:13
    Here's a link to the forum thread and strings object that Mike may be referring to: http://forums.parallax.com/showthread.php?p=587930.

    -Phil
  • T ChapT Chap Posts: 4,223
    edited 2009-11-13 04:53
    What about use a second eeprom.
  • MagIO2MagIO2 Posts: 2,243
    edited 2009-11-13 07:23
    Why would you need an additional tracklist? You already have one on the SD card which is called directory. For user interaction reading the directory again and again should be fast enough.
    You need additional information? Then create a file which contains all tracks of the SD-card plus the additional info (for example if the track is selected / length ...) Once you change the SD-card you first create this file - maybe supported by a checksum to avoid recreation when nothing has been changed.

    Basically the trick is: only keep in memory what you immediately need (for example for display ..).
  • science_geekscience_geek Posts: 247
    edited 2009-11-13 20:51
    what i have done is an array that holds the song title in a specific index of an array, then i send the next/change song command and pass in a song number to the change method. This will then close the currently open file on the sd card and open and start playing the next file whose name corresponds with the array index. This helps when i want to make playlists with some songs and not just play all the songs on the sd card in a row. The reason i want a "mutating" array is because im not storing a specific number of songs always on the sd card. the reason im doing it this way is because i know almost nothing on how sd cards work, if you know of a tutorial to get me introduced with them then point me in the right direction please.
  • MagIO2MagIO2 Posts: 2,243
    edited 2009-11-13 21:40
    As you already close the song that's currently playing, you can also use the directory or an additional song-title-file to find the next song. Keep in HUB RAM what you need for display purposes or whatever. And let the rest stay on SD card.

    So ... that's what I would do:
    1. Change the SD card driver a bit. You need access to the sectors. So, basically you need to create a function in the FAT-driver (fsrw), that allows you to call the readblock function in the low level driver (sdspi...).
    2. Format the SD card.
    3. Say you want a playlist of max. 1MB. So, create a 1MB file on the PC and copy it to SD card.
    4. Find out which sector is the first sector of your file. (Either you can change the driver again, or you can use PC-tools for that - WinHex for example)

    Having the SD card formatted before means that the 1MB file will occupy all the sectors in a row. A sector is 512 bytes in size. So, if you want to want to access 'virtual memory adress' 5120 you simply load sector "first sector + 5120/512" there you find your data.
    If you now choose the size of one entry of your playlist to a fraction that divides 512 without a rest, you always find full entries in your sector. For example entry size = 32 . Then you have 512 / 32 = 16 playlist entries per sector.

    So, if your command says play song 54, you simply can calculate in which sector you can find this entry and load it with the readblock function.


    PS:
    If you have access to readblock you could also have the player play an open file while you access the playlist, because the FAT driver keeps it's own variables. You only need to synchronize the access. For example having a buffer for the player and give the buffer load a higher prio. So, if the play-pointer reaches the end of a safe-zone, you don't access the SD-card for playlist access.

    Hope I pointed out clear enough what I mean ;o)

    Post Edited (MagIO2) : 11/13/2009 9:49:28 PM GMT
  • MagIO2MagIO2 Posts: 2,243
    edited 2009-11-13 23:03
    Just tried it, as I'll need it soon. It's possible to have a file open while reading single sectors into a different buffer. I only added

    pub readblock(number, buffer)
    sdspi.readblock(number, buffer)


    in FSRW.




    Gigabytes of virtual memory ...·cool ·;o)

    Post Edited (MagIO2) : 11/13/2009 11:24:28 PM GMT
  • MagIO2MagIO2 Posts: 2,243
    edited 2009-11-15 22:04
    Did you solve your problem?

    If not I might help. Just modified the SD-card driver to work as virtual memory. You can have a look at thread "Virtual Memory" to get a feeling.
    Since that I added some more functions to copy data into virtual memory (like filenames for example) and back to HUB-RAM. So, in my usecase I first scan the directory for .BMP files and copy their names into the list of BMP-files. Later on I get the filenames from this list instead of from directory. Files can still be open while using virtual memory.

    Of course you could also add more data to the table like a selection-flag or some information of the MP3 itself - e.g. full name and runtime ... whatever
  • science_geekscience_geek Posts: 247
    edited 2009-11-15 22:26
    MagIO2 said...
    Did you solve your problem?

    I have not had a chance to test it yet, we are just finishing up the semester and starting finals week, Im going home this week so hopefully next weekend i can have a chance to try what you have given me, i think it should do what i want it to though, Thank You Very Much!
Sign In or Register to comment.