Tutorial: Triggers (Part 3)

[infuzion]

I asked Malc a while ago about Trigger Flurries, and for me I understand easier what things are if they are explained to me in terms of actual code..Malc told me that trigger flurries are actually function flurries, meaning they are calls to functions.

Have to watch out for that giant McFlurry!

http://thefabulouslifeoflucymoreno.blogspot.com/2010_04_01_archive.html

[stw]

My only concern right now is with the loading of presets, we have close to 1,500 parameters and loading a preset seriously slows things down. So what I have done thus far is block all triggers on a parameter change and when the preset is loaded, send out one trigger to all of them. This worked ok, but I was still not getting the speed thats needed, then I connected a trigger switch to the output of the VST preset prim. That improved things greatly because the actual parameter value sends a trigger as well, not just the after change and before change. Sadly though, we are still not getting anywhere near the performance we need...

What I would like to try next is to take all the parameters and stuff them into a VST parameter array where each index represents a knob, an XY position, etc. Then place a numbered GETAT on each of the controls, the number in the get at represents the index in the VST parm array. So you would be sending out a wireless array connection, to a get at..
I wonder if the presence of only one VST parameter instead of 1,500 would make a difference as we don't know what type of calls get made in the "P" subsystem?

Though i did almost exactly the same experiments on speeding up preset changes (with the same succsess) i'm very interested in any news about your findings. Maybe you can post these HERE too?

[trogluddite]

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.

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.

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!

[tinkergnome]

hey trogluddite.... thanx for that PDF. i know that it will most certainly come in handy, in respect from a few things i recently asked about.

[trogluddite]

thanx for that PDF.

No problem, glad that people are finding it useful.

May be a bit of a wait for the next installment, as I have a few busy weekends coming up - but there is more to come...

[philter5]

thx for the update! i can see this book more and more coming....

Blank.jpg

[pall]

Yeah! And a small contribution from me.

[adamszabo]

i think we need a proper book on the whole sm and not just triggers 50$ is waiting in my wallet.

[trogluddite]

Very flattering
I think that will definitely have to be the cover - even if only for the .pdf.

Of course, my lame tales of "work", "too many SM projects", "having friends" etc. are all just a smokescreen.
Soon after publishing the first .pdf, I naturally realised that if I give away all of my secret knowledge, I might weaken my position as "Supreme SM'er of the Known Universe (and West Yorkshire)" - and thus I might lose my total and utter power over you all!!!

I thought an attachment of my evil laugh would be good at this point- but sadly, mp3 and other compressed audio formats are unable to encode the full extent of my evil.

So have decided that I will only consider writing the book in return for your SOULS! (Though, I may make an exception if you bring many bottles of the finest Belgian Trappist beer, get me very very drunk, and then distract me with a box of cute fluffy kittens!).

Please contact me by PM if you would like the book but don't have a soul - my body is getting rather decrepit these days, and maybe you have a few vital organs that you'd be willing to 'part-exchange' for a couple of the very finest paragraphs from the 'Author's Choice' compendium.

[pall]

From what I see, -among your ranks- feels some fatigue. We all in the forum we are very pleased for what you do, but you have to take care and health.
You spend much time on the computer, "missing time during the rest". But maybe I am wrong.

[tinkergnome]

btw......

philter5 ? thats a sweet user pic you got there. i just thought i would mention that.
and also,...... i'd like to learn much more about synthmaker and possibly help this forum build a library of knowledge to help future generations of members get into this quickly.

i was going to also ask trogluddite if there would be any problem in my submitting that augmented sampler with the image load button, .... unless someone else has already done that?

[trogluddite]

You spend much time on the computer, "missing time during the rest". But maybe I am wrong

He he, you know me too well! - and thankyou for caring.

Actually, I was a lot worse when I started out on old Z80 machines in my teenage years. I am more fortunate now to live in a different place,surrounded by countryside, good friends and a lot of good live music (and beer) - .I love those things (almost) as much as I love my PC.

I find that a nice walk in the trees, is not only good for the health - the total 'non-technology' environment is often where I grasp the solution to programming problems,find ideas for art, songs etc - without even making an effort, because my head is lost in looking at the beauty of nature.

(If the weather is too bad to go out, I find that visiting the 'little room' for a nice long poo is often good for fixing programmers 'brain freeze'!)

[tektoog]

I find that visiting the 'little room'

I play Tetris there, on my old Nintendo DS... 2 days ago, I just beat the CPU in the VS mode... LEVEL 5 !!!
But that was after traning for 3 years !!!
I'm fulfilled .....

[attic]

A Z80 .... how old are you? I turned 40 this year and started on an C64.. to an Amiga then Atari St from there a mac something and finally PC. I didn't start the DSP thing or any type of programming until recently, but have used cubase since the Atari St.

In the spirit of what Trogs doing here I should point all of you to this Digital sound processing tutorial for the braindead! http://yehar.com/blog/?p=121 It reminded me of Trogs easy to understand explanations. DSP in simple terms is not easy to come by on the Web so thanks for the resource Trog and I have 50 bucks or more waiting on the book.

[trogluddite]

41 this year.
But I still haven't forgotten how awesome it felt to have a real live working computer at home for the first time. Never had a C64, but I remember wanting one - the games programmers for that machine really pushed those old CPU's to the limits; quite incredible what they managed to do with just 8bits running at a few MHz.

Like the link - never found that one before.