ctrl+t for messages, too:
https://forum.pdpatchrepo.info/topic/14071/msg-a-message-object-bug-fix

I prefer keyboard over mouse.
Using the shortcuts ctrl+1 or +2 or +3 ect. keeps the flow already being connected.
[bng] [tgl] ect same for GUI objects.

In Windows system settings I have activated this shortcut:
zero on number-pad for click-hold. Although I'd prefer a different key, it is very useful in Pd to avoid arm strains.

And this looks promising:
Keyboard navigation/patching
https://github.com/pure-data/pure-data/pull/869

This one too:
canvas zoom and scroll with mousewheel
https://github.com/pure-data/pure-data/pull/1659

(Wish to connect a whole chain easily by simply dragging a cable across several objects/msgs, without the need to release the mouse-button.)

Also: in editmode ctrl+click on GUI, instead of ctrl+e

essential: hold shift + drag on number box

connections in bezier curves

not in Vanilla, as far as I know, only in other flavours as PurrData, L2Ork or PlugData.
One trick for clean patching is to use the patcher more text-like, with many horizontal lines, as you can see from more advanced users here in the forum (lately here f.e. : https://forum.pdpatchrepo.info/topic/14461/can-an-array-be-used-to-arrange-amplitude-changes/2 )

visualize what's going in the chords (which I remember I had in pd-ext)

I never tried, @svanya has made this:
https://forum.pdpatchrepo.info/topic/13046/a-movable-autoconnnecting-vu-meter-esp-for-debugging-code

and something like insert function (insert the block between two objects when dragging), adaptive chords drawing

Not all, but some are available by "intelligent patching"
https://forum.pdpatchrepo.info/topic/13471/shortcut-replacing-wires

edit/production modes

ctrl+e
learn all the shortcuts

@oid recommended this, I haven't tried yet:
https://github.com/RVirmoors/maxhotkey-pd

hard on PD

@whale-av yes, copying a selceted file in win-file-browser does full path in clipboard...

I think sending via pdsend is slick. And I believe and hope and am interested in if Pd receives it without [netreceive].

Otherwise, opening a [netreceive] patch with a startup-flag (in terminal or preferences or in a script) should do the trick:
https://forum.pdpatchrepo.info/topic/13895/opening-a-patch-inside-another-patch-by-filename/2

Also you could try to
use the terminal to browse,
ctrl+shift+c copy > alt+tab switch over to Pd task > ctrl+o open > ctrl+v paste > enter.

At least this works for me with the Windows file-browser and portable Pd.

read this patch from left to right

a) load a directory with sound files
b ) add more files if you want
c) connect this to the outlet:

