added 0.37 version from pddp_referencesfiles.zip

svn path=/trunk/; revision=890

1 files changed, 166 insertions, 0 deletions

diff --git a/doc/pddp/help-line.pd b/doc/pddp/help-line.pd
new file mode 100644
index 00000000..a188ad45
--- /dev/null
+++ b/doc/pddp/help-line.pd
@@ -0,0 +1,166 @@
+#N canvas 70 32 802 522 10;

+#X obj 22 14 line;

+#X text 57 14 -- ramp generator;

+#X text 17 43 [line]'s left inlet defines the "target" value. The right

+inlet defines the "time" value. The "target \, time" pair of numbers

+inform [line] to produce a numeric "ramp" from its current value (whatever

+that might be at any given moment) to the new value within the alloted

+time which is defined at the right inlet.;

+#X text 18 131 It is important to realize that [line] stores only the

+current value...it does not remember the defined "time" (duration of

+the ramp). Hence \, the following works:;

+#X obj 26 246 line;

+#X msg 60 222 1000;

+#X msg 26 222 1000;

+#X obj 26 179 bng 15 250 50 0 empty empty empty 0 -6 0 8 -262144 -1

+-1;

+#X obj 26 199 t b b;

+#X floatatom 26 268 5 0 0;

+#X obj 167 254 line;

+#X msg 167 230 1000;

+#X obj 167 210 bng 15 250 50 0 empty empty empty 0 -6 0 8 -262144 -1

+-1;

+#X floatatom 167 276 5 0 0;

+#X text 20 293 If [line] receives a new target value without an accompanying

+"time" \, it simply jumps to the new value...as in the example above

+on the right. In the example above on the left \, you'll see that [line]

+will create a numeric ramp from 0 to 1000 over 1000 milliseconds. You

+should also note that if you click that [bng] again a second time \,

+nothing happens. This is because [line] is already at 1000 \, so sending

+it new instructions to ramp to 1000 is meaningless and has no effect.

+;

+#X text 18 419 Having said all of that \, let's just reiterate that

+it's important to send a "time" value to [line] before sending it a

+new "target" value...unless of course you WANT it to jump immediately

+to the new target.;

+#X text 415 20 [line] will accept a list of two numbers. The first

+in the list will be assigned as the new target \, the second in the

+list will be the new time (duration of the ramp) as below:;

+#X obj 387 11 bng 15 250 50 0 empty empty empty 0 -6 0 8 -262144 -1

+-1;

+#X obj 387 473 bng 15 250 50 0 empty empty empty 0 -6 0 8 -262144 -1

+-1;

+#X obj 420 187 line;

+#X msg 420 99 1000 1000;

+#X floatatom 420 208 5 0 0;

+#X text 486 98 ramp up.;

+#X msg 429 122 0 1000;

+#X text 476 122 ramp down.;

+#X msg 441 166 stop;

+#X text 416 65 [line] will also accept the "stop" message which effectively

+halt the current ramp.;

+#N canvas 51 105 536 509 continuous_ramps 0;

+#X text 29 44 [line] does not schedule its incoming messages. What

+this means is that if you send [line] a new target value mid-way through

+a ramp \, a new ramp is immediatly created to the new target value

+starting from the "current" value.;

+#X text 27 105 In other words \, if [line] receives a message specifying

+some new target and time before reaching the previous target \, it

+takes off from its current value.;

+#X obj 34 254 hsl 128 15 0 127 0 0 empty empty empty -2 -6 0 8 -262144

+-1 -1 0 1;

+#X msg 64 212 stop;

+#X msg 57 192 42;

+#X obj 31 233 line;

+#X msg 31 151 127 5000;

+#X msg 49 172 0 5000;

+#X text 18 23 CONTINUOUS RAMPS;

+#X text 24 278 Due to this unique behavior \, a common construct found

+in PD patches includes the [pack] object as follows:;

+#X obj 38 399 line;

+#X floatatom 38 420 10 0 0;

+#X floatatom 38 313 5 0 0;

+#X obj 38 379 pack f 500;

+#X msg 49 332 50;

+#X msg 57 353 2000;

+#X connect 3 0 5 0;

