Fixing a bit of a silly error made by me, all control changes on my effect plugins were flagging the project as modified, which is annoying with automations etc. So I'm disabling it. Maybe later we can have flagging only when knobs are modified manually.
Recent builds of MinGW64 runtime include the winpthreads library which
is not linked statically anymore and thus doesn't required non-portable
(de-)initialization function calls.
Changing the velocity after noteon doesn't really seem to work on fluidsynth (may be dependent on soundfont file) - seems like the panning changes when velocity is changed.
So I disabled that, after which everything works fine.
Changing the velocity after noteon doesn't really seem to work on fluidsynth (may be dependent on soundfont file) - seems like the panning changes when velocity is changed.
So I disabled that, after which everything works fine.
Issue: Currently, we use threads to process all PlayHandles, so there's no guarantee of the order they are processed in. This causes timing inaccuracy and jitter: notes of instruments that use both NPH's and IPH's can get randomly delayed by one entire period.
The issue is solved thusly:
- When processing an IPH, we check if the instrument is midi-based. If yes, we just process it normally (no NPH's to worry about).
- If it's not, then it also uses NPH's, so we'll have the IPH wait until all NPH's belonging to same instrument have been processed. There's some similar code in the new FX mixer, I pretty much just copied how we do it there.
- currently only affects Vestige
- no idea whether this can also be used for Zyn and OpulenZ, I'm not sure if Zyn has any kind of mechanism for communicating frame offset to the synth, as for OpulenZ, @softrabbit would know the answer better
- basically, I made it happen by simply adding an extra parameter in the processMidi{In|Out} functions, which is 0 by default, and made the necessary changes in instrumentTrack and nph to utilize it
- I based this against 1.1 because I didn't think it's a very big change, and I don't see much possibility for things going wrong here, since we're basically just using the existing functionality in Vestige (there already was a frame offset being communicated to the remote plugin, just that it was always set to 0). However, if @tobydox thinks this is better to bump up to 1.2, I can rebase it for master...
