@enaeer Well........ mine has stopped working as well.
In 32-bit Pd/Gem (extended) I cannot get [pix_video] to work at all any more.
So maybe like me you don't have any 32-bit drivers for the camera on your system?
But in 64-bit It will work with [pix_video WMD]..... so set to use Windows media driver.
Setting driver DS just reverts to WMD for my camera.
It will not crash but I only get an image after repeatedly selecting device 0 until it succeeds.
So many programs install codecs and filters..... maybe it searches for the next one and again searches until is stumbles across one that works?
There are tools here...... https://www.nirsoft.net/utils/installed_codec.html that let you see all the 32-bit of 64-bit filters and codecs that you have installed........ and to disable them if necessary.

Clicking [enumerate( in cam.zip will print a message to the console with more information about your camera and a clue about the missing codec/filter.........
Do that before you click "create"....
But on my system it gives different messages for 32 and 64-bit Pd.
David.

Thanks again @lacuna - great to have that thread as reference!

Just tried it for a bit: I cannot seem to find any binary releases in the github, https://github.com/mganss/pdjs (EDIT: found them https://github.com/mganss/pdjs/releases )- so I went along with this:

http://puredata.info/Members/mganss/software/pdjs/1.2.63/pdjs[v1.2.63](Darwin-amd64-32)(Linux-amd64-32)(Linux-arm64-32)(Windows-amd64-32).dek/view

I don't really understand what this .dek file is supposed to be, but the page itself says it is a zip file, so I tried this (I use MSYS2 bash shell in Windows):

$ wget http://puredata.info/Members/mganss/software/pdjs/1.2.63/pdjs%5Bv1.2.63%5D%28Darwin-amd64-32%29%28Linux-amd64-32%29%28Linux-arm64-32%29%28Windows-amd64-32%29.dek/at_download/file -O pdjs_v1.2.63.dek

$ unzip pdjs_v1.2.63.dek
Archive:  pdjs_v1.2.63.dek
  inflating: pdjs/js.dll
  inflating: pdjs/js.l_arm64
  inflating: pdjs/js.pd_darwin
  inflating: pdjs/js-help.pd
  inflating: pdjs/js.pd_linux
  inflating: pdjs/js-help.js

nice, now I have a pdjs folder; so I tried copying it to my 32-bit copy of PurrData:

$ mv pdjs /c/bin/PurrData_x86_2.15.2/extra/
$ /c/bin/PurrData_x86_2.15.2/bin/pd.exe -verbose

Here, in an empty patch, I place an object [pdjs/js test.js] (see also the note in the Github README about declare -path pdjs); and I get:

...
tried C:\\Program Files (x86)\\Common Files\\Pd-l2ork\\pdjs\\js\\pdjs\\js.pd and failed
tried C:\\bin\\PurrData_x86_2.15.2\\extra\\pdjs\\js.m_i386 and failed
tried C:\\bin\\PurrData_x86_2.15.2\\extra\\pdjs\\js.dll and succeeded
verbose( 1):C:\\bin\\PurrData_x86_2.15.2\\extra\\pdjs\\js.dll: couldn't load
tried C:\\bin\\PurrData_x86_2.15.2\\extra\\pdjs\\js.pd and failed
tried C:\\bin\\PurrData_x86_2.15.2\\extra\\pdjs\\js.pat and failed
tried C:\\bin\\PurrData_x86_2.15.2\\extra\\pdjs\\js\\pdjs\\js.pd and failed
error: couldn't create "pdjs/js test.js"
...

Hmmm... library got found, but is not loaded; then I thought, let's check:

$ file /c/bin/PurrData_x86_2.15.2/bin/pd.exe
/c/bin/PurrData_x86_2.15.2/bin/pd.exe: PE32 executable (GUI) Intel 80386 (stripped to external PDB), for MS Windows

$ file /c/bin/PurrData_x86_2.15.2/extra/pdjs/js.dll
/c/bin/PurrData_x86_2.15.2/extra/pdjs/js.dll: PE32+ executable (DLL) (GUI) x86-64, for MS Windows

Yeah - I cannot load a 64-bit .dll by a 32-bit .exe!

So, apparently, there is no 32-bit build for pdjs (see "Supported platforms" in the Github README), so I installed the 64-bit build of Purr Data ... and tried it there:

$ cp -a /c/bin/PurrData_x86_2.15.2/extra/pdjs /c/bin/PurrData_x86_64_2.15.2/extra/
$ /c/bin/PurrData_x86_64_2.15.2/bin/pd.exe -verbose

... and finally, could see it working - instantiating [pdjs/js test.js] gives messages:

...
tried C:\\bin\\PurrData_x86_64_2.15.2\\extra\\pdjs\\js.m_i386 and failed
tried C:\\bin\\PurrData_x86_64_2.15.2\\extra\\pdjs\\js.dll and succeeded
pdjs version 1.2.63 (v8 version 8.6.395.24)
tried C:\\bin\\PurrData_x86_2.15.2\\test.js and failed
tried C:\\Users\\user\\AppData\\Roaming\\Pd-l2ork\\test.js and failed
tried C:\\Program Files\\Common Files\\Pd-l2ork\\test.js and failed
tried C:\\bin\\PurrData_x86_64_2.15.2\\extra\\test.js and failed
error: Script file 'test.js' not found.
... click the link above to track it down, or click the 'Find Last Error' item in the Edit menu.
error: couldn't create "pdjs/js test.js"

One invocation that works for quick test is [pdjs/js pdjs/js-help.js], which succeeds - and then you can right-click the object and see the Help.

Finally, note this from the README:

There is no built-in editor like in Max, source files have to be created and edited outside of Pure Data.

Well, this is nice! On to see how to work with this object...

Thanks again for the help!

@Laevatein It looks like the utility was built for use with Pd Extended.
Do you have any "cannot create" messages in the Pd window?

It could be that you need the 32-bit dll for OpenCV as Extended is 32-bit and the SDK is probably 32-bit too. And maybe an older version? But a 32/64 bit mismatch is more likely.
I don't have a Kinect....... so this is guesswork from me...
David.

@zeke1183 The 32-bit client you want to compile receives UDP packets from the ReacTivision server on port 3333 (default) and then changes the list headers to some friendly symbols such as "addCursor" before spitting out the data (I think..... I have misplaced my amoebae....... maybe the headers are the same?).
It is all OSC data so you can receive it like this...... tuio_client.pd
You can send data back to the ReacTivision server with the left inlet of [netreceive].... see its help file.

You then have some work to do if you need to use the other patches that are provided with the 32-bit [tuioclient] ....... translating the headers....... but those other patches are abstractions and should work in your 64-bit Pd.
The data format is unchanged I think.
Have a look at the ReacTivision online documentation to understand the messages. The patch above should be receiving those messages set out in their doc.
Here is the original spec........ TUIO_Documentation.pdf

I remember the Pd [TuioClient] external actually making it much more difficult to analyse the messages from the server...... due to the translated headers...... and headers added to each data part.... such as "xPos".......
David.

((P.S. You are more likely to get instant support using 32-bit extended with [TuioClient]
A browser search engine will find quite a lot......... but it will all be based on the older Pd OSC objects (from MrPeach etc.) and forcing the newer Pd OSC objects to do exactly the same requires much more knowledge of OSC formatting.
You will need some specialized help for every question you ask....... whereas for the 32-bit version probably all the questions were answered years ago.....
You could run Pd-extended just for TUIO...... and run a 64-bit Pd vanilla at the same time for your patches....... communicating between the two using [netsend] and [netreceive]....))

Hey,

I've uploaded the Zexy external on the latest version of PD-Vanilla (Pd-0.51-1) on my Mac, (I'm on Catalina) but when I go to add a repack object it still isn't recognised and won't create the object. Any ideas why?

http://puredata.info/Members/zmoelnigbot/software/zexy/2.3.1/zexy[v2.3.1](Darwin-amd64-32)(Linux-amd64-32)(Linux-arm64-32)(Linux-armv7-32)(Linux-i386-32)(Windows-amd64-32)(Windows-i386-32).dek

Best
Jess

@Jona I think the issue with your method is that the value stays the same over the entire block, so using it to drive a function would only output changed values at the beginning of every block.

you could use your method of adding the samples of a block in conjunction with a [tabreceive~] reading from a table that contains every integer from 0 to blocksize-1 and that would work though.
(btw I also have an object in my library [pinb~] that simply outputs the current sample # in the block for situations like this)
also if you do run it at a samplerate of 8000 hz it will take a ~5.5 times longer for rpole~ to not be able to represent than @ 44.1k so in this case it might not be as much of an issue (though obviously a counter that doesn't do that at all is preferable)

of course any method will lose precision between samples, especially if the counter isn't reset to 0 after 2^32 -1 samples (assuming "t" is a 32-bit integer)
in pd-double it would probably be better to use phasor~ with / and *~ to scale phasor to increment 1 every sample, with a period of 2^32 samples. Unfortunately in 32-bit float pd you can only represent up to 24 bits of precision so you can't divide or multiply by 2^32 exactly

A degenerate case that has probably no utility but that i post for fun.

The [block~ 32 2] (reblocked down overlapped twice)???

block.32.2.pd

Notice that here the letters represents 16 samples (64/4). And since it is always complete at each tick just one of them is required. The result is strange. Each DSP vector is sliced in four pieces, and combined. Is it normal. I don't know? But it can be awesome! For what?

TBH I did that kind of thing only to be sure that i didn't make an error while refactoring Pure Data.

[a b c d]  !  [A B - -]
              [- C D -]
              [- - A B]
              [D - - C]

-->       [A+D B+C A+D B+C]

// [block~ 32 2]

BLOCK FREQUENCY+4
BLOCK PERIOD+1
INLET SIZE+64
INLET WRITE+64
INLET HOP+64
OUTLET SIZE+64
OUTLET HOP+16

#+0#

P+0/+64

R+0/+32
W+0/+32
R+32/+32
W+16/+32
R+0/+32
W+32/+32
R+32/+32
W+48/+32

E+0/+64

#+1#

...

Basic upsampling and downsampling is obvious also. The up/down sampling is done before/after (the prologue/epilogue) in anothers buffers. The DSP computation is performed in one shot with the required block size.

// [block~ 32 1 0.5]

BLOCK FREQUENCY+1
BLOCK PERIOD+1
INLET SIZE+32       // Downsampling is done before.
INLET WRITE+32
INLET HOP+32
OUTLET SIZE+32      // Upsampling is done after.
OUTLET HOP+32

#+0#

P+0/+32             // Read 32 samples already downsampled from 64.

R+0/+32
W+0/+32

E+0/+32             // Write 32 samples that will be upsampled to 64.

#+1#

P+0/+32

R+0/+32
W+0/+32

E+0/+32

// [block~ 128 1 2]

BLOCK FREQUENCY+1
BLOCK PERIOD+1
INLET SIZE+128      // Upsampling is done before.
INLET WRITE+128
INLET HOP+128
OUTLET SIZE+128     // Downsampling is done after.
OUTLET HOP+128

#+0#

P+0/+128

R+0/+128
W+0/+128

E+0/+128

#+1#

P+0/+128        // Read 128 samples already upsampled from 64.

R+0/+128
W+0/+128

E+0/+128        // Write 128 samples that will be downsampled to 64.

For reblocked down (e.g. [block~32]) it is rather easy.

At each DSP tick the parent's vector (64 samples) is simply processed right away piece by piece.

// [block~ 32]

BLOCK FREQUENCY+2
BLOCK PERIOD+1
INLET SIZE+64
INLET WRITE+64
INLETHOP+64
OUTLET SIZE+64
OUTLET HOP+32

#+0#

P+0/+64     // Prologue: write 64 samples in the buffer in.

R+0/+32     // Proceed first half part (32 samples).
W+0/+32
R+32/+32    // Proceed secondth half part (32 samples).
W+32/+32

E+0/+64     // Epilogue: read 64 samples from the buffer out.

#+1#

P+0/+64

R+0/+32
W+0/+32
R+32/+32
W+32/+32

E+0/+64

@jameslo yes, @ddw_music was correct. It's a combination of double and single precision (and I edited my last comment, this prediction is consistent w/ the 1st patch at least). The value "conv" in the source code is stored in a t_float, which is generally a 32-bit float these days (though maybe that will change soon..). This is set to 1/samplerate. every sample conv is multiplied by the input frequency (which is also a 32-bit float) and then added as a double to the current phase, which is a double with value 1572864 + actual phase, (1572864 is 3^19, a float value that makes bit 32 of the entire 64-bit double value the 1s place, leaving the remaining 32 bits as the fractional part). Every sample the top 32 bits of the phase are set to the top 32 bits of 1572864, and when the phase is output, 1572864 is subtracted from it.

tldr: the phase accumulator is basically 32-bit fixed-point