+#X connect 4 0 5 0;

+#X connect 5 0 2 0;

+#X connect 6 0 5 0;

+#X connect 7 0 5 0;

+#X connect 10 0 11 0;

+#X connect 12 0 13 0;

+#X connect 13 0 10 0;

+#X connect 14 0 13 0;

+#X connect 15 0 13 0;

+#X restore 404 262 pd continuous_ramps;

+#X text 168 180 While this does NOT work unless;

+#X text 166 190 you click "500" first.;

+#X msg 201 230 500;

+#X msg 437 145 42;

+#X text 463 146 jumps to this value immediately.;

+#X text 478 166 stops the current ramp.;

+#X text 403 288 More information about [line] can be found in the Pure

+Documentation folder doc/3.audio.examples.;

+#X text 412 450 This document was updated for PD version 0.35 test

+28 by Dave Sabine as part of a project called pddp proposed by Krzysztof

+Czaja to build comprehensive documentation for PD.;

+#X text 404 326 RELATED OBJECTS;

+#X obj 405 346 line~;

+#N canvas 0 0 452 302 related_objects_from_other_libraries 0;

+#X obj 23 21 tripleline;

+#X obj 105 20 t3_line~;

+#X obj 171 20 fade~;

+#X obj 219 21 step;

+#X text 17 54 These objects are offered in PD only if you have downloaded

+and properly installed the appropriate library. These objects may or

+may not exist in a single library.;

+#X text 16 103 The best places to find information about PD's libraries

+is:;

+#X text 13 125 www.pure-data.org and click on "Downloads" then "Software"

+;

+#X text 14 141 or;

+#X text 15 155 iem.kug.ac.at/pdb/;

+#X restore 406 370 pd related_objects_from_other_libraries;

+#N canvas 0 0 454 528 grain_rate_and_creation_arguments 0;

+#X text 20 18 GRAIN RATE;

+#X text 32 38 The "grain rate" of [line] is the rate at which it will

+output its values. The faster the grain is \, the smoother the ramp

+will appear. While slower grain rates will produce a more disjunct

+ramp. Of course this setting will alter the amount of CPU that the

+[line] object will require. Higher rates require more computation.

+;

+#X text 33 144 This means simply that [line] will output a new value

+between its current value and your new value once every 20 milliseconds.

+;

+#X text 33 125 The default grain rate is 20 milliseconds.;

+#X text 30 192 [line]'s optional creation arguments can be used to

+reset the grain rate. However \, the grain rate cannot be reset dynamically.

+;

+#X text 32 247 First creation argument is the initial value: the starting

+point of the first ramp.;

+#X text 31 286 The second creation argument sets the grain rate. Observe

+the following two examples to see how the grain rate effects the output.

+;

+#X obj 44 417 line 0 5;

+#X obj 47 450 hsl 128 15 0 127 0 0 empty empty empty -2 -6 0 8 -262144

+-1 -1 0 1;

+#X msg 147 346 127;

+#X msg 179 354 0;

+#X obj 146 382 pack f 5000;

+#X obj 214 450 hsl 128 15 0 127 0 0 empty empty empty -2 -6 0 8 -262144

+-1 -1 0 1;

+#X obj 211 417 line 0 500;

+#X connect 7 0 8 0;

+#X connect 9 0 11 0;

+#X connect 10 0 11 0;

+#X connect 11 0 7 0;

+#X connect 11 0 13 0;

+#X connect 13 0 12 0;

+#X restore 404 235 pd grain_rate_and_creation_arguments;

+#X connect 4 0 9 0;

+#X connect 5 0 4 1;

+#X connect 6 0 4 0;

+#X connect 7 0 8 0;

+#X connect 8 0 6 0;

+#X connect 8 1 5 0;

+#X connect 10 0 13 0;

+#X connect 11 0 10 0;

+#X connect 12 0 11 0;

+#X connect 17 0 18 0;

+#X connect 19 0 21 0;

+#X connect 20 0 19 0;

+#X connect 23 0 19 0;

+#X connect 25 0 19 0;

+#X connect 30 0 10 1;

+#X connect 31 0 19 0;