@jo Hi there,

To my eye the Unauthorized library looks rather abandoned, I'm not sure if the source code is on Github or elsewhere but a quick search didn't turn up anything promising. There are a bunch of other Pd-Extended era libraries that are similarly unmaintained.

There is a version in Deken (Help menu -> Find externals) called:
unauthorized-v0-0extended-(Darwin-i386-32)(Darwin-PowerPC-32)(Darwin-x86_64-32)
I think libraries with that "v0-0extended" name were taken directly from one of the final versions of Pd_Extended, and if there is no more recent version, that's a likely sign that the library is unmaintained. Since Darwin-x86_64-32 is listed, it seems your only option for using these objects is to run Pd with Rosetta 2 (Intel emulation) and reinstall the library with Deken. I also recently migrated from Intel to M2, and since my patch is dependent on a whole bunch of abandoned libraries, I'm currently running everything in Intel mode. It'd be great to have more native Apple Silicon versions of older libraries, if enough savvy Mac users are able to find the source code repos & compile updated versions.

As for those specific objects you mentioned, I haven't used either, so unfortunately I don't have a good recommendation for replacements.

@alexandros

thanks for the suggestion! I"ve never compiled anything before, but I gave it a shot...

I'm getting this error in PD after loading the 3 compiled objects (6 files: grambidec.pd_darwin, grambidec.pd_darwin.o, grambiman.pd_darwin, grambiman.pd_darwin.o, grambipan.pd_darwin, grambipan.pd_darwin.o):

 load_object: Symbol "grambiman_setup" not found in "/Users/brianlindgren/Documents/Pd/externals/grambiman.pd_darwin"

Also make is generating a bunch of warnings:

++++ info: using Makefile.pdlibbuilder version 0.7.0
++++ info: using Pd API /Applications/Pd-0.54-1.app/Contents/Resources/src/m_pd.h
++++ info: making target all in lib grambidec~
++++ info: making grambidec.pd_darwin.o in lib grambidec~
cc -DPD -I "/Applications/Pd-0.54-1.app/Contents/Resources/src"  -DUNIX -DMACOSX -I /sw/include    -Wall -Wextra -Wshadow -Winline -Wstrict-aliasing -O3 -ffast-math -funroll-loops -fomit-frame-pointer -arch arm64 -mmacosx-version-min=10.6 -o grambidec.pd_darwin.o -c grambidec.c
grambidec.c:41:24: warning: unused variable 'x' [-Wunused-variable]
    t_grambidec_tilde *x = (t_grambidec_tilde *)(w[1]);
                       ^
grambidec.c:43:16: warning: unused variable 'APin2' [-Wunused-variable]
    t_sample  *APin2 =    (t_sample *)(w[3]);
               ^
grambidec.c:44:16: warning: unused variable 'APin3' [-Wunused-variable]
    t_sample  *APin3 =    (t_sample *)(w[4]);
               ^
grambidec.c:45:16: warning: unused variable 'APin4' [-Wunused-variable]
    t_sample  *APin4 =    (t_sample *)(w[5]);
               ^
grambidec.c:69:24: warning: unused variable 'x' [-Wunused-variable]
    t_grambidec_tilde *x = (t_grambidec_tilde *)(w[1]);
                       ^
grambidec.c:78:23: warning: variable 'sample2' set but not used [-Wunused-but-set-variable]
    t_sample sample1, sample2, sample3, sample4;
                      ^
grambidec.c:78:41: warning: variable 'sample4' set but not used [-Wunused-but-set-variable]
    t_sample sample1, sample2, sample3, sample4;
                                        ^
grambidec.c:102:24: warning: unused variable 'x' [-Wunused-variable]
    t_grambidec_tilde *x = (t_grambidec_tilde *)(w[1]);
                       ^
grambidec.c:113:41: warning: variable 'sample4' set but not used [-Wunused-but-set-variable]
    t_sample sample1, sample2, sample3, sample4;
                                        ^
grambidec.c:143:24: warning: unused variable 'x' [-Wunused-variable]
    t_grambidec_tilde *x = (t_grambidec_tilde *)(w[1]);
                       ^
grambidec.c:185:24: warning: unused variable 'x' [-Wunused-variable]
    t_grambidec_tilde *x = (t_grambidec_tilde *)(w[1]);
                       ^
grambidec.c:228:24: warning: unused variable 'x' [-Wunused-variable]
    t_grambidec_tilde *x = (t_grambidec_tilde *)(w[1]);
                       ^
grambidec.c:282:24: warning: unused variable 'x' [-Wunused-variable]
    t_grambidec_tilde *x = (t_grambidec_tilde *)(w[1]);
                       ^
grambidec.c:351:37: warning: unused parameter 's' [-Wunused-parameter]
void *grambidec_tilde_new(t_symbol *s, int argc, t_atom *argv) //, t_floatarg test
                                    ^
grambidec.c:473:5: warning: performing pointer subtraction with a null pointer has undefined behavior [-Wnull-pointer-subtraction]
    CLASS_MAINSIGNALIN(grambidec_tilde_class, t_grambidec_tilde, APf);
    ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
/Applications/Pd-0.54-1.app/Contents/Resources/src/m_pd.h:529:59: note: expanded from macro 'CLASS_MAINSIGNALIN'
    class_domainsignalin(c, (char *)(&((type *)0)->field) - (char *)0)
                                                          ^ ~~~~~~~~~
