Sorry for the spam, i just noticed that the TICKS vs. FRAMES issue sucks even more than I was aware of.
When i draw automation for a software synthesizer, this automation curve is stored in FRAMES. So when changing tempo, all my automation is screwed, even though it would be perfectly fine to "stretch" it (i.e., have it stored in TICKS, not in FRAMES) We'll need to overhaul that soon… My idea is: - don't store any beginning points in FRAMES, only TICKS - (wave event beginning offsets are still stored in file-relative frame counts, but that's different) - store all automation in TICKS - wave parts may select one of "store length in TICKS, auto-stretch" (suitable for recorded or played-in music) and "store length in FRAMES", do not autostretch (suitable for effects like screams, door creak etc) problems with that: one might have meant to modulate an "effect" like a scream, door creak etc with the automation. This would break now. (but this currently breaks as well: you'd have automation and the effect in sync, but not effect and music; i think the change even makes it better.) workaround: modulate your effect outside MusE and use that modulated wavefile. FRAMES are basically useless, because they're sampling-rate dependent (which both tim and me want to fix by doing transparent sampling rate conversion) and tempo-dependent (which at least i want to fix by time-stretching audio). They're good as a "slave", cached quick-lookup data, but they must not contain information. i think, all FRAMES stored within MusE should be calculated from TICKS values, and never vice versa. (The only exception might be wave event length for effects) greetings flo
signature.asc
Description: OpenPGP digital signature
------------------------------------------------------------------------------ Master Java SE, Java EE, Eclipse, Spring, Hibernate, JavaScript, jQuery and much more. Keep your Java skills current with LearnJavaNow - 200+ hours of step-by-step video tutorials by Java experts. SALE $49.99 this month only -- learn more at: http://p.sf.net/sfu/learnmore_122612
_______________________________________________ Lmuse-developer mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/lmuse-developer
