@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: