it's been done before but this was my take on a simple way to livecode with [expr] in pure data - it leans into being as simple as possible so its easier to take it and use it for something else (bytemidi, drum triggers, using [expr~] instead for rampcode(?)).

a thing c and [expr],[expr~] share in common youcanwritefunctionswithoutanywhitespace so there didn't have to be any messy patching dealing with that - as an example it's being used for bytebeat (with some caveats about floats and things that [expr] doesn't like like sending it 0 with [value] at audio rate. It's pretty easy to change up - for example - pick a new big number and small number to the [mod ]s and you can make triggers for a sequencer. you could modify it to be [expr~] by changing the [message< , could stack more livecode inputs to control other things like the update frequency. anyway

https://patchstorage.com/bytebeat-and-dynamic-repatching-pd-as-a-livecode-environment/

"this is an experimental way to allow dynamic repatching in PD and do livecoding just using pure data.

livecoding requires – 1) an obscure language – pure data is a dataflow programming language 2) an obscure text editor – well I cant think of a more arcane one than a visual programming language so check that off for pure data too.

Known limitations – it’s a little crashy – the List message box doesn’t like backspaces.

32 bit floats lose precision and can make it a seem a little wonky – not all patches will sound the same because Pure Data uses 32 bit floats for effeciency. so objects with / % >> will effectively “chop” off and the patch will sound different than a real bytebeat (or whatever you use this for) after a while or seem like it can just plain quit. The numbers either got too small or too big to work with 32 bit floats.

Another thing about 32 bit floats, the biggest number PD can count to is 1.6772e+07

Pure data also squashes numbers you get 123456 digits. 1234560 turns into 1.23456e+06. In comments this gets changed after you close, reopen so try cut/paste.

Also I noticed sending 0 into [expr] in the variables makes it unhappy and crash so I avoided it making x and y 1 or bigger.

Anyway – check out

to see it in action – and if you want o use this for something else remove anything connected before and after the spigot objects.

public domain / unlicense / fishcrystals out"

pasting the same patch here: dynamicsinPatchingBYTEBEATeditionNewest.pd

dno about all the terminolgy and requirements, but it makes me happy when I see other people being creative and livecode has been a way to get people into doing experimental computer audio and video - probably after working where work is on the computer , personally I saw it as a way to rapidly prototype & it was my very first idea about something I wanted to do with bytebeat and pure data (only took a year! lol) - thanks to everyone in the community & the discord and netpd for making stuff and being helpful and being inspriring

Good day,
has anyone here ever tried using pmpd on later MacOS? Mine doesn't seem to work giving this message every time I try to create a pmpd object:

... couldn't create
/Users/fyodor-st/Downloads/pmpd 2/iAmbient2D.pd_darwin: dlopen(/Users/fyodor-st/Downloads/pmpd 2/iAmbient2D.pd_darwin, 0x000A): tried: '/Users/fyodor-st/Downloads/pmpd 2/iAmbient2D.pd_darwin' (mach-o file, but is an incompatible architecture (have 'i386', need 'arm64')), '/System/Volumes/Preboot/Cryptexes/OS/Users/fyodor-st/Downloads/pmpd 2/iAmbient2D.pd_darwin' (no such file), '/Users/fyodor-st/Downloads/pmpd 2/iAmbient2D.pd_darwin' (mach-o file, but is an incompatible architecture (have 'i386', need 'arm64'))
/Users/fyodor-st/Documents/Pd/externals/pmpd/iAmbient2D.pd_darwin: dlopen(/Users/fyodor-st/Documents/Pd/externals/pmpd/iAmbient2D.pd_darwin, 0x000A): tried: '/Users/fyodor-st/Documents/Pd/externals/pmpd/iAmbient2D.pd_darwin' (mach-o file, but is an incompatible architecture (have 'i386', need 'arm64')), '/System/Volumes/Preboot/Cryptexes/OS/Users/fyodor-st/Documents/Pd/externals/pmpd/iAmbient2D.pd_darwin' (no such file), '/Users/fyodor-st/Documents/Pd/externals/pmpd/iAmbient2D.pd_darwin' (mach-o file, but is an incompatible architecture (have 'i386', need 'arm64'))

