@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:
my guess: upsampling pre-fft could help ?
yes, downloading patches works here.
and a version with simple fix: latency-tester2.pd
To find new adress of broken links to forum threads:
do an online search with "thread title site:pdpatchrepo.info"
The thread about this:
yes, Katja's meter measures 1 sample latency additionally, so real latency is -1 sample.
here are threads of other forums:
and an older comparision:
parts 1 2 3:
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?
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?
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.
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.
[phasor~] [*~ 2] [-~ 1] [abs~]
[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)