RE: What *is* the GUID
On 28-Sep-2000 Chris Kuklewicz wrote: Here is where a design document would help. What is the GUID, and what is its purpose in life? Answer: it is what the music brainz library generates into char guid[17]. It's not a unique id since two different songs may have the same GUID but different urls. Thus the multimap. But GetFilename simply presents the first match returned. The only routines that notice multiple values with same GUID key are the Remove operations, which erase all the matches. It is a unique id for the song. 'Course, people may have the same song multiple times in their collection. So why rely on the guid-url mapping? Since PlayListItem simply combines metadata with url, why not put the url into the metadata? The url is the key into the database, and the url to metadata mapping is given by ReadMetaDataFromDatabase. With playlistitems, the one to one mapping of url and metdata is clear. But the meta-url mapping is clouded. Database. url is the key, metadata is the data. Given the metadata, you have the kludge of Getfilename. What is the consequence of GetFilename shadowing some urls by only returning the first hit? It's not really a kludge. It'll return what's desired -- a song that matches that GUID. Again, why is the sky blue? why is the grass green? why is url not in MetaData? It's just an issue of separation.. a PlaylistItem has a URL and associated MetaData. I want to grok the design before I replace the map of strings with a map on char*. I do not want to redesign where the url is stored, but I do want to understand how it got to be the way it is. -- Chris ___ [EMAIL PROTECTED] http://www.freeamp.org/mailman/listinfo/freeamp-dev
Re: What *is* the GUID
The GUID-url map is because the metadatabase is keyed off URL. When you want to retrieve the metadata, or at least the filename of a given song, given the song GUID, you use that map to get the filename. The GUID is unique, in that any files which share the same GUID are duplicates of each other, perhaps the same track on multiple albums. However, they sound the same, so it is irrelevant which one is retrieved when, for instance, inserting into a playlist a list of songs, as identified by the song GUID. -Sean As my plan for world domiation though efficient string caching unfolds, the next step is rewrite the guid - url multimap for GetFilename. The MetaData does not know the url. It knows the guid, which a keys to one (or more, it is a multimap) of urls. I see the Metdata is further wrapped into the PlaylistItem which holds: private: MetaData m_metadata; string m_url; PlaylistItemState m_state; }; And the MusicCatalog has the methods: void WriteMetaDataToDatabase(const char *url, const MetaData metadata, MetadataStorageType type = kTypeTrack); MetaData *ReadMetaDataFromDatabase(const char *url); string GetFilename(const string strGUID); ..and various Add*(url) and Remove*(url) operations. And it is the MusicCatalog that keeps track of guid-url multimap. Here is where a design document would help. What is the GUID, and what is its purpose in life? Answer: it is what the music brainz library generates into char guid[17]. It's not a unique id since two different songs may have the same GUID but different urls. Thus the multimap. But GetFilename simply presents the first match returned. The only routines that notice multiple values with same GUID key are the Remove operations, which erase all the matches. So why rely on the guid-url mapping? Since PlayListItem simply combines metadata with url, why not put the url into the metadata? The url is the key into the database, and the url to metadata mapping is given by ReadMetaDataFromDatabase. With playlistitems, the one to one mapping of url and metdata is clear. But the meta-url mapping is clouded. Given the metadata, you have the kludge of Getfilename. What is the consequence of GetFilename shadowing some urls by only returning the first hit? Again, why is the sky blue? why is the grass green? why is url not in MetaData? I want to grok the design before I replace the map of strings with a map on char*. I do not want to redesign where the url is stored, but I do want to understand how it got to be the way it is. -- Chris ___ [EMAIL PROTECTED] http://www.freeamp.org/mailman/listinfo/freeamp-dev ___ [EMAIL PROTECTED] http://www.freeamp.org/mailman/listinfo/freeamp-dev
RE: URL of patch for HashStore
Okay, I've checked this stuff out.. Few helpful tips =) - When generating a patch against CVS, please remember to update your local copy. - Remember to remove your editors temporary files.. - look at your patch before posting it =) ie., freeamp-hashstore-1.cvs.patch.gz is 525k. If you remove all the junk in the patch, it goes down to 35k. On to comments 'bout what it's doing. - Shouldn't MetaData::SetCharStore be called before the music catalog is loaded? - Memory usage before and after using the patch is identical. Tested by loading freeamp, adding all tracks in MyMusic to the current playlist, and playing it. CVS: Size: 22624 RSS: 18832 CVS+patch: Size: 22608 RSS: 18808 Isaac On 28-Sep-2000 Chris Kuklewicz wrote: The patches can be downloaded from my MIT AFS account : http://web.mit.edu/chrisk/www/ http://web.mit.edu/chrisk/www/freeamp-hashstore-1.cvs.patch.gz http://web.mit.edu/chrisk/www/freeamp-hashstore-1.beta9.patch.gz Or my full tarball (from my personal machine, more space) : http://kuklewicz.mit.edu/ http://kuklewicz.mit.edu/freeamp-hashstore-1.tar.gz freeamp-hashstore-1.cvs.patch.gz is against latest CVS at 8:20PM EST on Sept. 27,2000 (made with diff -uPr -x CVS freeamp freeamp-hashstore | gzip /home/shared/mit/freeamp-hashstore-1.cvs.patch.gz) freeamp-hashstore-1.beta9.patch.gz is against 2.1 beta 9 tar.gz If people need a full ___ [EMAIL PROTECTED] http://www.freeamp.org/mailman/listinfo/freeamp-dev ___ [EMAIL PROTECTED] http://www.freeamp.org/mailman/listinfo/freeamp-dev
Re: URL of patch for HashStore
hey issac.. could you check his stuff in to a branch so i can check it out? i am having trouble with patch on win32... elrod Isaac Richards wrote: Okay, I've checked this stuff out.. Few helpful tips =) - When generating a patch against CVS, please remember to update your local copy. - Remember to remove your editors temporary files.. - look at your patch before posting it =) ie., freeamp-hashstore-1.cvs.patch.gz is 525k. If you remove all the junk in the patch, it goes down to 35k. On to comments 'bout what it's doing. - Shouldn't MetaData::SetCharStore be called before the music catalog is loaded? - Memory usage before and after using the patch is identical. Tested by loading freeamp, adding all tracks in MyMusic to the current playlist, and playing it. CVS: Size: 22624 RSS: 18832 CVS+patch: Size: 22608 RSS: 18808 Isaac On 28-Sep-2000 Chris Kuklewicz wrote: The patches can be downloaded from my MIT AFS account : http://web.mit.edu/chrisk/www/ http://web.mit.edu/chrisk/www/freeamp-hashstore-1.cvs.patch.gz http://web.mit.edu/chrisk/www/freeamp-hashstore-1.beta9.patch.gz Or my full tarball (from my personal machine, more space) : http://kuklewicz.mit.edu/ http://kuklewicz.mit.edu/freeamp-hashstore-1.tar.gz freeamp-hashstore-1.cvs.patch.gz is against latest CVS at 8:20PM EST on Sept. 27,2000 (made with diff -uPr -x CVS freeamp freeamp-hashstore | gzip /home/shared/mit/freeamp-hashstore-1.cvs.patch.gz) freeamp-hashstore-1.beta9.patch.gz is against 2.1 beta 9 tar.gz If people need a full ___ [EMAIL PROTECTED] http://www.freeamp.org/mailman/listinfo/freeamp-dev ___ [EMAIL PROTECTED] http://www.freeamp.org/mailman/listinfo/freeamp-dev ___ [EMAIL PROTECTED] http://www.freeamp.org/mailman/listinfo/freeamp-dev
Re: Title scrolling
On 26 Sep, gunnm wrote: I have the current stable version of freeamp, 2.0.8, and I think the program rules! No really, it is way better than winamp, I am very impressed. I think you need to improve your "marketing" though, since I just heard about it recently from a slashdot post and would have used it a long time ago if I knew it existed. On to my question. I cannot seem to stop the title from scrolling repeatedly during song playback. Is there a way to stop the scrolling that I haven't figured out? I find it very distracting. If it isn't possible now, would it be difficult to implement? I've been meaning to add support for this in the themes. I will try and get this done next week. --ruaok Freezerburn! All else is only icing. -- Soul Coughing Robert Kaye -- [EMAIL PROTECTED] http://moon.eorbit.net/~robert ___ [EMAIL PROTECTED] http://www.freeamp.org/mailman/listinfo/freeamp-dev
Re: What *is* the GUID
On Thu, Sep 28, 2000 at 03:36:47PM -0400, Sean Ward wrote: The GUID-url map is because the metadatabase is keyed off URL. When you want to retrieve the metadata, or at least the filename of a given song, given the song GUID, you use that map to get the filename. The GUID is unique, in that any files which share the same GUID are duplicates of each other, perhaps the same track on multiple albums. However, they sound the same, so it is irrelevant which one is retrieved when, for instance, inserting into a playlist a list of songs, as identified by the song GUID. -Sean I am worried not about insertion, but removal. Thanks for all the clarification, everyone. I can proceed now. ___ [EMAIL PROTECTED] http://www.freeamp.org/mailman/listinfo/freeamp-dev
Re: URL of patch for HashStore
On Thu, Sep 28, 2000 at 04:42:07PM -0400, Isaac Richards wrote: Okay, I've checked this stuff out.. Few helpful tips =) - When generating a patch against CVS, please remember to update your local copy. Guilty. Very guilty. I knowingly and cowardly and deliberately violated best practice. I am pretending that I am on a branch, since my changes are so scattered. I will bite that bullet in future cases. - Remember to remove your editors temporary files.. I tried with commands like: rm `find -name '*~' -o -name '.#*'` - look at your patch before posting it =) Guilty as charged. I only glanced at it. ie., freeamp-hashstore-1.cvs.patch.gz is 525k. If you remove all the junk in the patch, it goes down to 35k. Oooh. On to comments 'bout what it's doing. - Shouldn't MetaData::SetCharStore be called before the music catalog is loaded? I call that in unix main bootstrap.cpp and in the player ctor. That could be fixed. - Memory usage before and after using the patch is identical. Tested by loading freeamp, adding all tracks in MyMusic to the current playlist, and playing it. CVS: Size: 22624 RSS: 18832 CVS+patch: Size: 22608 RSS: 18808 Damn. What compile flags were use? Not that it really matters Since my coplies take forever I have not really tested the memory usage. Are duplicate STL strings copy on write? Hmmm... As for the MVC widgets in gtk...we could just wait for the next version: http://mail.gnome.org/archives/gtk-app-devel-list/2000-September/msg00084.html From: Havoc Pennington hp redhat com To: bl tod dk Cc: gtk-app-devel-list gnome org Subject: Re: New version of GTK+ Date: 08 Sep 2000 22:20:28 -0400 Bo Lorentsen [EMAIL PROTECTED] writes: Havoc Pennington wrote: The new text/tree widgets are totally incompatible with the old ones. (But again, the old ones remain in GTK+, so you don't have to port until you want to.) The text widget code is in CVS in mostly final form, and there's a testtext.c to look at. The tree widget is in the 'gtree' module in CVS and is still very much in flux. Does this mean that then next version will have real MVC layout, to make it possible to display lager data lists (alias database's) ? Yes, this feature was the primary motivation for the new widget. (Or at least one of the most important motivations.) Havoc ___ [EMAIL PROTECTED] http://www.freeamp.org/mailman/listinfo/freeamp-dev
Re: URL of patch for HashStore
On 28-Sep-2000 Chris Kuklewicz wrote: I call that in unix main bootstrap.cpp and in the player ctor. That could be fixed. Wasn't in the CVS patch, at least.. Damn. What compile flags were use? Not that it really matters Since my coplies take forever I have not really tested the memory usage. Normal -O2 -g, cept for the -O0 files. Are duplicate STL strings copy on write? Hmmm... As for the MVC widgets in gtk...we could just wait for the next version: Ya, I'm going to have to rewrite most of the UIs when gtk+-2.0 comes out anyways... Isaac ___ [EMAIL PROTECTED] http://www.freeamp.org/mailman/listinfo/freeamp-dev
Re: URL of patch for HashStore
On Thu, Sep 28, 2000 at 04:04:54PM -0700, Mark B. Elrod wrote:
so i did some reading up on stl strings and it appears they are copy on write.
I learn something new every day...usually 7 days after it would have
been most useful to learn it.
i do
not know if this is only for instances where you do this:
string foo, bar;
foo = "hello";
bar = foo;
and not for instances like this:
string foo, bar;
foo = hello;
bar = hello;
the results that isaac posted seem to indicate that the second case is copy on write
in which case the char store stuff won't save us any memory h need more
research to confirm/deny this theory.
I have too little time for the next few days to find that.
elrod
Except for the case where the string is empty, in which case I
allocate 1 byte which all the empty strings point to ( + 4 bytes for
each char * in the program of course).
I bet C.O.W. string does not compress duplicates:
string a,b;
char * x,y;
x=strdup("Hello");
y=strdup(x);
a=x;
b=y;
free(x)
free(y);
Since to detect this, b would have to search the actual contents of a.
Initializing a string from a char * has to make a copy. So...damn.
Perhaps HashStore should have used string internally. (Like MetaData
did).
Now the guid is in the HashStore as char* so the guid string key in
m_guidTable must make a full copy of it, where before it coould copy
on write. So if HashTable is used, I *have* to fix m_guidTable to use
char* as its key as well. Eliminating duplicate url paths by
splitting into path and filename is independent of this.
Note : m_guidTable is only used 18 lines of code in musiccatalog.cpp
and nowhere else, so it is much easier to change than MetaData was.
But if you split the filename into pathfilename then PlaylistItem
would need fixing internally.
I suggest either
a) Reverting my patch and forgetting the whole mess.
b) Keeping HashStore with m_guidTable as multimapchar*, string
instead of multimapstring,string
--
C.O.W. strins does not fix Gtk widgets. If the current CList and CTree
are duplicating the passed pointers, then for a full playlist there
are 3 copies of the strings.
Too bad the widgets are not using the std::string class.
---
Better Quesion: Can anything else be done about the RAM use? Or is it
all a bloated std c++ library?
I am not up to speed on loadable modules as they are used here. Do they
contain redundant copies of some freeamp .o files?
What is a good memory profiler to find out what object files are using
more memory (for code or data or whatever it can measure) at run time?
-
Anyway, I have no time to code again on this until Saturday.
If we toss out HashStore I can go back to working on GUI improvements,
and thinking about a search interface.
--
Chris.
___
[EMAIL PROTECTED]
http://www.freeamp.org/mailman/listinfo/freeamp-dev
Re: URL of patch for HashStore
I think alot of the memory is used by plugins that are not even being used bc all plugins are loaded at startup. We would see a massive reduction in the memory footprint if we demand load our plugins. elrod Better Quesion: Can anything else be done about the RAM use? Or is it all a bloated std c++ library? ___ [EMAIL PROTECTED] http://www.freeamp.org/mailman/listinfo/freeamp-dev
Freeamp html by Doxygen 1.2.2
The cvsweb is nice, since it is always up to date. (It would be nicer if template brackets were not stripped as bad html) But to help dig through the multitude of code, I built the latest Doxygen and had it try and index and diagram (it makes pictures!) the souce tree. The multi-platform code duplication may have wierd consequences on the namespace. If so, I may have run a copy with win32 and beos directories excluded. This is hot off the presses, and on my personal machine: http://kuklewicz.mit.edu/freeamp/ [ It takes as long a full compile to generate the html docs ] To really appreciate it, use a graphical browser instead of lynx... :) -- Chris ___ [EMAIL PROTECTED] http://www.freeamp.org/mailman/listinfo/freeamp-dev
Re: Freeamp html by Doxygen 1.2.2
On 29 Sep, Chris Kuklewicz wrote: This is hot off the presses, and on my personal machine: http://kuklewicz.mit.edu/freeamp/ [ It takes as long a full compile to generate the html docs ] To really appreciate it, use a graphical browser instead of lynx... Sweet -- are you going to keep this up to date? If so, I'll link to it from the FreeAmp developers page. This can come in really handy... --ruaok Freezerburn! All else is only icing. -- Soul Coughing Robert Kaye -- [EMAIL PROTECTED] http://moon.eorbit.net/~robert ___ [EMAIL PROTECTED] http://www.freeamp.org/mailman/listinfo/freeamp-dev
