-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 Hi,
i've found out something which does not amuse me: Changing the tempo map while playback *WILL* glitch. (This includes using the 50%/200% "global tempo" buttons). Mutliple reasons for this: the audio prefetch thread, well, prefetches things. If you change tempo in the near future (not yet played, but already prefetched), we're screwed: Should we empty and recalculate the prefetch buffer? Then we're playing "on the bleeding edge" for some time. If your harddisk decides to block for whatever reason, it will glitch. Or we play back what we have, and ignore the problem. This will cause audio being out of sync with MIDI until you stop/start playback. This applies to all changes in the near future, including wave-event or -part movements. What should we do? Then, what happens if the tempo is changed in the past? The current position's tick will just continue as usual, but the frame will jump (because with a different tempomap, tempomap.tick2frame will return different things) But how to inform AudioPrefetch about this? Actually, AudioPrefetch is accessing the tempo map *without synchronisation* anyway, so this is bad. We have two options here: 1. Synchronize tempomap access properly, by keeping TWO copies of the tempo map. Each change to the AudioThread's tempomap must be mirrored to the Prefetcher (and the prefetcher is in charge of migrating its own frame pointer, and possibly discard and recalculate.) However, consequentially, we would have to synchronize acces to events, parts, too. This would be really hard!) 2. ignore the problem, and declare that changing the tempomap while playback is unsupported and *expected to glitch* I want to note that none of the above mentioned is a regression. It didn't work before, and my audiostreams have the same problem. My opinion about this is: The set of possibly dangerous operations is: "changing things in the near future or in the past" and "use the global tempo buttons while playing back a wave part" while playing. I think we should state that MusE MAY glitch, but CANNOT crash in these cases. Additionally, we should offer a "glitch-free"-checkbox. If checked, all possibly dangerous operations will be disallowed. In a live situation, these "dangerous operations" should be unneeded. In a studio situation, occasinal glitches when the user provokes this are... well... acceptable. Can you agree? Greetings flo - -- Diese Nachricht wurde von meinem Smartphone aus gesendet. Etwaige Tippfehler bitte ich daher zu entschuldigen. -----BEGIN PGP SIGNATURE----- Version: APG v1.0.8 iQFCBAEBCAAsBQJSMlEPJRxGbG9yaWFuIEp1bmcgPGZsb3JpYW4uYS5qdW5nQGdt eC5kZT4ACgkQc931Ar+c+qWS3gf+NNe+B9Cv/2Y+4Zb5HA/yfD62RRTfGuiakZJt 5tisBJif+iJhb3eO/BzsAWHxfoCGjVvOjzbrLfgzjMGpcQoeihCy6+BSrCV+drOf pFTc79utDQFDIBwJltCG8zUHe6HF7y403SrTFF8YAu0isJ4mdunHwFLz/keB2+Cn AS4qLrcIioepY4Qsmd6anZCa/5ErWQwYJLxaKJZiKbnIRD943VdEEilpeZy2ItD4 1VIj2uPGfCNqEOVzM+UWqOYW82ArJ6aw79Mu3uGwZcQ/8Y5v1r7c3p2c0Ig+NlBW PHzjJ/5s+ip7RGSPz0zf7IlMDO0jKZSMLVoDksY7wFUWSTiMwg== =v1SH -----END PGP SIGNATURE----- ------------------------------------------------------------------------------ How ServiceNow helps IT people transform IT departments: 1. Consolidate legacy IT systems to a single system of record for IT 2. Standardize and globalize service processes across IT 3. Implement zero-touch automation to replace manual, redundant tasks http://pubads.g.doubleclick.net/gampad/clk?id=51271111&iu=/4140/ostg.clktrk _______________________________________________ Lmuse-developer mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/lmuse-developer
