There is a very interesting help topic called 03.connection.pd in the puredata doc. I can't understand why the numbers add up the wrong way. Let me pick up a concrete situation for better understanding:

the input number box is set to '33', wires are crossed in the '+' object (rig the left inlet first, right inlet last). if I scroll up the value to '34', then accroding to that tutorial, and as proved by experience, the right inlet of the '+' object does not receive the value '34', only the left inlet does, so the outlet of '+' returns 34+33=67. But if wires are 'uncrossed' (rig right inlet first, left inlet last), then what ? ok I suppose the right inlet (so called 'cold' inlet) receives data first, but then why does the left inlet receive data too ? It's a miracle in that case, the outlet returns 34+34=68.

If the author of 03.connection.pd is around I would be extremely grateful if he could explain me this curiosity in detail ... I'm beginning in puredata, I need to use it for my phD, and if that kind of misbehaviour happens for a simple addition then it's gonna happen for more complicated things. I can deal with a technical explanation, in fact I would love one, please.

cheers
legus

no, that's not a miracle:

the right inlet of the [+] object stores the incoming value until the the operations gets started by an incoming event at the left inlet. if you connect the number box first to the right inlet and then to the left inlet, the following happens:
the number box shows 10, then the second inlet of the [+] object receives the value first and stores it, but it will not trigger an operation. immediately the left inlet receives the value (10) - this event triggers the operation (in this case an addition) and results in an output value of 20 (10 on the right + 10 on the left, then processed addition)
if you first connect to the left inlet of [+] and then the right inlet, the left inlet receives the data and imediately triggers the opereation - so it receives a 10 and triggers an addition with the last stored value at right input:
if you tweaked the number box from 0 to 10, the last stored input at the right inlet has to be a 9, so the result is 19. if you tweaked it down from a higher number, the last stored value must have been an 11 so the result is 21.

edit: i'm sorry, i must have been to tired, when i typed that shit yesterday.... i changed some things now! hope you understand what i mean...

thanks for your reply, it was helpful. I've been going through tutorials for several hours now, pd is certainly a weird language when you're used to standard object-based or type-based languages like matlab or python or c. The soundfiler object for instance is completely unnatural to me. in standard coding there would be an object called "fileread" and one would enter the filename as an argument. in pd you need both a message and a soundfiler object. I guess it was thought out for convenience because in pd you can change arguments with number boxes and messages and so on ... but still it feels weird ...