"Tim E. Real" <[email protected]> schrieb: . Whenever an event's absolute pos was needed, > one simply added the part and event pos to give an absolute pos. > >> - possible accidental misuse of EventBase::frame()/tick() (they lie!) >How so?
Let's have an event in TICKS mode at relative position "100 ticks". Let's have this event placed on a part in TICKS mode at absolute position 1000. Let's begin our song with tempo 100ticks/second, but at tick#500, we increase it to 200ticks/second. Now Event::frames _lies_. Because it returns tempomap.tick2frames(100), which is "1sec". If you add Part:;frames to it (which is 7.5 seconds, correct), you'll find out that the event starts on "8.5seconds" == tick 1000+100 But this is WRONG. in reality, thr event indeed starts at tick 1100. But tempomap.tick2frame(1100) = 8sec != 8.5sec see the problem? Thus, we need to use Pos::operator+ on many placed anyway, which anyway calls tick2frames. This might be "slow" for certain values of "slow", but i have no ides if that's a problem. Let's try? (You know, premature optimisation is the root of all evil ;)) Cheers, flo -- This message has been sent from my smartphone. Please pardon any typing errors that might have occurred. ------------------------------------------------------------------------------ October Webinars: Code for Performance Free Intel webinars can help you accelerate application performance. Explore tips for MPI, OpenMP, advanced profiling, and more. Get the most from the latest Intel processors and coprocessors. See abstracts and register > http://pubads.g.doubleclick.net/gampad/clk?id=60134791&iu=/4140/ostg.clktrk _______________________________________________ Lmuse-developer mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/lmuse-developer
