Hi All,
I'm about to learn puredata, but I didn't reach very far. I understood the issue with 2 or more inlets, and read, that a trigger could help
I'm not shure if i really understood that trigger thing, so can anyone look at "my" example?
Best regards, Sebastian Schwerdhöfer
Hallo, Sebastian Schwerdhoefer hat gesagt: // Sebastian Schwerdhoefer wrote:
I'm about to learn puredata, but I didn't reach very far. I understood the issue with 2 or more inlets, and read, that a trigger could help
- but never found an example for that.
I'm not shure if i really understood that trigger thing, so can anyone look at "my" example?
Your example is perfectly correct.
The left example also "works", it just works differently than the right one.
The right part with the trigger will always output the sum of both numbers, whereas the left part realizes a "muted" addition. Here you can set the number to add without generating any output, until a number is sent to the leftmost inlet. That's why the leftmost inlet also is called the "hot" inlet here, the right inlets are "cold" inlets.
If you think about it: The trigger object triggers its *outlets* in exactly the *opposite* order. That is, first the rightmost outlet fires, then the next one until at last the leftmost outlet fires.
This makes sure, that if you directly connect outlets to inlets without making crossed connections, the cold *inlet* of any *following* objects gets its data as the *last* one. So all setup and stuff done through the other inlets can happen an be finished first.
A good example is squaring a number:
[3( | [t f f] == [trigger float float] | | [* ] | 9
Here the right trigger outlet will fire first, so the internal multiplicator of [* ] will set to be "3". No output is generated.
Then the left outlet of trigger fires and sends another "3", which will get multiplied with the "3" stored previously. *Now* the [*] will send "9" along as now its "hot" inlet was triggered.
If you send a "4" into the trigger, it will correctly output "16" as the previously stored "3" will be overwritten with a new "4" at the right moment.
If you consider the other possible connection, you cannot be sure of the result unless you now the history of the patch:
[3(
|
[t f f]
\ /
x
/
[* ]
|
?
Will there be a 9 here? Or a 3? Or a 0? And when?
It also is instructive to look at one of the rare objects, where the hot inlet is left: [timer].
A typical [timer] idiom is this:
[t b b] | | [timer] |
which will give the time differenc between two incoming bangs. See the help patch for timer to learn why.
Frank Barknecht _ ______footils.org__
_ __latest track: "plak" @ http://footils.org/cms/show/44
Hallo, Frank Barknecht hat gesagt: // Frank Barknecht wrote:
A good example is squaring a number:
[3( | [t f f] == [trigger float float] | | [* ] | 9
...
If you consider the other possible connection, you cannot be sure of the result unless you now the history of the patch:
[3( | [t f f] \ / x /
[* ] | ?Will there be a 9 here? Or a 3? Or a 0? And when?
Small addition here: If you don't use a trigger *at all* here as in this:
[3(
|
|
[* ]
then the order, in which the inlets get the data is *undefined*. That is, you cannot know which of the previously illustrated trigger orders you get in your patch.
And thus you will not know the result of the multiplication in advance. This is really bad as it will lead to errors in your patch. That's why it is so immensly important to understand and *use* triggers all the time.
Remember: "Pd" does not only stand for "Pure Data" but also for: "Pull da trigger!"
Frank Barknecht _ ______footils.org__
_ __latest track: "plak" @ http://footils.org/cms/show/44
Hallo, Frank Barknecht hat gesagt: // Frank Barknecht wrote:
It also is instructive to look at one of the rare objects, where the hot inlet is left: [timer].
Damn, a stupid error: I meant "where the hot inlet is *right*" of course.
Frank Barknecht _ ______footils.org__
_ __latest track: "plak" @ http://footils.org/cms/show/44
yeah you got it with your example.
note [trigger bang float]
is almost always abbreviated to [t b f]
usually, the right inlet of an object will not force an output, unless modified or triggered by the left...that is standard for pd.