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 2)

Postby trogluddite on Sat Sep 17, 2011 6:21 pm

Updated to correct an error in the examples schematic - Example 1 needed an After Load to generate a background bitmap at startup.
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 2)

Postby tor on Sat Sep 17, 2011 10:41 pm

I have some trouble to grasp how the changed modules work. The 'float equals', compare values from the same source: the 'trigger blocker'. As far as I can see the values that is compared will always be the same and the 'trigger switch' will not be opened. So the 'trigger blocker' would not even be asked for its present value...... :S

I made an example on how I expectedit to be from what I have learned until now. Though both versions seems to work the same. My modified version on top. Stock version below (shaded):
Skjermdump-2.png
Skjermdump-2.png (56.02 KiB) Viewed 3199 times
Any sufficiently advanced technology is indistinguishable from magic.
Arthur C. Clarke, "Profiles of The Future", 1961 (Clarke's third law)

http://www.audioteknikk.net
User avatar
tor
essemilian
 
Posts: 469
Joined: Wed Apr 14, 2010 8:52 pm

Re: Tutorial: Triggers (Part 2)

Postby attic on Sun Sep 18, 2011 3:25 am

@Trog. I haven't looked at part two yet but I know its gonna be helpful so thanks for this. :)

Edit: Brilliant. I could understand this! It's concise, simply put and terribly helpful. Thanks.
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 2)

Postby trogluddite on Sun Sep 18, 2011 10:52 am

tor wrote:I have some trouble to grasp how the changed modules work.

It's all in the trigger flow...
Because of the trigger blocker, the equals comparison is forced to happen when a trigger arrives at the trigger switch.
The equals will then read the value at the trigger blocker (new value), and the value at the sample and hold. The S & H won't have seen the new trigger yet, because it is still being processed by the comparison/trig.switch, so the value there will be the old value.
If the comparison is not equal, the trigger is then allowed through, to update the S&H and the final output - only now will the comparison become equal - but that doesn't matter because the trigger has already passed through the switch and done its work.
You could even add a second trigger blocker for the other input of the equals to prevent this unnecessary update of the equals/not combination.

If that's still a little confusing, never fear - for the next installment of the tutorial I am planning to cover 'Changed' modules and Trigger rate reduction. They are the key to the biggest reductions in GUI CPU load, so I will be examining how they work in a lot of detail.
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 2)

Postby trogluddite on Sun Sep 18, 2011 11:34 am

Just updated the examples schematic again - I had accidentally removed some of the bugs from the 'Bad Triggers' example when I was making screenshots. It should now match up better with the tutorial.
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 trogluddite on Sun Sep 18, 2011 3:46 pm

Part 3 now uploaded to the top post.
The new parts add tutorials for the 'Changed' modules and limiting the trigger frequency - both how to use them, and how they work.
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 attic on Sun Sep 18, 2011 8:57 pm

I cant thank you enough for these. Seriously if you write a book on SM you have my money.
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 bootsy on Mon Sep 19, 2011 4:08 pm

thanks man!
Come and visit my Blog: Variety Of Sound
bootsy
essemilian
 
Posts: 371
Joined: Sat Jul 28, 2007 10:55 am
Location: Frankfurt, Germany

Re: Tutorial: Triggers (Part 3)

Postby trogluddite on Mon Sep 19, 2011 5:55 pm

No problem, glad you're finding it useful!
Should be some more to come next weekend - I've got a few bits on GUI stuff planned, and I realised it needs a a page or two about the dreaded red feedback loops.
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 Tue Sep 20, 2011 5:47 am

:D This is a very good thing. Thank you very much! You do such a thing about coding? :D :D
pall
essemilian
 
Posts: 337
Joined: Thu Dec 09, 2010 12:27 pm
Location: Transilvania

Trigger connectors forward only?

Postby infuzion on Tue Sep 20, 2011 6:22 am

Question:
Are trigger connectors forward only? Since there is no value associated with them, then they do not need therefore do not cause a backwards value request trigger?
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 trogluddite on Tue Sep 20, 2011 6:30 pm

