Re: More searching musings...
the function should return an Error which is defined in Errors.h. feel free to add more! elrod "David A. Walker" wrote: > I was planning on makeing this part of PlaylistManager. The returned int > would be the index of the song, -1 for no match, and -2 for malformed > arguments. These return values could be enum'ed as SEARCH_NOMATCH and > SEARCH_BADPATTERN or something. ___ [EMAIL PROTECTED] http://www.freeamp.org/mailman/listinfo/freeamp-dev
Re: More searching musings...
> > 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. > > > Okay, this is a well-thought out solution. However, I'm wondering how > efficient it is to be allocating/dealllocating these search structures > when the actual search will be changing often. This is because for a > text-based player, searching is not a method of finding songs, it's a > method of moving around. The only functions for changing the song in text > mode are "previous" and "next". There are not even "10 forward" and "10 > back" options. (Although these would obviously be easy to do.) I figure, > why go to the bother of creating these search structures and having to > StartSearch/StopSearch when the search target is probably only one > song? This is why I envision FindSong as part of PlaylistManager: It would > start searching from the song immediatly after the current song, and > search the list until it found something or hit the current song. The time > spent searching is less, because you do not have to search the entire > playlist, but instead search until the first result. It allows iteration > because the same search run again will find the next song that matches, > and then the song after that... And it doesn't require any memory > allocation. > Okay, so you want the "Go to first song after m_lastindex that matches the pattern/type/casematters and play it" function. Excellent. Now there is a clear plan: have both a "return all results as a playlist" and the above solution. The playlist is much more complex, so first create the function that the console needs. Here is a question to all: For the pop-up search window I discussed before, what would be the best design to allow all platforms to have the same thing? Try to be specific. -- Chris ___ [EMAIL PROTECTED] http://www.freeamp.org/mailman/listinfo/freeamp-dev
Re: More searching musings...
On Wed, 4 Oct 2000, Chris Kuklewicz wrote: Hmm. This is going to be overly ">"ed. Oh well. > 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? > I was planning on makeing this part of PlaylistManager. The returned int would be the index of the song, -1 for no match, and -2 for malformed arguments. These return values could be enum'ed as SEARCH_NOMATCH and SEARCH_BADPATTERN or something. > > 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 > Works for me, too. I'm too used to C and its use of "int" for everything. > > 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. > Enums would be a good thing here, very true. > > 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. > I'm not so sure. I'll address this in a second. > > 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. Yes you should, it's quite awesome. > A playlist seems to just a structure like (from PlaylistManager) : > > vector m_masterList > > So what you actually want is an API like this > > vector* 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
Re: More searching musings...
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 m_masterList So what you actually want is an API like this vector* 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. -- Chris ___ [EMAIL PROTECTED] http://www.freeamp.org/mailman/listinfo/freeamp-dev
