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)
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.
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 don't actually perform a library update at this point, but I do create
a new task and add it to the update queue. When the run_task() function
is called, the task is removed from the queue and deleted.
Bryan Schumaker
Bryan Schumaker