https://www.flucoma.org/

Yes, indeed, just for display.
And polygon surprisingly is the cheapest option of the three.

For interpolation [cyclone/wave~] has more options, such as cubic, spline, Hermite and Lagrange as [tabread4~].

The [open $1, 1( are two successive messages: [open $1( and [1(, where the later is the same as [start(

Many (but not all) objects can update only at block boundaries of Pd's main blocks (fixed blocksize of 64 samples in standard Pd) .

One block of 64 samples at 44,1 kHz samplerate = 64*1second/44.1 kHz=1.451 ms

Use [vline~] instead.

[tabread] instead of [array get] !?
(Long time ago arrays where called tables in Pd.)
Read their helpfiles. You can use [array get] too, but more complicated for this.

In Pd Vanilla, right click on the blank canvas > help shows all build-in objects.

@seb-harmonik.ar 2048 points since Pd version 0.55 :
https://msp.ucsd.edu/Pd_documentation/resources/chapter5.htm#s5.1

There is a mapping equation:
https://forum.pdpatchrepo.info/topic/14355/limiting-amplitude-on-an-lfo/12

And with [mtof] (midi to frequency) you can get that exponential/logarithmic pitch to frequency curve.

@jameslo For me it is difficult to understand. Maybe I am missing the whole point and all I say is off topic.

First of all, I honestly don't understand why your left bang works

click bang [o] (GUI always on block-boundary) > [spigot] opens > [bang~] bangs > [spigot] closes > [vline~] starts (still on same block-boundary).

Similarly, in my first response to you, you can see in the snapshots that the bang from [delay 1.5 64 samp] is being processed during Ctrl 1, 32 samples before its real timing.

This I don't understand.
You use [rpole~ 1] as sample-counter, right? But [snapshot~] only snapshots on block-boundaries. (That's why there is [vsnapshot~], but that was buggy, when I last tried it.) [snapshot~] shows 64 samples, one whole block.
If you snapshot later, you see [del 1.5 64] outputs bang after 96 samples:

([sig~] also updates its output only on block-boundaries, not within the block.)

@seb-harmonik-ar s [pip~] could be done with [bang~] and [timer], to measure the time that has passed into the block.
Or for signalrate~ output~ with [rpole~ 1], to measure the samples past into the block.

you don't need to predict the future to make it one block earlier

So is it correct that you want to move the start of vline~ 'backward' ? To the start of the block? To the start of that block where [del] outputs later on a message to [vline~]?
Clicking [o] bang at ctrl 0 > [del 1] outputs after 1 ms, where audio 0 is happening > [vline~] should have started before, at the beginning of audio 0 ?
Is this what you want?

Here is a paper where message- vs signal-domain and scheduleing are graphed. It is in German, maybe you can use a translator and the time-graphs on the last pages are english / self-explanatory. And you problably already know all of this.
https://iaem.at/kurse/ss19/iaa/pdscheduler.pdf/view

@jameslo Thought that's what you where looking for? 'block-quatizer'?
But you want to move the output of [del 1] back to the start of the block?
Interesting, but I think moving backward is not possible in realtime Pd ... (hmmm there is the [lrshift~] object for moving in a block... )

Edit: My point was that this quantizes to (next) block boundary, and if already at it, it stays there.
[del 0] Breaks the deterministic order ( [t b b] ect.), as [delay] and [pipe] always do, and moves to the last point after everything else deterministic is processed, but keeps at the same logical time (zero delay).
But what was your point?
Edit: Now I tried without [del 0] and everything is the same. So I completely missed your point??

@jameslo said:

In the middle of a message cascade you may schedule another one at a delay of zero. This delayed cascade happens after the present cascade has finished, but at the same logical time".

Man, this got me excited because the only reason my bang quantizer outputs where it does and not one block earlier is because [bang~] for the end of the first block has already executed by the time my spigot opens and so we have to wait for the next audio block to complete. I was hoping [delay 0] would cause the bang from [bang~] to be rescheduled after my spigot opens, but it doesn't appear to.

That works, screenshot when left bang is clicked:

vline~blockquantizer.pd

(thought [bang~] would be expensive, that's why I [switch~]ed it in the other patch.)

@jameslo said:

Is there a way to zero out that bang timing attribute, so that the bangs are quantized to block boundaries? Or some other way to force [vline~] to start at the beginning of the next audio block?

Like this?
vline~onnextblockboundary.pd

Edit: it's not just bangs that have that intra-block timing attribute--you can see in my example that it's preserved through the message that's sent to [vline~]

As far as I understand it now, some objects
([metro] [del] [pipe] [vline~] maybe[vsnapshot~])
do intra-block-messaging/banging and some won't (like [tabwrite~] in my patch).

The scheduler processes GUI and Midi i/o at block-boundaries.

I am highly interested in how to sync or interface Reaper or other DAW with PD control rate sample-accurately intra-blocks.

since Pd-list got an update in August 2024 it has moved? and links are broken. Not a big issue, as we can sill find it lists.iem.at

Also IEM has list of Vanilla objects page online:
https://pd.iem.sh/objects/

@porres the "garbage-filter" since 0,49, as it won't show abstractions w/o helpfile. And the hiccup.

@SCFan32 My recommendation for learning Pd is keeping it straight Vanilla and go the way @whale-av proposed: Learn the list of objects Vanilla vocabulary and learn thinking in Vanilla, instead of searching for objects. This would be the low-level Pd-Vanilla way.

From what I have glimpsed SC is not so very low-low level.

Searching objects of libraries can be done in Deken. Help > Find externals
or deken.puredata.info where ctrl+f full text search helps, too.

There are some libraries that make easy high-level patching possible. But the bigger they are, and the more libs you use, the more you have to search for objects.

Searching this forum: https://forum.pdpatchrepo.info/topic/11732/commands-for-forum-search-engine/2
Where in many cases newer posts are more valid, because Pd-Vanilla has developed a lot and solved many issues, added more objects ect.
(keeping backward-compability).

Mabye

[symbol]
|
[float]

does the trick?

Pobably it is not encoded as float but neither has no symbol selector.
A symbol without 'symbol' selector looks like a float but isn't.

(btw there is [int] but ints are floats in pd)

I currently don't have Else lib installed, so no definetive answer, also I don't know those Else objects and did not look into their help-files ... only answering because noone did (EDIT well now I'm late), but looking at your patch:

• [print] helps debugging such things!
• After [list prepend amp] you might need [list trim] to remove the 'list' selector from the message (check with [print]).
• Cut the connection between [multi.vsl] and [bpbank~] !? Or why are they connected?
• Vanilla-ways to build such a message as [amp 0 2 0 2 ( would be:

@dmanz sorry, I was wrong in a rush and corrected my last post now:

[t b a] not [t a b]
it is right to left order,
first set the message (anything) then bang.

@dmanz have a look at the messages-helpfile.

Commata in messages separate messages,
so

#anything here
|
[set open $1, bang( 
|
[willbeovewritten(
|
[print]

are two successive messages
[set open $1( and [bang(
same as

#anything here
|
[t b a]
||
|[set open $1(
||
[willbeoverwritten (
|
[print]

Delaying the bang with [del] breaks the deterministic order of operation!
Usually this is bad practice.
(Althought sometimes required, if you need exact timing or have to mess with other rare non-deterministic operations, such as [readsf~] loading from harddrive (Pd 0.55) f.e.)

As you have mentioned, you can compose messages with lists, too.

#anything here
|
[list prepend set]
|
[list trim]
|
[t b a]
|/
[willbeoverwritten(
|
[print]

Data type String is called Symbol in Pd.
You can cut the Symbol and List prefix / selector of a message with [list trim].

Did anyone find an ideal screen size / resolution for Pd yet?

I can not recommend:
14 inch at 1920 x 1080 with 150 % scaling in OS
15,6 inch at 1920 x 1080 with 125% scaling in OS
Either needs zoom-in and there is not much space for patching left.

Ideally the screen would sit below ear-level for great studio acoustics. But I probably have to reject this premise.

(...while waiting for mouse-wheel zoom https://github.com/pure-data/pure-data/pull/1659 )

@Val
https://forum.pdpatchrepo.info/topic/12786/iemlib-in-vanilla-deken-compiling/7

https://forum.pdpatchrepo.info/topic/13613/bessel-linkwitz-riley-butterworth-filter-in-pure-data-vanilla/5