infuzion wrote:Question:
Are trigger connectors forward only?

Oooh, that's a tough one!
To be quite honest, I'm still not entirely sure - I have always assumed that's the case (for the same reason as you - no value to pass).
I have tried to test this for sure a few times now, including another little attempt tonight - but devising a test is not simple...

When a primitive returns a value in response to a 'backwards' trigger, it only ever sends the reply back along the same route as the request - and in this case, that would be back to a trigger input, which can't show you if anything changed! That's the big problem with reverse triggers, no way to see where they go - so tracking them is nigh on impossible.

The only way I could think of was to connect it up to some very big counters and arrays, and look for the CPU usage - but nearly all the really heavy duty stuff has a 'do it now' trigger input, precisely so that they won't get triggered by accident. It seems intuitive that these wouldn't do anything in response to a 'backwards' trigger - though I will be adding an 'exceptions to the rule' chapter at some point.
During the course of this, I did learn something else that needs a mention in that chapter... Even the array primitives without a 'do it now' trigger input do not generally respond to 'backwards' triggers - I haven't tested every single one, but it does seem like common sense that they are not updated every time something downstream is triggered.

But I'm no closer to an answer about trigger connectors. I tried testing with big nested modules of regular little maths prim's - but I got bored before I added enough to give a measurable dint in the CPU load (even on an Atom CPU).
Which may make some people wonder - "why go to all this effort optimising, if the CPU load is so small?".

A few reasons...
1) Triggering GUI ReDraws is not CPU friendly - I have had schematics where the GUI easily outstrips even the audio processing for CPU load.
2) Arrays and big loops will always be greedy if triggered too often.
3) MIDI events create triggers, and they can potentially happen much faster than mouse moves or the tickers (maybe a way there to answer Infusion's question).
4) Much of the reason I use so many trigger blockers etc. is to make a schematic behave more predictably, easier to understand, simpler to de-bug etc. If something is being triggered when you don't expect it, you don't need to search for the problem along links which have been blocked. Similarly, links which are blocked cannot be 'in the wrong order', which makes re-routing links much more predictable when editing.

PS) Although the tutorial is intended as a practical guide, I am planning to ask Malc if he'll proof read it some time, to check the technical accuracy, and see if I missed any other 'exceptions to the rule'.
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 attic on Tue Sep 20, 2011 11:01 pm

MIDI events create triggers, and they can potentially happen much faster than mouse moves or the tickers (maybe a way there to answer Infusion's question).


I'm very interested in the Midi event trigger part of all this. I would really be appreciative of info on that part of the system. I have noticed if I attach a Poly Readout to the trigger counter on the Voices to Poly, and have an adsr way down stream somewhere, the counted triggers wait for the adsr to run out before letting go. I am interested in how and in what ways triggers move backwards through a schematic as the manual leaves something to be desired in most explanations.
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 McBarGig on Wed Sep 21, 2011 1:14 am

@Trog..
I don't know if this is helpful to you or not, you probably already know this...
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. Where the problem for me comes in is that they become cascaded, so, function1 calls function2, function2 calls function3 and so forth. As anyone who develops knows, cascaded functions can become quite a problem if cascaded too deep, and the way in which SM works, a great deal of these calls need not be made at all, which is why the trigger blockers exist. It ends up being the same function called 1300 times, which in turn calls other functions 1300 times, etc.. At least thats my understanding of what Malc said...

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?

The only place this would be a problem is where the VST string prim is used...There is a work around for that too though..

Anyways Trog great work I learned quite a lot with this, thank you..

Thoughts...?
McBarGig
essemilian
 
Posts: 379
Joined: Sat Feb 14, 2009 5:00 am

Re: Tutorial: Triggers (Part 3)

Postby McBarGig on Wed Sep 21, 2011 1:15 am

attic wrote:as the manual leaves something to be desired in most explanations.

Attic, that is an understatement..haha
McBarGig
essemilian
 
Posts: 379
Joined: Sat Feb 14, 2009 5:00 am

PreviousNext

Return to Examples

Who is online

Users browsing this forum: No registered users and 1 guest

cron