I have never been there but:
py/pyext does not support Python >=3 yet
@shakfu wrote on Discord:
I have just updated my fork of Garth Zeglin's pdpython, an alternative python external for puredata. His original project is very cool but seems abandoned with no updates for 7 years. My fork makes the code python3 compatible and also updates the build system to use pd-lib-builder. Check it out if you are interested: https://github.com/shakfu/pdpython
Also try sending the compatibility message to Pd with the version you have been using years ago:
didn't really look into your patches, but will reply anyway:
I would like to be able modify the output value to an exponential or logarithmic curve where you can set the curve steepness.
[pow] needs an incoming range between 0 and 1 for this.
You could cascade mapping/scaling:
map from input range to 0 till 1
map from 0 till 1 to output range
Or use an array?
Would be similar:
draw an array with a transfer-function
map to x-size of array
map from y-range
the Max patch looks like feedback-FM to me. For PM the + would be placed between phasor and circle, if I'm not mistaken.
And with 1000 ms delay, as I read the Max patch? there would be no need for 1 sample-blocks.
There are threads on this topic:
DC-blocking you can do with [hip~ 20] for example (I'd put it in the feedback-loop).
[cos~] ? Is a cosine-tabel, to get a sine you can drive it like this:
Offtopic: Pd's cosine has a slight DC-offset.
Creating a one-sample delay is achieved by placing your objects in a subpatch and putting a
[block~ 1]object in there. Then you have to use
[delread~]to achieve the one-sample delay.
Yes. And be aware of the importance of creating [tabsend~] beforehand of [tabreceive~] . You can read about in the Pd documentation 3.audio.example > G05.execution.order.pd
For feedback, I usually build subpatches with such a dummy-connection, save the patch, and delete the dummy cable lastly and save again, for perceving the execution order and avoiding a dsp-loop.
[delwrite~] and [delread~] can become as short as 1 sample, too.
In both [osc~] and [phasor~], the phase is set by control messages, but since you'll have a one-sample block size, that shouldn't be a problem, you can just set the phase to what ever you like and it will be reset at the next sample block (one sample later).
This is one of the biggest myths in Pd (at least for me), but unfortunately not true. (Vanilla 52.2)
See vphasor~-help : https://github.com/dotmmb/mmb
Still the same, if you put it in a subpatch with [block~ 1].
Documentation is lacking here. There are very few timing- sample- or phase-critical control-objects that are able to update (sub-)sample-accurately in-between block-boundaries of 64 samples minimum:
I only know of [bang~], [metro], [delay], [pipe], [vline~]
there is a simple mapping abstraction:
unlike common Pd conventions, all its' inlets are hot, you might change that.
thank you for these collections!
not dynamaic patching but still useful: list-view of an array
found this by accident in the mailing-list. How could I have known?
[r pd] and [r arrayname] [print] won't work for this.
seems like a full-text search through the sources for
finds all those (internal) messages to vanilla-objects, arrays and such !?