Hi ABSTRACT:
It is "GUI performance" XOR "crackle-free playback". Currently, MusE focusses on "crackle-free" only, neglecting "GUI performance". (Using message passing, delegating work to the audiothread) With my proposal, we could offer "crackle-free" whenever needed, but can also offer "GUI performance" when currently not playing back (i.e. most of the time!) tl;dr: skip this until ====SNIP==== i'm currently doing a great rework of: - the Undo system - the way GUI-actions are synced with the audiothread - clone parts and much more... I have removed the ModifyPart Undo operation. When you now want to modify a Part's beginning, length or name, you do not any more create a copy of the part, modify that, and then replace the old part with the modified copy, but you just submit a ModifyPartTick. The audio part will parse and execute that message then. However, i want to make this message passing *obligatory*. No GUI part may have the possibility to directly write into audio-thread-managed data. (I.e., all GUI routines may only receive const references to the EventLists.) This arises one problem: someevent->setSelected() must be handled by the audiothread as well. This makes things similarly slow as moving notes in the score editor. For every operation, we've to wait for the audio thread to process it. ====SNIP==== interesting part starts here: Now i'd like to speed this up: When the song is not playing or recording, the audio thread does not access its parts in any way, right? We could lock a mutex whenever we're playing back, and release it when transport is "stopped". Then, song->applyOperationGroup() can tryLock() this mutex. (tryLock locks it, if possible. if not, it does not block, but immediately return!) If locking succeeds (i.e., if transport is stopped), then the changes can be applied in the GUI context without any harm. And this is *fast*. If locking does not succeed (i.e. transport is playing), then we have to go over the Audio::sendMessage, and wait for the audiothread to execute our changes. There's only one race-condition: When applyOperationGroup() has locked the mutex, but audio would like to start playing in the very same moment. MusE can use the transport framework to tell the transport master "please wait some milliseconds, i'm still initalizing...", so this won't be an issue. I'd really like to hear your opinion about this (further work depends on this). This would enable us to clean up huge part of muse, I even dare to say this can be the first step towards a easy-to-maintain muse3! And it would improve GUI performance notably, especially on setups which are not trimmed towards minimum audio latency (e.g. MIDI setups!) in await for your reply, Tim, Robert and Orcan, flo
signature.asc
Description: OpenPGP digital signature
------------------------------------------------------------------------------ Get 100% visibility into Java/.NET code with AppDynamics Lite! It's a free troubleshooting tool designed for production. Get down to code-level detail for bottlenecks, with <2% overhead. Download for free and get started troubleshooting in minutes. http://pubads.g.doubleclick.net/gampad/clk?id=48897031&iu=/4140/ostg.clktrk
_______________________________________________ Lmuse-developer mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/lmuse-developer
