If we are unable to open the preferences file we shouldn't try to read
from it. This led to a segmentation fault when compiled in release
mode, but for some reason it worked when compiled in debug mode?
I sort by artist / album / track, so I need to check each of these
fields in order. It would be nice if I could expand numbers into words
for some tags (3 Doors Down, Matchbox 20 and so on), but I'm happy with
what I have right now.
Pointers to a TrackTag structure are easier to pass around than the
TrackTag structure, so this should speed up sorting. Also it removes
duplicated memory between the LibraryPaths and the play_list.
Lookup by id will be slighly slower, but now I will have one list for
each path that can be merged together and sorted to represent the
library. This sounds like a good tradeoff to me, especially since I can
store an iterator to the current track when deciding what to play next.
This will give me much faster access to song for the current track.
I need to store the inode somewhere if I want to use a linked list to
store LibraryPath data. I currently have a map <ino_t, TrackTag>, so
the obvious choice is to store the inode in the TrackTag structure.
I was using a map, but the map required duplicating the library path
everywhere. Except for removing a path, I don't ever need to look up a
specific path by name, so why bother optimizing this case? Iterating
over a linked list should be more efficient (and easier to comprehend)
This function is used to access how far into the song the current audio
position is. The value is returned as a percentage of the total length
for easy use by the UI.
I always want to find tags if it's possible. Since I already have a way
to find the tags, it's fairly simple to tag a random file and pass the
result back to the UI.
The source model class is used to more tightly control how songs are
inserted into the UI. I provide an insert() function that the library's
for_each() function can take advantage of. This allows me to directly
insert songs into the UI rather than having to use a static function as
the "middle man"
This function will generate a Track object based on the current file
stored by the audio. I then pass this object to to provided function so
the UI can be updated.
This cleans up the idle task code a lot, and reduces the size of
ocarina.bin to less than 1MB (with full debugging). It probably won't
stay there long...
If the user no longer wishes to track a certain path, they can remove it
from the library. Note: it is unsafe to remove a path from the library
while that path is being scanned. This could potentially lead to a
segmentation fault.
The code was a bit messy and didn't make use of namespaces very well.
By converting to a set of functions (instead of a class) I can use
each function as a function pointer if I want to. I am also able to
remove libsaria/library.cpp since this was just a set of wrapper
functions to the old static class functions.
I plan on storing all my preferences there rather than creating my own
save directory. This will keep things consistent with other
applications the user may have.
Bryan Schumaker
Bryan Schumaker