I don't think I'll need this once I implement dynamic, stackable
playlists, but for now I need a way of scheduling the idle task.
Signed-off-by: Bryan Schumaker <bjschuma@gmail.com>
I put in a generic IOTask function. I'm sure this could eventually be
expanded to open and pass the appropriate stream to functions using this
task.
Signed-off-by: Bryan Schumaker <bjschuma@gmail.com>
I do this if PL_RANDOM is set before checking PL_SEQUENTIAL. I still
need to respond to the case that both flags are set...
Signed-off-by: Bryan Schumaker <bjschuma@gmail.com>
The improved next() function will increment the current iterator to the
next visible song. If no songs are visible, then it moves to the next
song on the list. The PL_DRAIN flags is then checked, and if draining
is enabled then the current track is removed from the list before
returning.
This patch also switches over the library sequential next function to
use the lib_playlist version.
Signed-off-by: Bryan Schumaker <bjschuma@gmail.com>
I can do this easier with library::lookup() since this avoids having to
loop on the entire track_list.
Signed-off-by: Bryan Schumaker <bjschuma@gmail.com>
get_info() performed a loop over all library paths and over each track
in each path to find the requested sid_t. I now keep a map sid_t ->
Track * to make finding the track easier and faster.
Signed-off-by: Bryan Schumaker <bjschuma@gmail.com>
This allows more direct access to each item in the list. It also speeds
up sorting, since I don't need to keep looking up the same tracks over
and over again in the library.
Siged-off-by: Bryan Schumaker <bjschuma@gmail.com>
With this change, my old queue code no longer saves itself. Instead, it
only sends out QUEUE_REFRESH notifications.
Signed-off-by: Bryan Schumaker <bjschuma@gmail.com>
Note that this follows the broken implementation used by the queue. It
will remove all ids with the given values rather than the ones at a
specifix index. This will be fixed later when I update the UI to make
it Playlist-aware.
Signed-off-by: Bryan Schumaker <bjschuma@gmail.com>
I replace the old queue iterator functions with calls to the queue
playlist object that way I don't need to modify the UI. This creates a
common iterator that can be used by all playlists.
Signed-off-by: Bryan Schumaker <bjschuma@gmail.com>
My goal is to slowly phase in use of a Playlist class. This patch
begins this effort by creating the Playlist class and changing the queue
code to load queue.q as a playlist in addition to the queue's hardcoded
list.
Signed-off-by: Bryan Schumake <bjschuma@gmail.com>
I want to pass a playlist argument through during playlist construction,
so I changed the LoadTask to handle it.
Signed-off-by: Bryan Schumaker <bjschuma@gmail.com>
The UI now passes in a string to use as the filename. In addition, I
store the filename and remove it when the application is closed. If the
pipe already exists, then I return the path without creating a new one.
Pipes will only be removed by the application that creates them.
Signed-off-by: Bryan Schumaker <bjschuma@gmail.com>
I save the song before refreshing the library so I can scroll back to
it. This way the user isn't interrupted too much...
Signed-off-by: Bryan Schumaker <bjschuma@gmail.com>
I want to store the currently selected row and go back there after a
refresh or a filter. This allows me to find the current songid and
scroll back to it later.
Signed-off-by: Bryan Schumaker <bjschuma@gmail.com>
The library only needs to refresh if new tracks were found, so don't do
anything if nothing new has been added.
Signed-off-by: Bryan Schumaker <bjschuma@gmail.com>
I created a new preference for "Using ALSA" that people can set if they
want to use extra alsa features. This should allow the UI to provide a
dropdown list of outputs that users can select. Once a UI is in place,
users can play music either on their computer speakers or pipe it out to
their blu ray players (or other device).
Signed-off-by: Bryan Schumaker <bjschuma@netapp.com>
After listening to a long queue, I noticed that there were problems
re-realizing widgets after moving the footer to a different page (the
header might have the same problem?). I decided to fix this issue by
creating a new footer instance for each notebook page.
If I do the same thing for the page header then I can get rid of the
"move this widget from page X to page Y" logic AND allow pages to use
their own custom header AND allow for separate library and queue
filters.
Signed-off-by: Bryan Schumaker <bjschuma@gmail.com>
If the text is "play", "pause", or "next" then I call the appropriate
libsaria function. I eventually plan on adding more commands so bash
can act as a generic remote control, but for now this is a good start!
To use: `echo play > ~/.config/saria[-debug]/saria.pipe` after creating
the fifo (see scripts/makepipe).
Signed-off-by: Bryan Schumaker <bjschuma@gmail.com>
This makes it easier to loop over all the library paths without needing
to know anything about implementation. I modified the update functions
to use the new way, so it should be ready for use by the UI.
Signed-off-by: Bryan Schumaker <bjschuma@gmail.com>
I moved ocarina over to the new system, so the old one can go away now
since it isn't thread safe and nothing uses it anymore.
Signed-off-by: Bryan Schumaker <bjschuma@gmail.com>
Rather than keeping a map of function pointers, I want the UI to
register a single function that takes a callback_t as an argument. From
there, the UI can decide the best way to handle callback lookups (such
as grabbing a lock before changing anything). At the very least, a
switch statement or array lookup should be faster than searching a map.
Signed-off-by: Bryan Schumaker <bjschuma@gmail.com>
I found it was calling itself over and over again, rather than calling
the stdlib rand(). This wasn't the desired behavior...
Signed-off-by: Bryan Schumaker <bjschuma@gmail.com>
Tracks only need to be unlisted from the library list when they are
manually removed by the user. Trying to do this during shutdown lead do
a segfault because the library's file_list had already been removed when
I tried to access it.
This allows me to create only one Track() instance for each song in the
library. Before this, a Track() was being created and then copied when
adding new songs to the library. I thought this was wasteful, so now
each song is only created once.
I use these to fill in the UI list for the library. I think this will
be easier to use (and cleaner) than passing a function pointer to a
for_each loop.
This is useful for sorting the library when filling in the list, since I
do many comparisons with the same artists and albums. This beats having
to lowercase them every time!
I don't care about the order of words for indexing, and I don't need
duplicates either. Formatting to a unique set of words should make
things a little faster.
This keeps the index up-to-date with the library. Tracks are indexed as
they are scanned, then the current filter string is run through the
index again to update it.
I need to get the next file out of the library or queue without changing
it immediately. I then queue it up in the gstreamer pipeline so it will
play automatically when the current track finishes.
It was only getting filtered when new songs were added to it and never
unfiltered. This was somewhat confusing for me, and not very useful
since the only visible songs were the last ones added. I fixed this by
creating an init option to enable filtering on songlists.
What if you want to leave and a good song starts playing? This solves
the problem by loading the next song, but not playing it so the user can
go away and listen to it when they come back.
I had a test function, but it wasn't being called. I connected the
widget to the activate signal and improved the function to list the rows
that are currently selected.
relative paths can't be trusted once the program has been installed. To
get around this, I assume that the install directory has been configured
correctly and then point to images located in the subdirectory next to
the executable.
Random hasn't been implemented in libsaria yet, but I can still create
the button to test preferences. The random button should set itself to
the value store in the preferences file.
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.
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.
Namespaces make code easier to follow, and remove the need to mangle the
beginning of function names by using ocarina_*() or libsaria_*(). In
other words: "namespaces are one honking good idea. Let's have more of
them!"
The SourceModel declares an insert() function that is called when
filling the list. I have defined this function in a way that the list
will be filled in through repeated calls to insert()
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.
It really should go into the include directory. I don't want to use
relative paths to include header files in a subdirectory... I don't know
why I even did it in the first place!
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...
I combined reference counting with the get_footer() function to make
using it easier (no manual reference counting). put_footer() will
deallocate the widget if the reference count is 0 (this is already done
by the g_object_unref() function) so it should work in a sane way.
Calling the remove() function will destroy the footer if it has no other
references. To prevent this, I need to call g_object_ref() add a
reference to the widget.
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 register the idle task when there are events in the idle queue and I
remove the idle task once those events have been processed. This should
cut down on CPU usage when nothing is happening.
When the first task is queued, I trigger a callback so the UI can start
processing when idle. I return the size of the queue from both
run_task() and queue_task() so the UI knows when to stop processing
callbacks.
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.
A text button will use a slightly larger image to make it easier to see.
This also gives me an opportunity to add some help text to describe what
the button does.
I think ocarina/ is a better name for this directory, and now that I've
named the executable "ocarina.bin" I can do this again. I also added
functions for creating a page footer with the basic controls.
This will include code for seeking and getting the current position in
the song. Right now I just have a function for resetting the position
to the beginning of the song.
Now I won't have to keep using libsaria_get() to access parts of
libsaria. This should also cut down on the number of things that need
to be recompiled when libsaria is changed...
I moved it from the generic button.cpp file to the controls.cpp file to
keep everything together. I also changed the button list to use the new
show / hide functions.
I moved all the button code into a new subdirectory. From there, I
moved the play button code into a file named controls.cpp. This should
help clean up button code.
Scons will track changes to my include/ directory better than make will.
I also have an easier time understanding the Sconstruct file than I did
with Makefiles.
I hide the play button when music is playing and show it when music has
been stopped. I hide the pause button when music is not playing and
show it when music has been stopped. This can give the effect of one
button replacing the other.
I have created generic functions for registering and triggering
callbacks. New callbacks can be added by creating a new constant in the
callback_t enum.
play() and pause() now return true or false base on if the state change
request succeeds or fails. This can be used later to determine if a
callback should be triggered.
I stop playback, and seek to the beginning. I do this as to different
function calls in the Libsaria class so callbacks will still trigger
(once they have been implemented).