[open $1, start(
|
[readsf~]
|
[dac~]

d) bang the random file player.

Your [clone] idea would be the way to go!
@Obineg said in Chords (polyphony) as arrays/lists:

if you code your own external at one point you always have to iterate the list into single values.

And have a look into the help-file of [clone]: Adress clone instances with the first number of a list or with next in a serial manner.

Instead you could send the whole list to all and in each instance cut-out the snipped of interest by getting the instance-# with [f $1] and cut-out with two [list split]s.

Maybe upload your non-working clone-version and we can fix it.

In your hard-coded patch only [mtof] and [phasor~] or only [phasor~] are required to duplicate, - sum all the [phasors~] into one [lop~] ect.

Maybe use [poly], if you like it.

Also, there are many examples of polyphonic synths floating around, in the patch-subforum for example.

Did not look into your patch, but this outputs random filenames, stored in a [text]

random-sound-file-from-dir.pd

@ddw_music said:

there is a need for an arbitrary-format [pipe]. Does such a thing exist?

maybe [text sequence]

unpackOSC handles timestamps, but also outputs each message immediately

Ports and networking introduce jitter: the stream out of [netreceive] jitters. This is where timestamps come in handy:
Buffering, and comparing timestamps to a steady (and delayed) clock eliminates jitter.

https://forum.pdpatchrepo.info/topic/8850/pure-data-sdif-and-resynthesis

@bobpell sounds like a new bug species.
Does it happen 1/4 times by just new patch > save > close > reopen?

Please give more info on your screen and GPU setup? Screensaver? Are there other things running doing sth related to the screen?
Does it happen after waking up or hybernating > saving the patch > reopening?

@jameslo the bigger the window,
the higher the frequency-resolution,
and the lower time-resolution are becoming !?

@Blair blocksize=windowsize, isn't it the same?
not sure if this is correct:

resynth-smear.pd

my guess: upsampling pre-fft could help ?

yes, downloading patches works here.
...uploading... latency-tester.pd

and a version with simple fix: latency-tester2.pd
https://forum.pdpatchrepo.info/topic/13814/catch-would-like-to-set-the-name-programmatically/20

To find new adress of broken links to forum threads:
do an online search with "thread title site:pdpatchrepo.info"

The thread about this:
https://forum.pdpatchrepo.info/topic/11464/any-mirror-of-old-forum-puredata-hurleur-com

yes, Katja's meter measures 1 sample latency additionally, so real latency is -1 sample.

here are threads of other forums:

https://forum.rme-audio.de/viewtopic.php?id=23459
linking to
https://web.archive.org/web/20160315074034/https://www.presonus.com/community/Learn/The-Truth-About-Digital-Audio-Latency

and an older comparision:
parts 1 2 3:
https://original.dawbench.com/audio-int-lowlatency.htm

https://gearspace.com/board/music-computers/618474-audio-interface-low-latency-performance-data-base.html

the patch looks legit:

in Real Life latency occurs in every part: converter, port, driver / os, pd.

Linux can be set up to be very responsive on audio with realtime-priority ect. (how can this be done in Win?)

USB(1 and 2) introduces 1 or 2 ms of fixed latency.
RME pci(e) cards are the fastest hardware and drivers you can get (Linux too). Marian could be sameish (no Linux, last time I asked).

Today there are USB3 / Thunderbold, too - but don't know about their latency.

If you have headroom, 96k should be faster.

Because of the complexity of the chain, I would be surprised if latency would be same anytime, or to put it differently:
If the patch relies on it, I'd do the measurement each time on startup (with a free io channel or switching patchbay), even more in a live-concert. But empiricism on your system could disprove it, - and now I realize that this actually is your question, but no, I can not share experience on reliability of latency in Windows.

@jameslo which post of katjav are you referring to?
Recurrently there has been some conversation about latency on the pd-list.

i want to validate an idea before making it in hardware

Beware there are differences in analog and digital world.
Pd is probably not the right tool for this. Better use analog circuit simulation, such as LTspice?

https://forum.pdpatchrepo.info/topic/13409/how-can-i-create-a-switchable-filter/3

https://forum.pdpatchrepo.info/topic/13621/20-mode-pole-mixing-and-morphing-filter-updated

@Coalman
To give you even more options:

If you want to patch everything in PD but no hardware change, you could connect an old laptop, or Bela (Beagle Board) or Pi and Arduino via USB (as virtual serial port) and use Firmata or PDuino (available in Deken) to access Arduino's GPIOs from PD.
Not sure if this is the case for the async PWM. (But you could add that function as exception on the Arduino side with input from serial.)

What speed is the PWM? Higher than audio Niquist (probably yes)?
Else you could just do PWM in PD.

Most, if not all popular (micro)controllers provide asynchronous PWM-pins today. Read the datasheets.

Did you already search your answers?
https://forum.bela.io/d/1009-basic-pwm-question/
https://forum.pdpatchrepo.info/topic/12112/raspberry-pi-gpio-and-puredata-does-it-work/
https://github.com/owenosborn/rpi_gpio

There should be many examples for, PD <-> GPIOs on Bela, as this is what it's all about.

reason for this inefficiency is that my knowledge is fairly limited on these platforms.

Maybe decide for one board (or an old laptop with comport) for all projects, and grow with it.

@ato said:

alternating between channels and treating them as 4 mono systems

A static multichannel installation? Sound is not panning across the speakers? Strictly alternating on/off, not panned in-between?
What is your wish for Pd? Please elaborate.

EDIT fixed the mapping equation

don't understand but maybe this helps:

[mtof] and [mtof~] conversion from midi-note-value to Hz

equation for linear mapping:

y = ( (c-d) / (a-b) ) * (x-a) + c

where x is input
a-b input range
c-d output range.

triangle~

[phasor~] 
[*~ 2] 
[-~ 1] 
[abs~] 

vanilla square~

[phasor~]
[-~ 0.5]
[*~ 1e+30]
[clip~ -1 1]

splitting a signal at zero-crossing would be

[min~ 0] [max~ 0]

(there might occur aliasing at the output... if this is too noisy maybe oversample, and or filter it or use a bandlimited waveform)

@esaruoho wrote:

16 "LFOs" to "breathe" up and down the volume slider

How does your modulation LFO look like?
Is the modulator a signal or control-object?
Does it offset or master the fader ?

Did you try what I mentioned in your other thread?
https://forum.pdpatchrepo.info/topic/14291/need-a-simpler-way-to-change-slider-background-color-when-on-and-off/6

If you update the GUI on each block
= SR/64 = 44100 /64=689 times per second,
this is overkill and is going to drag down performance, even if the two parts run asynchronously.
<25 frames per second should be enough for the GUI.

Setting many faders and their colour once in a while should not cause any trouble. Limiting the update rate might be enough to run stable. (see the patch below)

Benefit from separating GUI- and audio-parts across two PD-instances would be, if the GUI is lagging, audio still runs without drop-outs as PD-instances run asynchronous.

Ideally run the PD-instances on different CPU-cores (and audio in higher priority) by setting this in the operating system.

(btw offtopic, to complicate things even further: in case you are not aware of it:
there is also the [pd~] object, which does simple multithreading, splitting patches across the CPU-cores. But the parts are running synchronous.
Running one instance of Pure Data only, without [pd~], everything runs on one core only.)

For real-time audio a synchronous chain between input and output is important.
So no, unless you know what you are doing, don't split audio into several PD-instances.
(but yes, on different cores with [pd~], in case the audio-part runs out of CPU-time and you don't want to increase latency).

Sth like this is what I thought about in the other thread, slowing down GUI-update-rate with [metro] and [snapshot~]
and detaching it from the deterministic chain with [pipe],
while maintaining signal-rate amplitude modulation:

fader-abstraction.pd
slider-guts.pd

(I don't have Vanilla here right now, and doesn't work on web-PurrData,. But should work on Vanilla, if there is no bug!?)
EDIT: changed [pipe 5] and added [change] and set fader properties to "jump on click"