@ludnny said:

• how to query the file name of the abstraction that contains the numbox?
• how to find the right line in the .pd file? using the XY coords of the

sorry for distraction, didn't read about your workflow carefully enough.
ddw_music's approach might be it.

parsing could help to replace all the boxes in collection of patches you already have made.
just make a self-contained abstraction (with [nb-box\ and bang |o| on a graph-on-parent) and replace all the gatoms with the abstraction's name in .pd files.
even easier to do with a batch-file, text editor, or anything with "find/replace" function.

All connections should remain. .

@whale-av said:

there will be no messages to intercept, as the control chain is built within the Pd binary as the patch is loaded.

The tcl gui and pd core (on Windows: wish86.exe and pd.exe ?) are networking and it should be possible to sniff this.

@whale-av do you have a running example of interconnecting Pd and Iannix?

I can think of these ways to archive that:

a ) Use "find", "cut" ect dynamic messages to parse sth and replace it with sth known.
b ) Parse saved .pd files as txt (https://forum.pdpatchrepo.info/topic/13863/some-patches-won-t-open-was-why-vanilla-fails-at-reading-some-purr-data-patches/8 as simple example, this patch is parsing

#N canvas 

c ) Compile this: https://lists.puredata.info/pipermail/pd-list/2002-09/008215.html

d ) Keep track while patching with IEMguts [receivecanvas] (Would be needed for each canvas. But I can't find a way to find and read gatom properties that are already in the patch.)

Cleanest should be b ) and c ).

For the usecase you are describing, b ) might be reasonable.

I am highly interested in c) for total freedom, even for live-patching.

Also maybe ask again in the mailing list, as this is a questions going into the guts of Pd.

Please report back how you are proceeding.

... for basic prototyping, if you don't have any install around. by @cuinjune

purrdata.glitch.me

https://github.com/cuinjune/purr-data

I see, all kinds of precision errors in every stage. Didn't know [vline~] was calculating in double-precision. Thank you!

And didn't see your 2nd edit:

@seb-harmonik.ar said:

edit2: personally I use my own sine tables if I want really clean sine waves because the ones pd uses internally still sound a bit gritty to me sometimes, I think they use 512 points and I usually end up using tables that use 2048 or 4096 points

Here is a rather messy patch comparing different tables and interpolations I started to make a while ago, maybe worth sharing here:

Bigger tables are more robust against precision errors (offset) of their driving inputs.
With offset, [cyclone/cycle~] has same few artefacts for smaller as for bigger arrays (hmm..might be a bug I did?).
[osc~] is the cheapest sine.
[cyclone/cycle~] has non-expected costs with different interpolations.
My linear interpolation is different than cyclone's in results and very expensive (due to vanilla patching!?).
At an offset above [+~ 1023], with [cos~] and 512-point-table called $0-cos-GOOD, there is a sudden increase of artefacts .(due to bit-depth!!?)

puresine.zip

There might be bugs. Sorry for the mess, too boring cleaning up this time.

@seb-harmonik.ar said:

the error might be present at that point already..

yes, it might be a precision-thing.

