>> cache[track][note][(tick/250)*250][tick] >> >> I hope you can follow me and would be most gratefull for a reply. > > I'm not sure about the (tick/250)*250 part, since it seems to be > redundant with indexing by tick.
It is used since the tick is a dictionary and not a list, so I have to home in on what notes are displayed on screen by 250, and then iterate through them checking if they exist in the dictionary (by using try: [...] except KeyError: pass). This apears smarter (in my head) that getting the midi-tick of the start of the display, and then iterating through all midi-tick that are displayable on screen, checking if there's a note with cache.index(tick), because since the program can zoom, thousands of midi-ticks can be displayed on screen. > Apart from that, no, I don't see a > better way to optimize that off the top of my head. Are you having a > performance problem? Well, not with the program on its on, but since it's a sequencer it has to run at the same time as the sound-client, in this case iiwusynth, and then every CPU-cycle counts. I can do what I just descriped on my Celeron 500MHz, but not while moving the mouse fast (which is, of course, the ultimate test ;) ), then sound skips, so I was just wondering if I could speed up this function somehow. Thanks for your answer. Cheers ...Christian _______________________________________________ pygtk mailing list [EMAIL PROTECTED] http://www.daa.com.au/mailman/listinfo/pygtk Read the PyGTK FAQ: http://www.async.com.br/faq/pygtk/
