On 11/17/2014 09:12 PM, David Gerard wrote: > Have we got a dev blog You're reading it :)
Another thing comes to mind about signals & slots... and also, about the plan for multithreading changes: The problem with our native instruments, why it's bad for them to be rendered in complete per-note-parallelization, is that there's no single point in the instrument that gets called once per period, one where all the values/models/coefficients that all notes use could be updated, so what happens is either we have to use signals & slots to update those coefficients/values (slow) or we have to track the changes in every parallel threadable job (ie. every note), which leads to pointless duplication (so, also slow). So for the skeptics (hello Raine), there's yet another reason why I think it's beneficial to move to a one-threadable-job-per-track model. ------------------------------------------------------------------------------ Download BIRT iHub F-Type - The Free Enterprise-Grade BIRT Server from Actuate! Instantly Supercharge Your Business Reports and Dashboards with Interactivity, Sharing, Native Excel Exports, App Integration & more Get technology previously reserved for billion-dollar corporations, FREE http://pubads.g.doubleclick.net/gampad/clk?id=157005751&iu=/4140/ostg.clktrk _______________________________________________ LMMS-devel mailing list LMMS-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/lmms-devel
