On Wed, Oct 04, 2000 at 02:40:10PM -0500, David A. Walker wrote:
> After pondering the searching issue some more, I came up with a function
> prototype that will (hopefully) address everyone's needs:
> int FindSong(char *pattern, int type, int casematters)

And the returned int is the index of the first or next matching song?
As this would be a C++ method, what new or existing object would own it?
> Pattern is just the search pattern, type is what type of search to
> perform, and casematters indicates whether the search is
> case-sensitive. The types would work like this:

the bool works for me

> Type 0 is a simple search. If the pattern occurs anywhere in the track
> name, it's a match.
> Type 1 is a wildcard search. The pattern must match the _entire_ track
> name, * matches anything (including nothing), and ? matches one
> character. \ makes the next character have its literal meaning.
> Type 2 would be a regex search. Anything goes.

Use enums for better legibility, but yes this is fine.

> This could be done easily using the regex routines which are part of
> libc. Additionally, regex.c (from the sed package) could be included to
> link against for platforms that lack built-in regex support.
> Does this address everyone's searching desires?

> Also, after seeing the various searching suggestions that were posted
> (especially the one about returning search results as a playlist), it
> struck me that there are two fundamentally different types of searching
> support.

Lets see how fundamentally differnt they are.

> The first is a very flexible, powerful search that could look at
> any (or all) of the metadata fields in the MusicCatalog and create a
> playlist based on the results. This is great for graphical players, which
> have a need for on-the-fly playlist modification and the ability to
> import/export from the catalog.

Yes, that was my idea.

> However, it is nearly useless for
> text-based players which have a fixed playlist and no good way to
> import/export from a db. The other method is a fast-and-dirty search that
> would be quick and easy to use and only check a specific attribute of the
> song. (eg., the pathname) This method would only return one result, but it
> could be used multiple times to access different songs that matched the
> pattern.

the API for that is larger than just FindSong. You need to start/stop
a given search.

> This is very useful for the text-based players, which lack any
> method of jumping to a given song in the playlist, but it is virtually
> useless for graphical players, where the user can simply click on a song
> to play it. I believe that most people want the first kind of searching
> support, because most people like their GUIs. For backwards people like me
> who still live in the stone age, the latter type is an absolute
> necessity. Does this sound reasonable?

I have never used Freeamp on the console.  Perhaps I should.  A
playlist seems to just a structure like (from PlaylistManager) :

vector<PlaylistItem*> m_masterList

So what you actually want is an API like this

vector<PlaylistItem*>* PlaylistMananger::StartSearch(pattern,type,casematters)

Then make a function PlayFirst that takes the returned pointer, pops the first
PlaylistItem* off the vector, and jump to that song and starts playing it.
Then passing the returned pointer PlayFirst over and over will move forward
through the search results.  This is the behavior you want.

Bind that to the a key, and you are set.

To let it loop from the last item to the first item again, move the
front item to the end of the vector instead of popping it off (might
want a deque instead of a vector).

Then make a StopSeach function that cleans up the vector when you are
done with the previous search and need a new one.

Since you call StopSearch right before StartSearch, you could even
combine them into the same function.

If you focus on the need to go through each search result in turn,
then having an internal view of the playlist like this (a sub-playlist)
makes sense.

Now all this assumes you want to start each new search at the top of
the playlist.  If you want to start it form the currently (or most
recently played) song, then you could have a one function API:

"Go to first song after m_lastindex that matches the
pattern/type/casematters and play it"

Or you could mimic this by cylicing through the vector of results in
PlayFirst so the next song after m_lastindex is played.


I like the design discussion that is going on.


Reply via email to