buggy print output order
I am new in pd and found strange for me print object behavior. test.pd
In attached pd (from Loadbang book with print adds) the output has to be
s1: 1
print: -1
print: 0
print: 1
...
print 99
s0: 0
but I see in console
s1: 1
s0: 0
print: 99
print: 98
...
print: -1
How it is possible? Or buggy and random print order is normal in PD ?!?
@GeorgeXX Yeah, I'm not sure about this. Everything happening around the [f]>[+ 1] is calculated (near) instantaneously. You CAN get the desired result by putting a [pipe f 1] before the [sel 100] but that doesn't really answer your question as to WHY the print doesn't output before the print s0...
This is not a bug, but a consequence of the way order of operations work in pd. If an object has more than one connection coming from its outlet, it has to send data to one of them before the other one, so it sends them in the order that they were connected. In this case, the [f] object has two connections coming from its outlet, and the one going to the [+ 1] is the first one, so it sends data there first. But the [+ 1] object leads back into the [f] object, so another process is scheduled there, before it had time to send to the second [print] object. This happens 100 times, meaning that 100 [print] commands are waiting to be scheduled. When the feedback cycle finally ends (ie. the spigot is closed), they come out in reverse order because the -1 has been asked to wait 100 times, whereas 99 has only been asked to wait once.
To "fix" this, all you need to do it delete the connection between the [f] and the [+ 1] object, then create it again. The print command will now be received first and hence the numbers will come out in the right order. (It would be better to use a trigger of course--that's what it's for--except that it's sometimes tiresome to do all this rewiring, especially if you just want to do a quick print test).
This might seem like strange or artificial behaviour, but if it didn't work like this, chaos would ensue!
@GeorgeXX Hello George......
Now that you are getting a better understanding of Pd it will really help you a lot if you read http://puredata.info/docs/manuals/pd/x2.htm up to chapter 2.9 (don't read 2.9...... you will give up!)......
It is quite well written. The bit about [trigger] is very important for everything you build in the future. You will find that you will understand what is going on behind the scenes whilst you are building your patch......... make fewer mistakes..... and build better patches!
Next time you have a question try to upload your patch to the forum (the up arrow button at the top while you are writing your question). That helps anyone that tries to help you....... as they don't have to build your patch again from your description........
David.
@LiamG said:
This might seem like strange or artificial behaviour, but if it didn't work like this, chaos would ensue!
Thanks to all! It really strange because I do not see connection order and can not quite count how it will work. So I need tools for full inspecting step-by-step patch behavior without "print" headache. Are they exist?
@GeorgeXX Hello again George.......
It is explained in the link above, but as @Liam says you really must use [trigger] to control your patch. Look at the [trigger-help] patch for how to use it....... (it can be created as [t a a] with the t as an alias for "trigger"...).
When analysing problems you can put a slow [metro 1000] (every second) for example at the head of your patch to repeatedly bang in the information that it is processing....... and then see inside the "cords" using the Magic Glass from the edit menu.........
I don't know of any way to slow down the processing so as to see the order of operations, as using delays would also change the order!
[Drip] is also a useful tool......... that will "drip" a list slowly into your patch.......
David.
Oops! Looks like something went wrong!
And thanks!