@Jakki You are very welcome......
......... and you are living proof that it is worthwhile making backups....
David.

@Jakki Hello again.
I spent 4 hours last night deleting all the corrupted objects.
Every time I deleted one another popped up on reopening the window, and more correct objects appeared and more of them were properly connected.
However, even once the patch was "clean" it was not as complete as the working patch you last posted.

Here is your last posted patch with [MY_RSP_HID_PRECISER] as an abstraction, which makes the main patch a little lighter (smaller file)......... generic_feb.zip

If fact, you can replace the contents of [MY_RSP_HID_PRECISER] with just one object........
[change] will do the same job all on its own.

I think it will be easier to move on again from the older working patch than to try to save the bad one.
It looks like it was [trigger] that was mostly corrupted......
David

@Jakki Hmm. It looks like there is just one object missing (well, not missing, but corrupt)....... whatever was top centre of the patch and in every copy of [pd MY_RSP_HID_PRECISER]

Other objects are missing for me on windows..... which is normal.
The worst problem is that all the connections in the patch are lost, but there is a remote chance they will come back when the problem is solved.

The patch is not going to recover the object I think. The object might still be working though.
Make a new patch and "put" that object onto a clean canvas. If it creates then it should be ok.
If not you will need to replace it, from wherever it came from.

I don't think you should edit the raw text contained in the patch in text mode. The chance of not making a mistake and destroying it is very high.

Make a backup of your patch from Pd.
I just deleted the "red-dotted" object above [hidio] and a couple of them in pd MY_RSP_HID_PRECISER ....... and saved the patch, and all the connections in the patch came back on reopening, which is good news.

If every copy of pd MY_RSP_HID_PRECISER was identical then I would.....
Make a new patch called MY_RSP_HID_PRECISER ........ so an abstraction, without the pd prefix.
Put the object inside.
Save it.
Then rename every copy of [pd MY_RSP_HID_PRECISER] in your patch to [MY_RSP_HID_PRECISER]

You can do that if they are all different, but you will need to use $ vatiables and arguments.

David.
PS....... I see there are a load more bad objects hidden away in the main window.
But they all look similar. Any idea what they were? Could you upload the object that was inside [pd MY_RSP_HID_PRECISER] (In a ZIP folder is easiest).

@Jakki That is truly horrible gobbledegook....
I think you will need to upload your patch so it can be looked at.
Although, unless your patch is doing something very exotic, I would suggest re-installing / repairing your Pd installation.
I cannot imagine that any of the error message is meaningful.
David.

@Jona Good to see it working!
Yes, generally netsends and netreceives have matched ports (one port only).
For comms with verification of receipt (tcp) it is vital.
But for udp you can "broadcast"...... much like streaming internet radio.

So you could have all your [netreceive] objects as [netreceive 3001 1] and broadcast to your router the [netsend]
So, on my network the primary router address is 192.168.1.1
That is the address that will serve up its web-page. Often referred to as the "gateway".
Its broadcast address will be 192.168.1.255
255 is reserved specifically for this purpose so......
[connect 192.168.1.255 3001( will set [netsend 3001 1] to broadcast to any/all copies of [netreceive] listening on port 3001 on any computer on the local network.
If that is what you want?
David.

@Jona Hello again...... I forgot to explain that your frozen Pd is still working, and you can communicate with it through ports (netsend and receive) so you could use a second instance of Pd to do the GUI work.
That was my thinking behind using a batch file to open more than one instance of Pd.
David.

@Jona You should be able to open an executable sending a message into [sys_gui]......
[exec "C:/Program Files (x86)/pd/bin/pd.com"(
Note the quotes that take care of spaces in the path (just like a batch file).

If you then want it to open a file then you need to give the path to that file as well........
[exec C:/path....../whatever.exe C:/path......./file.extension(

If the file is within the Pd folder then you can use a Pd global variable for the relative path.........
$::sys_libdir ..... being the C:/path_to_pd
[exec wish85.exe $::sys_libdir/lib/tk8.5/demos/widget(
Note that wish.exe is in the Pd folder so no path is required.

The last one could be useful if you are sharing a patch.
You are correct though, Pd is frozen (hands user input to the new executable.

You can open multiple copies of Pd using a batch file......
...... BUT it needs a file to open.
Eg........

start "C:\Program Files (x86)\pd\bin\pd.com" start C:\Users\"David"\Desktop\PDMusic\minx\minx_run.pd
start "C:\Program Files (x86)\pd\bin\pd.com" start C:\Users\"David"\Desktop\PDMusic\minx\minx_run.pd
exit

Note..... slashes the other way for a batch file.
And then use one of them frozen for [sys_gui]
David.

@ujav I could be sensing your movement, or there could be some interference...... https://www.raspberrypi.org/forums/viewtopic.php?t=112111
Try completely covering it with a cloth, and see if that changes anything, if it does then try it in darkness..... etc.
What is its manufacturer /reference?
David.

@ujav Yes, wrong forum, but........

Are you measuring 3V relative to 0V.....?
The delay is the time during which it will stay in its "on" i.e triggered state, regardless.
Think "automatic garden lighting"...... which is probably what it was designed for.
If it was designed for security I would not expect a delay setting, but I don't know.
Then, probably, it will refuse to react for about 3 seconds if the "one time only" switch is set, because otherwise it could re-trigger itself if it were controlling a "hot" light.
If that is not set then it will trigger again straight away.

Which suggests that your 3V is actually "off", and that it is actually reacting to IR changes or noise all the time........ being continuously triggered by your presence.

Have you tried playing with the sensitivity (if it is like this one)...... http://qqtrading.com.my/pir-motion-sensor-module-hc-sr501

And also, thinking "automatic outside lighting" again, is it not triggering at all because there is too much ambient light? (I don't think that is the case..... I would still guess that it is being permanently triggered).
David.

@egog Do they exist in the Pd Folders as executables? Look especially in the Pd/extra folder for them.
They are probably not there.
Getting externals to work was very difficult in the past.
Now there is a tool included in Pd Vanilla to help you...... called "Deken".
In the Pd menu bar go to "Help" "Find Externals" and then click the "Find All" button.
Installing everything on offer is probably a good idea.

But you still will not have [soundtouch~]....... probably...?
More and more libraries are being added to Deken all the time, so you might be lucky..
You might have to compile it for your system. You can get it here......... http://www.katjaas.nl/pitchshift/soundtouch~.html
There are detailed instructions there (for OSX).
The executables in the download link are probably 32-bit, so if your installation is all 64-bit you might be forced to compile from the source code included in the download.
If you can (system dependant), you will find it easier to stay wit 32-bit and use those executables.
They can be put directly into the Pd "extra" folder and should work.

If you post (in this thread) all the info about your computer....... operating system, Pd version, etc. you might be lucky and someone might upload it for you.
Do a google search too, as it might be posted somewhere else.

David.