Comparing Pd's [cos~]ine-table with [tabread4~ $0-cos-GOOD] from this patch:
https://github.com/pure-data/pure-data/issues/105
(see https://forum.pdpatchrepo.info/topic/13709/bug-osc-cos-circle-asymmetry-drifting-out-of-phase )

Driving them with a large number added, same artefacts appear.

Offtopic, but
without any addition [+~ 0] $0-cos-GOOD is slightly cleaner:

Sounds unaliased to me

< -90 dB we can't hear that.

Does that make sense ?

no

@gentleclockdivider said:

I guess it's just a matter of preference of using a comparator or S/H

Don't want to stop you from doing so. But keep in mind that [phasor~] is not accumulating in a reliable way: Recording and reading the floats in an array you can see, due to precision, it accumulates non-predictably and rarely counts to 1 or starts from 0.
If you want reliable, steady precision, [samplehold~] is the way to go.

The quoted paper in the sources explains [phasor~] in depth:
https://github.com/pure-data/pure-data/blob/7f87e06a97db50a4c46af236e8bd41534d005bfa/src/d_osc.c#L53

B11.sampler.nodoppler

Wondering if Vanilla's documentation comes with Plugdata?
Highly recommended to read into it!

@KMETE I think you're looking for the 'set' prefix

Since pd vanilla version 52 there is that new list-atom-box in the put menu or at ctrl+4 .
Works for lists, symbols, floats ...

it gets trickier if you need special characters like commas and dollars-es inside the box

@ddw_music said:

@oid said:

@ddw_music Control+ will make them twice as large...

And then you can fit about 10 objects going down on a typical laptop screen, not enough to do anything interesting.

With zoom mode on and changing font size to 8, objects are shrinking and the ratio between obejct size and io size changes.

EDIT:
and in pd-gui.tcl
https://github.com/pure-data/pure-data/blob/20334410c20948f14f5c1d8ae5ed992717b83291/tcl/pd-gui.tcl

you can edit the font size even smaller, which helps but ratios between GUIs and messages/objects actually get messed up:

# sizes as above for zoomed-in view
set font_zoom2_metrics {
    10 19
    12 26
    14 32
    20 38
    28 58
    44 88
}

looks like this with zoom in and font size 8:

@ddw_music said:

Does anyone know offhand where to hack the hot zone size, so that maybe one does not have to have superhuman precision?

searching sources for

mouse 

I found in https://github.com/pure-data/pure-data/blob/20334410c20948f14f5c1d8ae5ed992717b83291/tcl/pd-gui.tcl

            # mouse cursors for all the different modes

[...]

            set ::cursor_editmode_connect "circle"

.
Then searching for

cursor_editmode_connect 

I found probably relevant
https://github.com/pure-data/pure-data/blob/c4ae1bd8df436de15c0a80f303ae33b5f3569088/src/g_editor.c

  /* look for an outlet */
            else if (hitobj && (noutlet = obj_noutlets(hitobj)) &&
                ypos >= y2 - (OHEIGHT*x->gl_zoom) + x->gl_zoom)
            {
                int width = x2 - x1;
                int iow = IOWIDTH * x->gl_zoom;
                int nout1 = (noutlet > 1 ? noutlet - 1 : 1);
                int closest = ((xpos-x1) * (nout1) + width/2)/width;
                int hotspot = x1 +
                    (width - iow) * closest / (nout1);
                if (closest < noutlet &&
                    xpos >= (hotspot - x->gl_zoom) &&
                    xpos <= hotspot + (iow + x->gl_zoom))
                {
                    if (doit)
                    {

[...]

/* not in an outlet; select and move */

---

...Searching the sources for IOWITH
or better OHEIGHT
has this result among others:

https://github.com/pure-data/pure-data/blob/5462d1eae0ad9f139997d56d459c212e797d96be/src/g_canvas.h

* --------------------- geometry ---------------------------- */
#define IOWIDTH 7       /* width of an inlet/outlet in pixels */
#define IHEIGHT 3       /* height of an inlet in pixels */
#define OHEIGHT 3       /* height of an outlet in pixels */
#define IOMIDDLE ((IOWIDTH-1)/2)
#define GLIST_DEFGRAPHWIDTH 200
#define GLIST_DEFGRAPHHEIGHT 140

#define GLIST_DEFCANVASXLOC 0
#ifdef __APPLE__
#define GLIST_DEFCANVASYLOC 22
#else
#define GLIST_DEFCANVASYLOC 50
#endif 

---

---

.

(Not sure how the apparently different size of inlets and outlets hot area is coded? Inlets appear to be 'magnetic'. )

---

---

---

---

Wish there was a shortcut to open objects-help.

Could belong here:
https://github.com/pure-data/pure-data/blob/90ad8005199605095e49dbbf1daf4f032211b7f4/tcl/pd_bindings.tcl

not the only one. That is the reason, I am patching with zoom mode on small screen. Still missing the hot area by times.

Also wish we could just draw connections across multiple objects/messages by simply drawing the cable across them + pressing hot key.
Also wish we could grab a cable at one end to change connection.
Wish there was a shortcut to open objects-help.
Wish autocompletition-plugin would run stable (it has hiccups and even crashes pd when closing a window occasionally).

this is how olli~ looks here:

olli~.pd
olli~-help.pd
EDIT
uses Cyclone's [delay~ 1 1]
Vanilla would be [rzero_rev~ 0]

Thank you very much @jameslo
this patch means something else to me!!!

Your tri to ramp conversion by mirroring the falling part of the triangle by *~ -1 seems to be the definitive answer and by the screenshot I do understand visually.

Yes, it must have been the sh-flip-flop in my patch, somehow flipping or flopping one way or another around, - only wondering why that is not the case on your machine, here a 180° shift happens a lot actually.

Anyway...
Thank you very very much!

EDIT:

[phasor~]
|
[cos~]

should be the same as
[osc~]

but this time I need to measure the phase of [osc~]
and do the same as

with [osc~] instead of [phasor~].

I have a running patch, but sometimes it flips the phase by 180 degrees.
Do you know why or how to avoid that?

Here is the patch:
phase_of_normalized_cosine~.pd

The patch calculates the phase of a normalized cosine y(x) by
asin(y(x)) / (pi/2)
this is a triangle wave, following cosine's shape linearized.
Then a tri-to-saw waveshper:
invert the falling part of the triangle
and divide it's frequency by 2.

@alexandros said:

But if you think, the execution order goes like this: the object that sends audio to its outlet does its computations before the object that receives the audio signal. If you make a feedback connection, which object is supposed to make its computations first?
To achieve this you have to send the output of [cos~] to a [tabsend~] (don't disconnect it from [*~ 0.4]), and connect a [tabreceive~] to [delwrite~]. Also, if you want feedback in your delay, you'll need to do this in the same way, so use another pair of [tabsend~]/[tabreceive~] to connect the output of [delwrite~] back to its input.

By using a [delwrite~] [delread~] or [delread4~] pair, the DSP loop is already detached, - you won't need [tabsend~] [tabreceive~] additionaly. You can use either or to break the loop.

Make sure that the whole chain feeding (and including) [delwrite~] is written in the .pd file before [delread4~],
(Check .pd file in a text editor. In Pd you can select > cut > paste parts of the patch, to change the order) -
then you will be able to go as low as min 1 sample delay.

You can measure latency with this latency-tester2.pd
https://forum.pdpatchrepo.info/topic/13814/catch-would-like-to-set-the-name-programmatically/20

A thread on this topic:
https://forum.pdpatchrepo.info/topic/6185/feedback-fm-algorithm

Expert Sleepers i/o have a range of 20 Vpp, ideal for Eurorack.

An explanation of [donecanvasdialog( for canvas properties, including and most important graph-on-parent:

@Maelstorm wrote:

You can use [donecanvasdialog( to change the gop properties. When you right-click on a patch and choose Properties, all of that stuff is contained in the [donecanvasdialog( message. The format is this:

[donecanvasdialog <x-units> <y-units> <gop> <x-from> <y-from> <x-to> <y-to> <x-size> <y-size> <x-margin> <y-margin>(

The gop argument is 0 = gop off; 1 = gop on, show arguments; and 2 = gop on, hide arguments.

And there is a phenomenal patch-demo reposted by @whale-av

https://forum.pdpatchrepo.info/topic/5746/change-graph-on-parent-dimentions-from-inside/2

thx

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:

[compatibility 0.49(
|
[s pd]

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:

input
map from input range to 0 till 1
[pow]
map from 0 till 1 to output range
output

Or use an array?

Would be similar:
draw an array with a transfer-function

input
map to x-size of array
[tabread4]
map from y-range
output