Hi Will,
On 09/11/2016 22:02, Will Godfrey wrote:
The current 'master' has a compile time switch to enable reporting of the
time it takes to create a note-on event. This proved to be very revealing. On
my machine, a fairly average sound takes about 60uS for each note played.
Something like 'Master Synth' takes about 130uS. However, on odd occasions they
take three times a long!
It gets worse. Run the 'Out_There' demo files and it occasionally peaks a 10x
as long. This simply has to be due to memory shuffling.
This evening I looked at the Adnote code (must be getting better, I didn't have
a panic attack) and for every note-on there are a bunch of 'new' directives
then value calculations/insertions. For each note-off there is the
corresponding bunch of 'delete'. To me, This seems quite wrong.
*warning* crazy bit coming up.
So, what if when loading an instrument to a part we do all the memory
allocations for notes up to the limit for that part (but no initialisation)?
This will take up a lot more memory than previously, but memory availability
continues to expand - and remember original Zyn was written when we were
talking in terms of memory sizes of 200-500 megabytes.
So, at note-on we do no memory management at all but simply find an emptyYoshimi source code is available from either:
slot and fill in the data. At note-off, after the release tail we just set a
flag to indicate this slot is available again. Importantly, we don't delete the
objects. However, stuff that at note-on does a lot of zeroing or standardised
data filling could usefully be shifted here to even things out a bit more.
To do it like this we don't have a single note pool, but one per part. This is
because different instruments will have different note features.
Currently, MIDI program changes are done by disabling a part, shunting the
actual loading to a low priority thread, then re-enabling the part. It should
be relatively easy to create a fresh note pool just before re-enabling the part.