My DICT is too big.
Hello Fellow Patchers,
WHAT I'M DOING:
I am trying to create an automated interactive karaoke system where users will select songs from a HUGE karaoke database and the songs will automatically be cued by the system. What I would like to have happen is to have two separate systems where users could search by either Artist or Song Title. I thought I could use the dict object to create a hierarchical database that I could use to populate umenus. For example, if "By Artist" is selected, the dict would populate one umenu with all Artists, and selections from this menu could call up from the dict the songs available from that artist to populate a second umenu.
WHAT MY PROBLEM IS:
I built an iterative system to build the dictionaries from text files by using zl.iter and a sprintf object to format them into messages to the dict object. The process takes REALLY LONG! Like 15+ minutes for a single volume. There are so many entries that zl object stops reporting them even though I set the @zlmaxsize really high and I have to feed the text in in chunks. Apart from the time involved in building the dictionary, I cant seem to call up the data correctly. I think for some reason the highest level of my data structure is stored as a key. The usual messages like "getnames" or "getkeys" do not return the correct data. I can see the data, which appears to be hierarchically correct, with a dict.view object, but I cant dig down past the highest level with a "get" message.
MY QUESTION:
Am I missing something? Can I reformat the dict somehow to return the information correctly (ie move the highest level from a key to a dictionary)? Is there a faster way to build the dictionary? Is there a different way to create a menu system like I describe at the top of this post directly from the file structure on the hard drive and forgo a dict?
EXAMPLE:
Here is an example patch that shows what I am trying to do. I am also attaching the text file for the first volume if you are brave enough to feed it into the system to build the entire first volume dictionary (of 23 volumes) to see what I am talking about when it comes to performance.
Thank you for your help. Happy Patching!
first thoughts :
-for this kind of very long list processing i'd recommend using the bach library, which is more at ease with (very) large lists.
-using filein might help too.
-dict *should* be a good tool for your aim. didn't use it extensively and couldn't say why it's not working the way you want tho. But again, the bach library might help, since they use a dict style help system, very well working.
"Is there a faster way to build the dictionary? Is there a different way to create a menu system like I describe at the top of this post directly from the file structure on the hard drive and forgo a dict?"
SQlite could handle something like this provided you have the time/inclination to get your head around it, and the discrete files in your file structure are readable by Max (most likely) . From the sound of it, it would probably be way faster too. There is not that much info on SQlite in the Max docs but a forum search should yield some results (look for Andrew Bs MovieBase tutorial as a point of departure)
a database is the best for your case (many entries). searching/sorting by interpret or title will be easy. if you got 23 volumes of this it can't be handled by any max storage object.
Hey Spectro, i can't find the Andrew Bs MovieBase on Google or in Cycling search... what is it ?
edit : probably that https://cycling74.com/tutorials/data-collection-building-databases-using-sqlite/
Yep that's the one - well done! I couldn't find the tutorial when I posted that - obviously I didn't try too hard. The term MovieBase which I could recall as the name of the database/js file in one of those tutorial patches was all I could manage - but a poor term to search for the tutorial with. Sorry...
Hah, no worries. That sqlite thing seems as powerful as undocumented :) but maybe not too hard to grasp, and there's probably a lot of doc about it outside of the Max realm.
once you get the main concept of how sqlite is linked with max all the rest is inside the sqlite docs.
as a start before adding the extra max-layer on top of SQL/Sqlite i'd recomment to go through some SQL tutorials as the thinking/logic behind SQL-database scripts differs a lot from other kind programming.
I'm proud of you, forum. This whole thread, not one lurid pun about the thread title.
it took me a while to realize the punny intent of the OP. After what i decided to leave it be, in its pure, discrete, self-sufficient essence ;)
I’m proud of you, forum. This whole thread, not one lurid pun about the thread title.
--> We are either all intellectuals or REAL GEEKS!!!