15 warnings generated.
++++ info: linking objects in grambidec.pd_darwin for lib grambidec~
cc -undefined suppress -flat_namespace -bundle  -arch arm64 -mmacosx-version-min=10.6  -o grambidec.pd_darwin grambidec.pd_darwin.o  -lc   
ld: warning: -undefined suppress is deprecated
ld: warning: -undefined suppress is deprecated
++++ info: making grambiman.pd_darwin.o in lib grambidec~
cc -DPD -I "/Applications/Pd-0.54-1.app/Contents/Resources/src"  -DUNIX -DMACOSX -I /sw/include    -Wall -Wextra -Wshadow -Winline -Wstrict-aliasing -O3 -ffast-math -funroll-loops -fomit-frame-pointer -arch arm64 -mmacosx-version-min=10.6 -o grambiman.pd_darwin.o -c grambiman.c
grambiman.c:64:24: warning: unused variable 'x' [-Wunused-variable]
    t_grambiman_tilde *x = (t_grambiman_tilde *)(w[1]);
                       ^
grambiman.c:139:24: warning: unused variable 'x' [-Wunused-variable]
    t_grambiman_tilde *x = (t_grambiman_tilde *)(w[1]);
                       ^
grambiman.c:226:24: warning: unused variable 'x' [-Wunused-variable]
    t_grambiman_tilde *x = (t_grambiman_tilde *)(w[1]);
                       ^
grambiman.c:252:32: warning: variable 'sample3' set but not used [-Wunused-but-set-variable]
    t_sample sample1, sample2, sample3, sample4, sample10;
                               ^
grambiman.c:306:24: warning: unused variable 'x' [-Wunused-variable]
    t_grambiman_tilde *x = (t_grambiman_tilde *)(w[1]);
                       ^
grambiman.c:370:37: warning: unused parameter 's' [-Wunused-parameter]
void *grambiman_tilde_new(t_symbol *s, int argc, t_atom *argv)
                                    ^
grambiman.c:436:5: warning: performing pointer subtraction with a null pointer has undefined behavior [-Wnull-pointer-subtraction]
    CLASS_MAINSIGNALIN(grambiman_tilde_class, t_grambiman_tilde, APf);
    ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
/Applications/Pd-0.54-1.app/Contents/Resources/src/m_pd.h:529:59: note: expanded from macro 'CLASS_MAINSIGNALIN'
    class_domainsignalin(c, (char *)(&((type *)0)->field) - (char *)0)
                                                          ^ ~~~~~~~~~
7 warnings generated.
++++ info: linking objects in grambiman.pd_darwin for lib grambidec~
cc -undefined suppress -flat_namespace -bundle  -arch arm64 -mmacosx-version-min=10.6  -o grambiman.pd_darwin grambiman.pd_darwin.o  -lc   
ld: warning: -undefined suppress is deprecated
ld: warning: -undefined suppress is deprecated
++++ info: making grambipan.pd_darwin.o in lib grambidec~
cc -DPD -I "/Applications/Pd-0.54-1.app/Contents/Resources/src"  -DUNIX -DMACOSX -I /sw/include    -Wall -Wextra -Wshadow -Winline -Wstrict-aliasing -O3 -ffast-math -funroll-loops -fomit-frame-pointer -arch arm64 -mmacosx-version-min=10.6 -o grambipan.pd_darwin.o -c grambipan.c
grambipan.c:423:5: warning: performing pointer subtraction with a null pointer has undefined behavior [-Wnull-pointer-subtraction]
    CLASS_MAINSIGNALIN(grambipan_tilde_class, t_grambipan_tilde, APf);
    ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
/Applications/Pd-0.54-1.app/Contents/Resources/src/m_pd.h:529:59: note: expanded from macro 'CLASS_MAINSIGNALIN'
    class_domainsignalin(c, (char *)(&((type *)0)->field) - (char *)0)
                                                          ^ ~~~~~~~~~
1 warning generated.
++++ info: linking objects in grambipan.pd_darwin for lib grambidec~
cc -undefined suppress -flat_namespace -bundle  -arch arm64 -mmacosx-version-min=10.6  -o grambipan.pd_darwin grambipan.pd_darwin.o  -lc   
ld: warning: -undefined suppress is deprecated
ld: warning: -undefined suppress is deprecated
++++info: target all in lib grambidec~ completed

This is my Makefile:

# Makefile for mylib

lib.name = grambidec~

class.sources = grambidec.c grambiman.c grambipan.c

datafiles = grambilib-help.pd readme.md

include Makefile.pdlibbuilder

Any suggestion? Thanks again!

internally phasor~ uses something like 32-bit fixed-point. So the comparative error is really introduced when multiplying by the buffer size I guess.

Also looking at what I think is the Phasor code, it looks to me like it outputs 64-bit doubles.. https://github.com/supercollider/supercollider/blob/137cb4cd56f5bdf4484c9ad6761d4724dc8d7818/server/plugins/TriggerUGens.cpp#L134

I think the difference is that the output of Phasor is already scaled and output as a 64-bit value before being converted to 32-bit whereas when using phasor~ it is output as 32-bit and also scaled from range 0-1 as a 32-bit by multiplying by buffer size

If there were a Phasor equivalent in pd it might be comparable..
(and that also seems to be the case if [rpole~] gives similar results)
[vline~] should work as well

@fishcrystals said:
'Darwin-amd64-32'

huge apologies - you need ones that say Darwin-arm64-32 - it's so easy to confuse them when they are called amd64-32 (intel mac/x86_64, for non macs this is most computers as well) not Amd

you need Arm - also sometimes called arm64, aarch64, M1, M2

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)