Tutorial: Triggers (Part 3)

Until our dedicated user library is in place you can post examples and modules here

Moderators: electrogear, exonerate

Re: Tutorial: Triggers (Part 3)

Postby infuzion on Wed Sep 21, 2011 1:47 am

McBarGig wrote: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!
Image
http://thefabulouslifeoflucymoreno.blogspot.com/2010_04_01_archive.html
Need help? First search the forum & WiKi, then post in the help forum with a clear topic, request, & OSM. Then please WiKi the correct solution. If you want my personal assistance, I charge by the hour or for an exchange of services.
infuzion
smstar
smstar
 
Posts: 6169
Joined: Wed May 04, 2005 8:02 pm
Location: Earth, USA, CO, Denver

Re: Tutorial: Triggers (Part 3)

Postby stw on Wed Sep 21, 2011 4:54 am

McBarGig wrote: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?
stw
smanatic
 
Posts: 641
Joined: Mon Jun 30, 2008 2:55 pm

Re: Tutorial: Triggers (Part 3)

Postby trogluddite on Wed Sep 21, 2011 3:46 pm

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!
Feel free to use any schematics and algorithms I post on the forum in your own designs - a credit is appreciated (but not a requirement).
Don't stagnate, mutate to create. Without randomness and serendipity the earth would be just another barren rock.
User avatar
trogluddite
smychopath
 
Posts: 3033
Joined: Mon Oct 20, 2008 3:52 pm
Location: Yorkshire, UK

Re: Tutorial: Triggers (Part 3)

Postby tinkergnome on Sun Oct 02, 2011 11:59 am

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. :)
User avatar
tinkergnome
essemist
 
Posts: 65
Joined: Thu Sep 29, 2011 2:05 pm
Location: near washington DC

Re: Tutorial: Triggers (Part 3)

Postby trogluddite on Sun Oct 02, 2011 7:49 pm

tinkergnome wrote: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...
Feel free to use any schematics and algorithms I post on the forum in your own designs - a credit is appreciated (but not a requirement).
Don't stagnate, mutate to create. Without randomness and serendipity the earth would be just another barren rock.
User avatar
trogluddite
smychopath
 
Posts: 3033
Joined: Mon Oct 20, 2008 3:52 pm
Location: Yorkshire, UK

Re: Tutorial: Triggers (Part 3)

Postby philter5 on Mon Oct 03, 2011 9:57 am

thx for the update! i can see this book more and more coming....
Blank.jpg
---Yes, a piece of software CAN be your best friend---
User avatar
philter5
smaniac
 
Posts: 1495
Joined: Thu Jan 04, 2007 7:52 pm
Location: Germany

Re: Tutorial: Triggers (Part 3)

Postby pall on Mon Oct 03, 2011 11:51 am

Yeah! And a small contribution from me. :D
Attachments
volume1 yet .png
volume1 yet .png (26.46 KiB) Viewed 3236 times
pall
essemilian
 
Posts: 342
Joined: Thu Dec 09, 2010 12:27 pm
Location: Transilvania

Re: Tutorial: Triggers (Part 3)

Postby adamszabo on Mon Oct 03, 2011 1:57 pm

i think we need a proper book on the whole sm and not just triggers :) 50$ is waiting in my wallet.
adamszabo
essemilian
 
Posts: 230
Joined: Sun Jul 11, 2010 6:21 am

Re: Tutorial: Triggers (Part 3)

Postby trogluddite on Mon Oct 03, 2011 4:14 pm

Very flattering :love:
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! 3:) (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.
Feel free to use any schematics and algorithms I post on the forum in your own designs - a credit is appreciated (but not a requirement).
Don't stagnate, mutate to create. Without randomness and serendipity the earth would be just another barren rock.
User avatar
trogluddite
smychopath
 
Posts: 3033
Joined: Mon Oct 20, 2008 3:52 pm
Location: Yorkshire, UK

Re: Tutorial: Triggers (Part 3)

Postby pall on Mon Oct 03, 2011 5:44 pm

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. :)
pall
essemilian
 
Posts: 342
Joined: Thu Dec 09, 2010 12:27 pm
Location: Transilvania

Re: Tutorial: Triggers (Part 3)

Postby tinkergnome on Mon Oct 03, 2011 5:58 pm

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?
User avatar
tinkergnome
essemist
 
Posts: 65
Joined: Thu Sep 29, 2011 2:05 pm
Location: near washington DC

Re: Tutorial: Triggers (Part 3)

Postby trogluddite on Tue Oct 04, 2011 8:18 am

pall wrote: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'!) ;)
Feel free to use any schematics and algorithms I post on the forum in your own designs - a credit is appreciated (but not a requirement).
Don't stagnate, mutate to create. Without randomness and serendipity the earth would be just another barren rock.
User avatar
trogluddite
smychopath
 
Posts: 3033
Joined: Mon Oct 20, 2008 3:52 pm
Location: Yorkshire, UK

Re: Tutorial: Triggers (Part 3)

Postby tektoog on Tue Oct 04, 2011 10:03 am

trogluddite wrote: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 .....
Essential random order for chaotic repetitive sequences
User avatar
tektoog
essemilian
 
Posts: 444
Joined: Mon Apr 07, 2008 12:21 am
Location: Alps-France

Re: Tutorial: Triggers (Part 3)

Postby attic on Thu Oct 06, 2011 2:43 am

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.
A common mistake that people make when trying to design something completely foolproof is to underestimate the ingenuity of complete fools.

North Bay Music Attic
User avatar
attic
essemilian
 
Posts: 475
Joined: Sat Feb 13, 2010 12:40 pm
Location: San Francisco California

Re: Tutorial: Triggers (Part 3)

Postby trogluddite on Thu Oct 06, 2011 5:18 am

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.
Feel free to use any schematics and algorithms I post on the forum in your own designs - a credit is appreciated (but not a requirement).
Don't stagnate, mutate to create. Without randomness and serendipity the earth would be just another barren rock.
User avatar
trogluddite
smychopath
 
Posts: 3033
Joined: Mon Oct 20, 2008 3:52 pm
Location: Yorkshire, UK

PreviousNext

Return to Examples

Who is online

Users browsing this forum: No registered users and 1 guest