I've been using Pure Data for a couple of years now and feel more or less comfortable with it, but have no actual background in coding of any kind, so any help figuring out what this means and whether this is fixable would be really appreciated!

Perhaps a question for Pierre? (Can't figure out how to @ people with a space in their name... @Pierre-Guillot)

I've just been fiddling around with PlugData. I found in this project's issue reports that you can use [r playhead] (same as Camomile) to get information about play state, tempo, position etc.

I would like to attach "position" messages to my scheduler object, but I don't quite understand the position values that are being reported. Documentation seems scarce.

When the project is playing, [r playhead] emits messages like:

[ position, 11.842176437378, 261120.0, 32.0, 4.0, 5.921088218689 ]
[ position, 11.88861656189, 262144.0, 32.0, 4.0, 5.9443082809448 ]
[ position, 11.935056686401, 263168.0, 32.0, 4.0, 5.9675283432007 ]
[ position, 11.981496810913, 264192.0, 32.0, 4.0, 5.9907484054565 ]
[ position, 12.027936935425, 265216.0, 32.0, 4.0, 6.0139684677124 ]
[ position, 12.074376106262, 266240.0, 32.0, 4.0, 6.0371880531311 ]
[ position, 12.120816230774, 267264.0, 32.0, 4.0, 6.060408115387 ]

To work with the scheduler, I need to be able to anticipate the next tick time. The difference between successive beats (first number) appears to be consistently 0.04644012, and this seems to be proportional to tempo (160 bpm gets 0.061919212341).

Does anyone know what the exact relationship is? I can check tomorrow if it's consistent across DAWs too, but not today.

Data collection patch is (sending by OSC because I couldn't copy/paste the log within PlugData's window):

hjh

@ingox I think this might be system and or locale dependent, I get escapes with 32 160. Plain 160 is probably the safest way to go for portability since it is a non-breaking space in both UTF-8 and Unicode and should work on most system and still work if pd goes unicode. Apprently 194 160 is UTF-8 and not unicode as I had said, but it is the same character as 160 (a non-breaking space). I half suspect that 32 160 is being seen as a double space by pd on some systems and the 32 is dropped as pd tends to drop double spaces leaving you with just the 160s and no escaped 32s, but the other half of me suspects I am overlooking something.

For anyone interested, I was able to figure out how to do it using the original guide for earlier Xcode versions. The mistake I was making was to attach the full package of Pure Data to the debugging scheme as the executable. The correct way of doing it is to link the actual executable file as described below.

In Xcode (this is v 12.3):

1. Create a new debugging scheme
   

2. Edit the new scheme:
   

3. In the Executable drop-down menu, select Other...

4. Find the executable for pd (e.g. /Applications/Pd-0.51-3.app/Contents/Resources/bin/pd)

The settings for the scheme should look like this (notice the setting for Launch - Automatically)

5. Build and run the external. This will start Pd. The actual debugging will begin when you instantiate the external object inside a patch.

In my case, I added a breakpoint inside the bang() method. Upon receiving the bang, the breakpoint is reached:

@morpheu5 the canonical supported pd only uses 32-bit floats in messages (and signals). the question of how to write/format externals that support both floats and doubles is an ongoing discussion afaik. Right now almost everyone uses "normal" pd w/32-bit floats, and externals generally aren't available for pd-double.
most architectures support doubles now, so t_float isn't based on the machine. (but I presume the reason supported pd uses 32-bit floats is so it can run on an abbacus)

However, there's nothing to restrict external developers from using doubles in their externals internally. It's just that when the message/signal goes back into pd it will be 32-bit.

I think functions like fmod are fine to use for both doubles and floats (I wouldn't be surprised if the compiler will just use fmodf instead if the inputs are floats)

But I don't know how far off pd-double is from being supported or used anyways, so right now
I'd say right now you don't need to worry about t_floats or t_samples being doubles at all. No externals support pd double, because I don't think the loading mechanism/convention has been completely fleshed-out yet. (and barely anyone uses pd-double)

@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]....))