Hello all.

So i had a idea for a debugger but its not real a debugger it will simply print out each object in a pd patch to console.

PrintDebugger.pd

The reason for this is I have run into a bunch of these errors that can not be tracked. Like the screenshot below.

So to combat this I had the idea of dynamicly creating and connecting a [print] to each [obj] This will allow me to see what is actually happening for each patch and in turn seeing where the red messages start exactly.

I almost have it working but im not sure how to handle the connect message.

Any ideas of how to geteach [obj] # each line is passed through $1 which is then use to create [pd tmppatch] is the index of a object always the 3rd place of a string? I have an idea of how to brake $1 down to a list but im still not sure if somthing like [pd-tmppatch connect $2 0 $3< or whatever the message should be i dont know.

Any help is appreciated.

@RetroMaximus Unfortunately there is no "index" of objects in the patch file.
When Pd opens a patch it gives them an index in their order in the list...... which is also the order in which they were put in the patch...... because that will determine the order of operations.
They appear as "obj x y" where x and y are where they appear in the patch window.... coordinates, not index.

BUT beware..... it is not just "obj" objects that count..... "floatatom" "msg"..... anything that has connections is counted.

The connect message is connect a b x y....... you see a load of them already at the bottom of the text file.
"a" is the object number to connect from starting at zero.
"b" is the outlet number of that object starting at zero on the left outlet.
"x" is the object number to connect to starting at zero.
"y" is the inlet number of that object to connect to starting at zero on the left inlet.

So with 2 objects only..... say [f] and [print]...... [connect 0 0 1 0(
With [route 1 2] and 2 [print] objects [connect 0 0 1 0( for the print of the left outlet of route and [connect 0 1 2 0( for the middle outlet.

That assumes you created [route] first and the prints afterwards.
Each object number starting at 0 is assigned in the order in which it was put in the patch.
You are going to have to count the objects in the patch to test before you start because the first [print] you put will have the next object number.

Actually you could just put a bigger number into my patch below...... a guess, but big.... and it will just throw more errors as it tries to connect [print] s together when it runs out of other objects to connect to.

debugger.zip
Of course it gets more complicated by an enormous factor when you want a [print] on all outlets of all the objects, but again, you could repeat connect messages for each object up to 10? outlets and suffer the console errors as it tries to connect to non existent outlets....... but then your print numbers will not match up with the object numbers.... hum.
David.

Ok that clears things up. Thank you.

I have a understanding of whats going on now with your patch and I was able to mash this together. I can see a connection being made. Now i cant seam to figure out how to get rid of the [tmppatch] object and use the highlighted portion instead.

The purpose of this is to get the latest temp file that was created. At the moment the PrintDebugger.pd patch has to be reopened to view the [tmppatch] file.

I tried to connect [obj 10 10 tmppatch] to the right outlet of [textfile] but pure data seams to lock up. Also If clicked [obj 10 10 tmppatch] manually I do see it added to PrintDebugger.pd I need it to be automatic as soon as a new temp file is created.

Any idea where to connect it?

@RetroMaximus Time for bed for me now and out tomorrow.... but others will help.
This [debugger2] will connect all outlets up to 10 to indexed print objects...... debugger.zip

I think you might need to upload your patch for more help though especially if you are crashing Pd.
You can make windows invisible with vis 1 and vis 0 messages....... and you might find map 1 map 0 useful as well......... 0.all_msg.pd

David.

PrintDebugger.pd

@RetroMaximus Apart from the various difficulties mentioned above, how would the outputs of all objects help to find an error?

A possibly more promising way would be to track down the error starting from beginning of the command tree. For example, if you have a metro that triggers an error, if you cut the outgoing connection, the error should stop. Then you can reconnect it and follow the path down and cut the connections one by one where the path branches. Thus you can quickly find the source of the error.

Ive been doing exactly that and i can seam to find the inlet that wants a float.

So in the original post i ran into the error "inlet expected float but got list" that gets overwritten some so i cant seam to cntrl + mouse to go to the last error. It says the error cant be found tho the screenshot does not.

So i was thinking if i could print out whatever is coming from any obj i could see the its contents and have a better idea of which inlet to look for in the overall patch. The problem is I have no idea where the inlet is.

In theory I was hoping this would breakup the string of errors with printed obj contents. Or maybe if the last thing was a triggered bang or the value of a floatatom ect.

So if i was to give the [tmppatch] all the correct test data and no red errors appear i can eliminate that pd patch move on to whatever it is connected to (if it might be a subpatch) to look at its value and see if its the correct obj type.