attic wrote:I'm very interested in the Midi event trigger part of all this.
Triggers from MIDI events are used to tell the MIDI-to-Poly when you have pressed and released a key, but beyond that, triggers (in the sense of the tutorial) are not involved at all, as the poly sections are pure stream.
A trigger (in a MIDI/poly sense) is a single sample pulse telling a note to begin playing - and just to be really confusing, the trigger counter output from the MIDI-to_Poly is (IMHO) very badly named. It is not counting triggers at all, it is simply a count of how many voices are currently active ('Voice counter' would be more accurate) - if it counted triggers, then surely the value would only ever go up!
It's a real shame that the naming has been made so confusing.
There is a connection between the envelopes and the MIDI-to_Poly that carries messages about the current note status, envelope stages, and when to kill a voice. Until ALL of the envelopes within a voice have finished, the note will remain active (and show at the counter output) - unless you run out of voces, in which case notes that are 'releasing' will be first to be stolen.
There is a primitive called "Envelope Control" that gives you explicit access to these signals 'wirelessly', which is used if you want to build custom poly envelopes - but the stock toobox envelopes all have this hidden away inside, so few people ever become aware of it. There's no connector or links used for this kind of data, it's just always there 'invisibly' whenever you are using a poly design.
Since I am an FX man, and tend not to build synths, that's as much as I know - but I'm sure that some of the guys working on the Multi-stage envelope
would be able to give you more details.
McBarGig wrote:function flurries
I had a feeling that it must be something like that; so thanks, it's always good to have a hunch confirmed!
The 'bad triggers' example from the tutorial schematic shows the effect of the nesting quite well, I think. Just when you think the screen will stabilise as the array fills, yet another trigger from the knob (from many seconds ago) finally arrives, and the whole process repeats itself.
While this is happening, the clearing of the call stack makes it impossible to interact with the GUI. In other (very bad!!) designs, I've also known it to stall the audio streams, or even cause the PC to hang (presumably because the stack got too big).
It also contributes to the poor timing of green signals - all new triggers are essentially joining the back of a queue, and if the queue is very long, then even very precise tickers would not be able to guarantee accurate generation of output events.
It's for this reason that I've always felt that requests for 'Accurate Green Timing' are looking for the wrong solution - the Green triggers save CPU precisely because they are asynchronous - and an asynchronous system carrying an arbitrary (and very variable) amount of data can never guarantee latency times. I've long felt that adding a synchronous (i.e. stream) way to deal with MIDI data would be a better solution than 'breaking' the advantages of the green system when used for GUI interaction and generating 'constants'.
This is particularly bad in the case of drawing complex GUI displays, e.g. with lots of Draw Loops - they take an age (relatively speaking), and no other green processing can even begin until the entire Re-Draw has completed. This would badly affect green MIDI timing even if the tickers were more accurate or had a higher frequency.
McBarGig wrote:loading of presets
To be honest, I have never used presets for more than a handful of parameters at a time; and I have no idea of the underlying methods used within the VST standard.
But it sounds to me as if you are approaching things in the right way - i.e. separate the 'loading' of presets from the 'processing'' of the values by the rest of the schematic, and display updates.
i have used an 'array distribution' system for getting MIDI CC data to knobs - using the array as a lookup table of what controller to send where, rather than every single knob having to filter every MIDI event looking for its own controller. This led to some good CPU savings in a design with 100s of possible controller destinations, so I would say that it is well worth trying for presets.
A couple of other things spring to mind...
1) Parsing - AFAIK parameters are parsed by name rather than position in the preset file. Using shorter preset names and making them more 'unique' may speed up parsing a little. For example, if every preset name were to begin with 'PresetName' then the parser has to read up to the 10th character of every name before being able to tell the parameters apart.
2) ReDraws - if possible, make it so that preset changes don't redraw GUI controls. Multiple small redraws take a hell of a lot of CPU load - instead, wait for all values to be loaded, then trigger a single redraw area that covers the entire GUI. A module with just an MGUI and ReDraw area (no actual graphics components) will refresh the graphics of all modules contained within the same area of the screen, without them each needing an explicit redraw of their own. It doesn't even have to be the topmost layer for this to work (something I'll be covering in a later tutorial).
Good luck with your design - I can't wait to see what a VST that needs 1500 parameters looks like!