According to block~ help, if you bang [switch~] it runs one block of DSP computations, which is useful for performing computations that are more easily expressed as audio processing. Something I read (which I can't find now) left me with the impression that it runs faster than normal audio computations, i.e. as if it were in control domain. Here are some tests that confirm it, I think: switch~ bang how fast.pd

The key to this test is that all of the bangs sequenced by [t b b b b] run in the same gap between audio block computations. When [switch~] is banged, [osc~] fills array1, but you can see that element 63 of array1 changes after [switch~] is banged. Furthermore, no logical time has elapsed. So it appears that one block of audio processing has occurred between normal audio blocks. [bang~] outputs when that accelerated audio block processing is complete.

This next test takes things further and bangs [switch~] 10 times at control rate. Still, no logical time elapses, and [bang~] only outputs when all 10 bangs of [switch~] are complete. [rzero_rev~ 0] is just an arcane way of delaying by one sample, so this patch rotates the contents of array1 10 samples to the right. switch~ bang how fast2.pd

(There are better ways to rotate a table than this, but I just needed something to test with. Plus I never pass up a chance to use [rzero_rev~ 0] )

Finally, I've seen some code that sends a 1 to [switch~] and then sends 0 after one block of processing. In this test you can see that one block of audio is processed in one block of logical time, i.e. the normal way. switch~ bang how fast3.pd

But that second test suggests how you could embed arbitrary offline audio processing in a patch that's not being run with Pd's -batch flag or fast-forwarded with the fast-forward message introduced in Pd 0.51-1. Maybe it's an answer to two questions I've seen posted here: Offline analysis on a song and Insant pitch shift. Here's a patch that writes 20s of 440 Hz to a file as fast as possible (adapted from @solipp's patch for the first topic). You just compute how many blocks you need and bang away. write440File.zip

Here's another that computes the real FFT of an audio file as fast as possible: loadFFT.zip

But as with any control rate processing, if you try to do too much this way, Pd will fall behind in normal audio processing and stutter (e.g. listen to the output while running that last patch on a >1 minute file). So no free lunch, just a little subsidy.

I searched through many of the s~/r~ throw~/catch~ hops in my own code for mistakes based on what I've learned, and it looks like ~50% of all my non-local audio connections carry modulation signals that originate from control rate objects, so those aren't affected much. Only a few programs would have been broken had the non-local connections not matched, but because things were created in signal-flow order where it mattered, there was a consistent (and often unnecessary) 1 block delay everywhere. Many of those patches were later converted to use tabsend~/tabreceive~ under a small block size, and a few were converted to use delay lines. I was burned by the creation order side effect of delwrite~/delread~ once, but it wouldn't have happened had I not taken a lazy shortcut. Hilariously, I also found one test patch that I used to declare definitively, once and for all, that s~/r~ always introduces a 1 block delay if the sort order isn't controlled using the G05 technique. To paraphrase Agent K in the movie Men in Black, imagine what I'll "know" tomorrow!

So as a practical issue, I doubt coders are getting tripped up by this frequently. If you're like me you tend to code in signal flow order, and so you are mostly just introducing latency unnecessarily. RE advice, I agree with @Nicolas-Danet: use local audio connections wherever it matters and never mind the clutter. Even my worst spider web isn't so bad. Subpatches and abstractions can help hide the mess.

But when things are broken and showtime is looming, you'd be foolish not to use what you know, especially when you can always go back after curtain calls and adjust things to satisfy the style police. Here is a summary of the sort rules as best as I've been able to figure them out so far:

• A patch orders its constituent audio subpatches and abstractions, but has no influence over their internal ordering. Consequently, these rules are applied starting at the top level patch and recurse into each subpatch and abstraction.
• Audio chain tributaries and independent audio chains are executed in reverse order of their head's creation, except for those created by [clone], which are executed in the order of their creation (i.e. ascending clone index order).
• Audio branches that start from fanout connections are executed in reverse order of their start connection's creation.
• Whenever the rules conflict, the rule that places the tilde object the latest in line takes precidence.

These sort rules can affect your patch because unless s~ and throw~ buffer their data before their corresponding r~ and catch~ are executed, the latter will have to wait a block to access it. Delread~ will have a minimum 1 block delay.

Finally, I thought of this technique if you're absolutely certain you are going to get burned (or are just paranoid): wrap all s~, r~, throw~, catch~, delwrite~, delread~, and audio chain heads in their own subpatches. I noticed that if you modify the contents of a subpatch, it doesn't change its sort order in the containing patch, so you can add test code (e.g. [sig~ <uniqueNr>]->[tabsend~ <sharedArray>]) to subpatch pairs and check their execution order without changing it. If the order is wrong, then you cut and repaste the appropriate subpatches or audio connections according to the rules above until it isn't. That should take 15 mins, not days.

@jaffasplaffa I recently built my first device, a USB midi footswitch with an arduino. A bit of googling led me to the awesome MIDI Control Surface library.

The main thing to be careful about IMO is to get the right board to communicate directly over USB (Micro, Leonardo, Teensy, see the documentation), otherwise (Uno, Nano) you will need a serial-MIDI converter software like hairless (with GUI) or ttymidi (command line).

For the LED lighting I took inspiration from my other commercial controllers, and set the arduino's code to light up the LEDs by sending a notein and then it off with a noteoff (if you have multiple colors or blinking mode, you can use different velocities, e.g. 36 1 1 for solid green on button 36 (channel 1), 36 2 1 for blinking green, 36 3 1 for red, etc.
You can also hardcode the LEDs status with the buttons status, but you may loose flexibility (especially when using Pd, but it may be more complicated to use a DAW if you have to set up when to light up the LEDs, not sure).

Now I am looking into building another controller with faders and knobs, and there I'll indeed also need multiplexers, as I believe that the bigger Arduino I could find had ~40pins. You will probably need digital pins for the buttons and LEDs, while potentiometers need analog pins (as far as I could understand so far, but I'm also new to this!).

In any case, regardless of how you initially program the arduino (e.g. only notein/noteout to control the LEDs), you can just decide otherwise later on and reprogram it (just like you would update a commercial controller's firmware) to change the note numbers of each button, add special modes to give other functionalities to the same buttons, this kind of things.

Let me know how it goes I'm hoping to get started on mine in 2 weeks or so.

NoxSiren is a modular synthesizer system where the punishment of failure is the beginning of a new invention.

--DOWNLOAD-- NoxSiren for :

• Pure Data :
  NoxSiren v15.rar
  NoxSiren v14.rar

• Purr Data :
  NoxSiren v15.rar
  NoxSiren v14.rar

--DOWNLOAD-- ORCA for :

• x64, OSX, Linux :
  https://hundredrabbits.itch.io/orca

In order to connect NoxSiren system to ORCA system you also need a virtual loopback MIDI-ports:

--DOWNLOAD-- loopMIDI for :

• Windows 7 up to Windows 10, 32 and 64 bit :
  https://www.tobias-erichsen.de/software/loopmidi.html

#-= Cyber Notes [v15] =-#

• added BORG-IMPLANT module.
• introduction to special modules.
• more system testing.

#-= Special Modules [v15] =-#

• BORG-IMPLANT (connects ORCA MIDI system to NoxSiren system)

#-= Current Modules [v15] =-#

• VCO (voltage-controlled-oscillator)
• VCO2 (advance voltage-controlled-oscillator)
• WAVEBANK (additive synthesis oscillator)
• ADSR (Attack-Decay-Sustain-Release envelope)
• C-ADSR (Curved Attack-Decay-Sustain-Release envelope)
• CICADAS (128 steps-Euclidean rhythm generator)
• CICADAS-2 (advance 128-steps polymorphic-Euclidean rhythm generator)
• COMPRESSOR (lookahead mono compressor unit)
• DUAL-COMPRESSOR (2-channel lookahead mono compressor unit)
• STEREO-COMPRESSOR (lookahead stereo compressor unit)
• MONO-KEYS (virtual 1-voice monophonic MIDI keyboard)
• POLY-KEYS-2 (virtual 2-voice polyphonic MIDI keyboard)
• POLY-KEYS-3 (virtual 3-voice polyphonic MIDI keyboard)
• POLY-KEYS-4 (virtual 4-voice polyphonic MIDI keyboard)
• POLY-KEYS-5 (virtual 5-voice polyphonic MIDI keyboard)
• POLY-KEYS-6 (virtual 6-voice polyphonic MIDI keyboard)
• BATTERY (simple manual triggered machine for drumming.)
• REVERB (reverb unit with lowpass control)
• STEREO-REVERB (stereo reverb unit with lowpass control)
• RESIN (advanced rain effect/texture generator)
• NOISE (generates black,brown,red and orange noise)
• NOISE2 (generates yellow,blue,pink and white noise)
• COBALT (6-stage polyrhythm generator)
• SHAPER (basic shaper unit)
• FOLDER (basic wave folding unit)
• STEREO-FOLDER (stereo wave folding unit)
• DUAL-FOLDER (advance wave folding unit)
• POLARIZER (transform a signal into bi-polar, uni-polar, inverted or inverted uni-polar form)
• CLOCK (generates a BPM clock signal for sequencing other modules)
• CLOCKDIVIDER (a clock divider with even division of clock signal)
• CLOCKDIVIDER2 (a clock divider with odd division of clock signal)
• DELAY-UNIT (delay unit)
• STEREO-DELAY (stereo delay unit)
• CHORUS (chorus unit)
• STEREO-CHORUS (stereo chorus unit)
• SEQ (advance 16-step/trigger sequencer)
• KICK (synthesize kick unit)
• KICK2 (synthesize flavor of KICK module)
• KICK3 (synthesize flavor of KICK module)
• SNARE (synthesize snare unit)
• CLAP (synthesize clap unit)
• CYMBAL (synthesize cymbal unit)
• RAND (RNG generator for other modules parameters)
• FMOD (feedback modulation unit)
• AM (amplitude modulation unit)
• RM (ring modulation unit)
• LFO (low-frequency-oscillator)
• LFO2 (advance low-frequency-oscillator)
• COMBINATOR (combine two waves)
• COMBINATOR2 (combine three waves)
• COMBINATOR3 (combine four waves)
• STRING (Karplus-Strong string synthesis unit)
• STRING2 (advance Karplus-Strong string synthesis unit)
• DETUNER (parametric 4-channel detuner unit)
• CRUSHER (basic audio resolution unit)
• STEREO-CRUSHER (basic stereo audio resolution unit)
• DUAL-CRUSHER (advance audio resolution unit)
• FILTER (basic filter)
• VCF (voltage-controlled-filter)
• MAR (Moog-analog-resonant filter)
• VCA (voltage-controlled-amplifier)
• DUAL-VCA (advance voltage-controlled-amplifier)
• FMUX (multiplexer with fast A/D internal envelope)
• MMUX (multiplexer with medium A/D internal envelope)
• SMUX (multiplexer with slow A/D internal envelope)
• FDMX (demultiplexer with fast A/D internal envelope)
• MDMX (demultiplexer with medium A/D internal envelope)
• SDMX (demultiplexer with slow A/D internal envelope)
• MIXER (mix 1-4 possible waves)
• SCOPE (oscilloscope analyzer)
• MASTER (fancy DAC~)
• BOX (useless decorative module)

NoxSiren integrated modules menu system.

JASS, Just Another Synth...Sort-of, codename: Gemini (UPDATED TO V-1.0.1)

jass-v1.0.1( esp with midi fixes).zip

1.0.1-CHANGES:

• Fixed issues with midi routing, re the mode selector (mentioned below)
• Upgraded the midi mode "fetch" abstraction to be less granular
• Fix (for midi) so changing cc["14","15","16"] to "rnd" outputs a random wave (It has always done this for non-midi.)
• Added a midi-mode-tester.pd (connect PD's midi out to PD's midi in to use it)
• Upgrade: cc-56 and cc-58 can now change pbend-cc and mod-cc in all modes
• Update: the (this) readme

INFO: Values setting to 0 on initial cc changes is (given midi) to be expected.

JASS is a clone-based, three wavetable, 16 voice polyphonic, Dual-channel synth.

With...

• The initial, two wavetables combined in 1 of 5 possible ways per channel and then adding those two channels. Example: additive+frequency modulation, phase+pulse-modulation, pulse-modulation+amplitude modulation, fm+fm, etc
• The third wavetable is a ring modulator, embedded inside each mod type
• 8 wave types, including a random with a settable number of partials and a square with a settable dutycycle
• A vcf~ filter embedded inside each modulation type
• The attack-decay-release, cutoff, and resonance ranges settable so they immediately and globally recalculate all relevant values
• Four parameters /mod type: p1,p2, cutoff, and resonance
• State-saving, at both the global level (wavetables, env, etc.), as well as, multiple "substates" of for-each-mod-type settings.
• Distortion, reverb
• Midiin, paying special attention to the use of 8-knob, usb, midi controllers (see below for details)
• zexy-limiters, for each channel, after the distortion, and just before dac~

Instructions

Requires: zexy

for-entire-state

• O: Open preset. "default.txt" is loaded by...default
• S: Save preset (all values incl. the multiple substates) (Note: I have Not included any presets, besides the default with 5 substates.)
• SA: Save as
• TEST: A sample player
• symbol: The filename of the currently loaded preset
• CL: Clear, sets all but a few values to 0
• U: Undo CL
• distortion,reverb,MASTER: operate on the total out, just before the limiter.
• MIDI (Each selection corresponds to a pgmin, 123,124,125,126,127, respectively, see below for more information)
  • X: Default midi config, cc[1,7,8-64] available
  • M: Modulators;cc[10-17] routed to ch1&ch2: p1,p2,cutoff,q controls
  • E: Envelopes; cc[10-17] routed to filter- and amp-env controls
  • R: Ranges; cc[10-17] routed to adr-min/max,cut-off min/max, resonance min/max, distortion, and reverb
  • O: Other; cc[10-17] routed to rngmod controls, 3 wavetypes, and crossfade
  • symbol: you may enter 8 cc#'s here to replace the default [10-17] from above to suit your midi-controller's knob configuration; these settings are saved to file upon entry
• vu: for total out to dac~

for-all-mod-types

• /wavetable
  • graph: of the chosen wavetype
  • part: partials, # of partials to use for the "rn" wavetype; the resulting, random sinesum is saved with the preset
  • duty: dutycycle for the "du" wavetype
  • type: sin | square | triangle | saw | random | duty | pink (pink-noise: a random sinesum with 128 partials, it is not saved with the preset) | noise (a random sinesum with 2051 partials, also not saved)
• filter-env: (self-explanatory)
• amp-env: (self-explanatory)
• rngmod: self-explanatory, except "sign" is to the modulated signal just before going into the vcf~
• adr-range: min,max[0-10000]; changing these values immediately recalculates all values for the filter- and amp-env's scaled to the new range
• R: randomizes all for-all-mod-types values, but excludes wavetype "noise"; rem: you must S or SA the preset to save the results
• U: Undoes R

for-each-mod-type

• mod-type-1: (In all cases, wavetable1 is the carrier and wavetable2 is the modulator); additive | frequency | phase | pulse | amplitude modulation
• mod-type-2: Same as above; mod-type-2 May be the same type as mod-type-1
• crossfade: Between ch1 and ch2
• detune: Applied to the midi pitch going into ch2
• for-each-clone-type controls:
  • p1,p2: (self-explanatory)
  • cutoff, resonance: (self-explanatory)
• navigation: Cycles through the saved substates of for-each-mod-type settings (note: they are lines on the end of a [text])
• CP: Copy the current settings, ie. add a line to the end of the [text] identical to the current substate
• -: Delete the current substate
• R: Randomize all (but only a few) substate settings
• U: Undo R
• cut-rng: min,max[0-20000] As adr-range above, this immediately recalculates all cutoff values
• res-rng: min,max[0-100], same as previously but for q
• pbend: cc,rng: the pitchwheel may be assigned to a control by setting this to a value >7 (see midi table below for possibilities); rng is in midi pitches (+/- the value you enter)
• mod-cc: the mod-wheel may be assigned to a control [7..64] by setting this value

midi-implementation

name	---	Description
sysex		not supported
pgmin		123,124,125,126,127; They set midi mode
notein		0-127
bendin		pbend-cc=7>pitchbend; otherwise to the cc# from below
touch		not supported
polytouch		not supported

cc - basic (for all midi-configs)

#	name	---	desciption
1	mod-wheel		(assignable)
7	volume		Master

cc - "X" mode/pgmin=123

cc	---	parameter
8		wavetype1
9		partials 1
10		duty 1
11		wavetype2
12		partials 2
13		duty 2
14		wavetype3
15		partials 3
16		duty 3
17		filter-att
18		filter-dec
19		filter-sus
20		filter-rel
21		amp-att
22		amp-dec
23		amp-sus
24		amp-rel
25		rngmod-freq
26		rngmod-sig
27		rngmod-filt
28		rngmod-amp
29		distortion
30		reverb
31		master
32		mod-type 1
33		mod-type 2
34		crossfade
35		detune
36		p1-1
37		p2-1
38		cutoff-1
39		q-1
40		p1-2
41		p2-2
42		cutoff-2
43		q-2
44		p1-3
45		p2-3
46		cutoff-3
47		q-3
48		p1-4
49		p2-4
50		cutoff-4
51		q-4
52		p1-5
53		p2-5
54		cutoff-5
55		q-5
56		pbend-cc
57		pbend-rng
58		mod-cc
59		adr-rng-min
60		adr-rng-max
61		cut-rng-min
62		cut-rng-max
63		res-rng-min
64		res-rng-max

cc - Modes M, E, R, O

Jass is designed so that single knobs may be used for multiple purposes without reentering the previous value when you turn the knob, esp. as it pertains to, 8-knob controllers.

Thus, for instance, when in Mode M(pgm=124) your cc send the signals as listed below. When you switch modes, that knob will then change the values for That mode.

In order to do this, you must turn the knob until it hits the previously stored value for that mode-knob.

After hitting that previous value, it will begin to change the current value.

cc - Modes M, E, R, O assignments

Where [10..17] may be the midi cc #'s you enter in the MIDI symbol field (as mentioned above) aligned to your particular midi controller.

cc#	---	M/pgm=124	---	E/pgm=125	---	R/pgm=126	---	O/pgm=127
10		ch1:p1		filter-env:att		adr-rng-min		rngmod:freq
11		ch1:p2		filter-env:dec		adr-rng-max		rngmod:sig
12		ch1:cutoff		filter-env:sus		cut-rng-min		rngmod:filter
13		ch1:q		filter-env:re		cut-rng-max		rngmod:amp
14		ch2:p1		amp-env:att		res-rng-min		wavetype1
15		ch2:p2		amp-env:dec		res-rng-max		wavetype2
16		ch2:cutoff		amp-env:sus		distortion		wavetype3
17		ch2:q		amp-env:rel		reverb		crossfade

In closing

If you have anywhere close to as much fun (using, experimenting with, trying out, etc.) this patch, as I had making it, I will consider it a success.

For while an arduous learning curve (the first synth I ever built), it has been an Enormous pleasure to listen to as I worked on it. Getting better and better sounding at each pass.

Rather, than say to much, I will say this:

Enjoy. May it bring a smile to your face.

Peace through love of creating and sharing.

Sincerely,
Scott

@nicnut said:

I don't know if this helps, but sometimes the audio output level will make the audio sound bad. I have a RPi 4 and I am using a soundcard with a seperate audio output volume knob. And I use the alsamixer.

At first I turned everything up as much as possible. It sounded terrible and sometimes no audio came out. Now I have alsa mixer at about 60% and my soundcard at 80%. I control the volume from my amp and faders in Pd. It sounds way better.

If you are using the 8th inch jack out of the Pi something related to this could be an issue.

@EEight said:

@nicnut A dedicated soundcard is the way to go AFAIK. Also using jack and controlling the buffer (if you don't need low latency then use a big buffer like 1024).

I plugged in a USB audio dongle, and it seemed to stop the crackling but I still get the following audio dropouts

more info on how to set up jack or alsa would be appreciated

[4] error: audio I/O dropout
loading cached help index from ~/.purr-data/search.index
finished loading help index (0.20 secs)
[4] error: audio I/O dropout

I'm running a Raspberry Pi 4 with "Raspberry Pi OS (32-bit) Lite [August 2020 / 2020-08-20 / Kernel 5.4]" headless and the latest version of Purr-Data, set up the Raspberry using this guide , did the Alsa no audio (glitch) issue Pi 4

fix to get audio working through the 3.5 mm jack.

I'm interfacing the Raspberry Pi through the macOS terminal and with VNC Viewer through ethernet.

I get the following error as soon a starting Purr-Data,

error: audio I/O stuck... closing audio 

I open up a patch and turn off and turn on the DSP signals and get the following error

error: audio I/O stuck... closing audio error: audio I/O dropout 

Even though if I play sample .wav or bang a sinewave, the audio does get played but it gets glitchy as in the audio sound is crackled.

has anyone experienced it before? any knowledge on how to overcome it?

mda Delay.vst.zip

[vstplugin~] v0.2.0
WARNING: on macOS, the VST GUI must run on the audio thread - use with care!
searching in '/Users/boonier/Library/Audio/Plug-Ins/VST' ...
probing '/Users/boonier/Library/Audio/Plug-Ins/VST/BreakBeatCutter.vst'... failed!
probing '/Users/boonier/Library/Audio/Plug-Ins/VST/Camomile.vst'... failed!
probing '/Users/boonier/Library/Audio/Plug-Ins/VST/Euklid.vst'... failed!
probing '/Users/boonier/Library/Audio/Plug-Ins/VST/FmClang.vst'... failed!
probing '/Users/boonier/Library/Audio/Plug-Ins/VST/Micropolyphony.vst'... failed!
probing '/Users/boonier/Library/Audio/Plug-Ins/VST/PhaserLFO.vst'... failed!
probing '/Users/boonier/Library/Audio/Plug-Ins/VST/pvsBuffer.vst'... failed!
probing '/Users/boonier/Library/Audio/Plug-Ins/VST/smGrain3.vst'... failed!
probing '/Users/boonier/Library/Audio/Plug-Ins/VST/smHostInfo.vst'... failed!
probing '/Users/boonier/Library/Audio/Plug-Ins/VST/smMetroTests.vst'... failed!
probing '/Users/boonier/Library/Audio/Plug-Ins/VST/smModulatingDelays.vst'... failed!
probing '/Users/boonier/Library/Audio/Plug-Ins/VST/smTemposcalFilePlayer.vst'... failed!
probing '/Users/boonier/Library/Audio/Plug-Ins/VST/smTrigSeq.vst'... failed!
probing '/Users/boonier/Library/Audio/Plug-Ins/VST/SoundwarpFilePlayer.vst'... failed!
probing '/Users/boonier/Library/Audio/Plug-Ins/VST/SpectralDelay.vst'... failed!
probing '/Users/boonier/Library/Audio/Plug-Ins/VST/SyncgrainFilePlayer.vst'... failed!
probing '/Users/boonier/Library/Audio/Plug-Ins/VST/Vocoder.vst'... failed!
found 0 plugins
searching in '/Library/Audio/Plug-Ins/VST' ...
probing '/Library/Audio/Plug-Ins/VST/++bubbler.vst'... failed!
probing '/Library/Audio/Plug-Ins/VST/++delay.vst'... failed!
probing '/Library/Audio/Plug-Ins/VST/++flipper.vst'... failed!
probing '/Library/Audio/Plug-Ins/VST/++pitchdelay.vst'... failed!
probing '/Library/Audio/Plug-Ins/VST/ABL2x.vst'... failed!
probing '/Library/Audio/Plug-Ins/VST/BassStation.vst'... failed!
probing '/Library/Audio/Plug-Ins/VST/BassStationStereo.vst'... failed!
probing '/Library/Audio/Plug-Ins/VST/Camomile.vst'... failed!
probing '/Library/Audio/Plug-Ins/VST/Crystal.vst'... failed!
probing '/Library/Audio/Plug-Ins/VST/Ctrlr.vst'... failed!
probing '/Library/Audio/Plug-Ins/VST/Dexed.vst'... failed!
probing '/Library/Audio/Plug-Ins/VST/Driftmaker.vst'... failed!
probing '/Library/Audio/Plug-Ins/VST/GTune.vst'... failed!
probing '/Library/Audio/Plug-Ins/VST/Independence FX.vst'... failed!
probing '/Library/Audio/Plug-Ins/VST/Independence.vst'... failed!
probing '/Library/Audio/Plug-Ins/VST/JACK-insert.vst'... failed!
probing '/Library/Audio/Plug-Ins/VST/Lua Protoplug Fx.vst'... failed!
probing '/Library/Audio/Plug-Ins/VST/Lua Protoplug Gen.vst'... failed!
probing '/Library/Audio/Plug-Ins/VST/mda Ambience.vst'... failed!
probing '/Library/Audio/Plug-Ins/VST/mda Bandisto.vst'... failed!
probing '/Library/Audio/Plug-Ins/VST/mda BeatBox.vst'... failed!
probing '/Library/Audio/Plug-Ins/VST/mda Combo.vst'... failed!
probing '/Library/Audio/Plug-Ins/VST/mda De-ess.vst'... failed!
probing '/Library/Audio/Plug-Ins/VST/mda Degrade.vst'... failed!
probing '/Library/Audio/Plug-Ins/VST/mda Delay.vst'... failed!
probing '/Library/Audio/Plug-Ins/VST/mda Detune.vst'... failed!
probing '/Library/Audio/Plug-Ins/VST/mda Dither.vst'... failed!
probing '/Library/Audio/Plug-Ins/VST/mda DubDelay.vst'... failed!
probing '/Library/Audio/Plug-Ins/VST/mda DX10.vst'... failed!
probing '/Library/Audio/Plug-Ins/VST/mda Dynamics.vst'... failed!
probing '/Library/Audio/Plug-Ins/VST/mda ePiano.vst'... failed!
probing '/Library/Audio/Plug-Ins/VST/mda Image.vst'... failed!
probing '/Library/Audio/Plug-Ins/VST/mda Leslie.vst'... failed!
probing '/Library/Audio/Plug-Ins/VST/mda Limiter.vst'... failed!
probing '/Library/Audio/Plug-Ins/VST/mda Looplex.vst'... failed!
probing '/Library/Audio/Plug-Ins/VST/mda Loudness.vst'... failed!
probing '/Library/Audio/Plug-Ins/VST/mda MultiBand.vst'... failed!
probing '/Library/Audio/Plug-Ins/VST/mda Overdrive.vst'... failed!
probing '/Library/Audio/Plug-Ins/VST/mda Piano.vst'... failed!
probing '/Library/Audio/Plug-Ins/VST/mda RePsycho!.vst'... failed!
probing '/Library/Audio/Plug-Ins/VST/mda RezFilter.vst'... failed!
probing '/Library/Audio/Plug-Ins/VST/mda RingMod.vst'... failed!
probing '/Library/Audio/Plug-Ins/VST/mda RoundPan.vst'... failed!
probing '/Library/Audio/Plug-Ins/VST/mda Shepard.vst'... failed!
probing '/Library/Audio/Plug-Ins/VST/mda Splitter.vst'... failed!
probing '/Library/Audio/Plug-Ins/VST/mda Stereo.vst'... failed!
probing '/Library/Audio/Plug-Ins/VST/mda SubBass.vst'... failed!
probing '/Library/Audio/Plug-Ins/VST/mda TestTone.vst'... failed!
probing '/Library/Audio/Plug-Ins/VST/mda ThruZero.vst'... failed!
probing '/Library/Audio/Plug-Ins/VST/mda Tracker.vst'... failed!
probing '/Library/Audio/Plug-Ins/VST/mda Transient.vst'... failed!
probing '/Library/Audio/Plug-Ins/VST/mda VocInput.vst'... failed!
probing '/Library/Audio/Plug-Ins/VST/mda Vocoder.vst'... failed!
probing '/Library/Audio/Plug-Ins/VST/mdaJX10.vst'... failed!
probing '/Library/Audio/Plug-Ins/VST/mdaTalkBox.vst'... failed!
probing '/Library/Audio/Plug-Ins/VST/ME80v2_3_Demo.vst'... failed!
probing '/Library/Audio/Plug-Ins/VST/Metaplugin.vst'... failed!
probing '/Library/Audio/Plug-Ins/VST/MetapluginSynth.vst'... failed!
probing '/Library/Audio/Plug-Ins/VST/Molot.vst'... failed!
probing '/Library/Audio/Plug-Ins/VST/Nektarine.vst'... failed!
probing '/Library/Audio/Plug-Ins/VST/Nektarine_32OUT.vst'... failed!
probing '/Library/Audio/Plug-Ins/VST/Nithonat.vst'... failed!
probing '/Library/Audio/Plug-Ins/VST/Obxd.vst'... failed!
probing '/Library/Audio/Plug-Ins/VST/Ozone 8 Elements.vst'... failed!
probing '/Library/Audio/Plug-Ins/VST/PlogueBiduleVST.vst'... failed!
probing '/Library/Audio/Plug-Ins/VST/PlogueBiduleVST_16.vst'... failed!
probing '/Library/Audio/Plug-Ins/VST/PlogueBiduleVST_32.vst'... failed!
probing '/Library/Audio/Plug-Ins/VST/PlogueBiduleVST_64.vst'... failed!
probing '/Library/Audio/Plug-Ins/VST/PlogueBiduleVSTi.vst'... failed!
probing '/Library/Audio/Plug-Ins/VST/PlogueBiduleVSTi_16.vst'... failed!
probing '/Library/Audio/Plug-Ins/VST/PlogueBiduleVSTi_32.vst'... failed!
probing '/Library/Audio/Plug-Ins/VST/PlogueBiduleVSTi_64.vst'... failed!
probing '/Library/Audio/Plug-Ins/VST/sforzando.vst'... failed!
probing '/Library/Audio/Plug-Ins/VST/Sonic Charge/Cyclone FX.vst'... failed!
probing '/Library/Audio/Plug-Ins/VST/Sonic Charge/Cyclone.vst'... failed!
probing '/Library/Audio/Plug-Ins/VST/Soundtoys/Devil-Loc.vst'... failed!
probing '/Library/Audio/Plug-Ins/VST/Soundtoys/LittlePlate.vst'... failed!
probing '/Library/Audio/Plug-Ins/VST/Soundtoys/LittleRadiator.vst'... failed!
probing '/Library/Audio/Plug-Ins/VST/Soundtoys/SieQ.vst'... failed!
probing '/Library/Audio/Plug-Ins/VST/SPAN.vst'... failed!
probing '/Library/Audio/Plug-Ins/VST/Spitter2.vst'... failed!
probing '/Library/Audio/Plug-Ins/VST/Surge.vst'... failed!
probing '/Library/Audio/Plug-Ins/VST/Synth1.vst'... failed!
probing '/Library/Audio/Plug-Ins/VST/TAL-Chorus-LX.vst'... failed!
probing '/Library/Audio/Plug-Ins/VST/TAL-Reverb-2.vst'... failed!
probing '/Library/Audio/Plug-Ins/VST/TAL-Reverb-3.vst'... failed!
probing '/Library/Audio/Plug-Ins/VST/TAL-Reverb-4.vst'... failed!
probing '/Library/Audio/Plug-Ins/VST/TAL-Sampler.vst'... failed!
probing '/Library/Audio/Plug-Ins/VST/TX16Wx.vst'... failed!
probing '/Library/Audio/Plug-Ins/VST/u-he/Diva.vst'... failed!
probing '/Library/Audio/Plug-Ins/VST/u-he/Protoverb.vst'... failed!
probing '/Library/Audio/Plug-Ins/VST/u-he/Repro-1.vst'... failed!
probing '/Library/Audio/Plug-Ins/VST/u-he/Repro-5.vst'... failed!
probing '/Library/Audio/Plug-Ins/VST/u-he/Satin.vst'... failed!
probing '/Library/Audio/Plug-Ins/VST/u-he/TyrellN6.vst'... failed!
probing '/Library/Audio/Plug-Ins/VST/u-he/Zebra2.vst'... failed!
probing '/Library/Audio/Plug-Ins/VST/u-he/Zebralette.vst'... failed!
probing '/Library/Audio/Plug-Ins/VST/u-he/Zebrify.vst'... failed!
probing '/Library/Audio/Plug-Ins/VST/u-he/ZRev.vst'... failed!
probing '/Library/Audio/Plug-Ins/VST/UltraChannel.vst'... failed!
probing '/Library/Audio/Plug-Ins/VST/ValhallaFreqEcho.vst'... failed!
probing '/Library/Audio/Plug-Ins/VST/ValhallaRoom_x64.vst'... failed!
probing '/Library/Audio/Plug-Ins/VST/VCV-Bridge-fx.vst'... failed!
probing '/Library/Audio/Plug-Ins/VST/VCV-Bridge.vst'... failed!
probing '/Library/Audio/Plug-Ins/VST/WaveShell1-VST 10.0.vst'... failed!
found 0 plugins
searching in '/Users/boonier/Library/Audio/Plug-Ins/VST3' ...
found 0 plugins
searching in '/Library/Audio/Plug-Ins/VST3' ...
probing '/Library/Audio/Plug-Ins/VST3/TX16Wx.vst3'... error
couldn't init module

probing '/Library/Audio/Plug-Ins/VST3/WaveShell1-VST3 10.0.vst3'... error
factory doesn't have any plugin(s)

probing '/Library/Audio/Plug-Ins/VST3/Nektarine.vst3'... failed!
probing '/Library/Audio/Plug-Ins/VST3/Nektarine_32OUT.vst3'... failed!
probing '/Library/Audio/Plug-Ins/VST3/OP-X PRO-II.vst3'... failed!
probing '/Library/Audio/Plug-Ins/VST3/SPAN.vst3'... failed!
probing '/Library/Audio/Plug-Ins/VST3/Surge.vst3'... failed!
probing '/Library/Audio/Plug-Ins/VST3/Zebra2.vst3'...
[1/4] 'Zebrify' ... failed!
[2/4] 'ZRev' ... failed!
[3/4] 'Zebra2' ... failed!
[4/4] 'Zebralette' ... failed!
found 0 plugins
search done
print: search_done

@Nicolas-Danet said:

control messages and compute audio vectors of the DSP graph are interleaved operations. The internal audio vector size is 64.

[64][control][64][control][64][control][64][control]

Ok, i see.
But I read control messages are first, then audio. f.e. [loadbang] is proceeded before an upcoming audio-block.
And [vline~] is calculated and "drawn" before and "modulating" the *following * audio blocks.

[control][64][control][64][control][64][control][64]

What's happen in a 1 sample reblocked subpatch? In short, instead of compute 1 vector of 64 samples, it computes 64 times following a vector of 1 sample.

And there is no way to change this interval rate of 64?
Is upsampling in a subpatch increasing the computation time-interval of control-messages?

The tricky stuff with real time audio is not to do the things fast, but do things fast at the right time. Wait the sound in, deliver the sound out, compute the next sound and wait. When i benchmark my fork for instance, most of the time is spent in sleeping!

I see. In the analog world it is very different. This is why we have the buffer-latency in digital everywhere:

...incoming audio-samples in blocks, computation, audio out, and again...

And the control-domain every 64 samples.
For me as "user" of PD this is confusing.
So every object with a [v ...] will be sampleaccurate on point in upcoming audio-blocks, as long as it is not needed more often then 64 samples later!??? i.e. as long it is not starting several times in a smaller interval then 64 samples?

Hello,

this is going to be a long one.
After years of using PD, I am still confused about its' timing and schedueling.

I have collected many snippets from here and there about this topic,
-wich all together are really confusing to me.

*I think it is very important to understand how timing works in detail for low-level programming … *

(For example the number of heavy jittering sequencers in hard and software make me wonder what sequencers are made actually for ? lol )

This is a collection of my findings regarding this topic, a bit messy and with confused questions.

I hope we can shed some light on this.

---

• a)
  The first time, I had issues with the PD-scheduler vs. how I thought my patch should work is described here:
  https://forum.pdpatchrepo.info/topic/11615/bang-bug-when-block-1-1-1-bang-on-every-sample

The answers where:

„
[...] it's just that messages actually only process every 64 samples at the least. You can get a bang every sample with [metro 1 1 samp] but it should be noted that most pd message objects only interact with each other at 64-sample boundaries, there are some that use the elapsed logical time to get times in between though (like vsnapshot~)
also this seems like a very inefficient way to do per-sample processing..
https://github.com/sebshader/shadylib http://www.openprocessing.org/user/29118
seb-harmonik.ar posted about a year ago , last edited by seb-harmonik.ar about a year ago 
• 1 
 whale-av 
@lacuna An excellent simple explanation from @seb-harmonik.ar.
Chapter 2.5 onwards for more info....... http://puredata.info/docs/manuals/pd/x2.htm
David.
“

There is written: http://puredata.info/docs/manuals/pd/x2.htm

„2.5. scheduling 
Pd uses 64-bit floating point numbers to represent time, providing sample accuracy and essentially never overflowing. Time appears to the user in milliseconds. 
2.5.1. audio and messages 
Audio and message processing are interleaved in Pd. Audio processing is scheduled every 64 samples at Pd's sample rate; at 44100 Hz. this gives a period of 1.45 milliseconds. You may turn DSP computation on and off by sending the "pd" object the messages "dsp 1" and "dsp 0." 
In the intervals between, delays might time out or external conditions might arise (incoming MIDI, mouse clicks, or whatnot). These may cause a cascade of depth-first message passing; each such message cascade is completely run out before the next message or DSP tick is computed. Messages are never passed to objects during a DSP tick; the ticks are atomic and parameter changes sent to different objects in any given message cascade take effect simultaneously. 
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. 
2.5.2. computation load 
The Pd scheduler maintains a (user-specified) lead on its computations; that is, it tries to keep ahead of real time by a small amount in order to be able to absorb unpredictable, momentary increases in computation time. This is specified using the "audiobuffer" or "frags" command line flags (see getting Pd to run ). 
If Pd gets late with respect to real time, gaps (either occasional or frequent) will appear in both the input and output audio streams. On the other hand, disk strewaming objects will work correctly, so that you may use Pd as a batch program with soundfile input and/or output. The "-nogui" and "-send" startup flags are provided to aid in doing this. 
Pd's "realtime" computations compete for CPU time with its own GUI, which runs as a separate process. A flow control mechanism will be provided someday to prevent this from causing trouble, but it is in any case wise to avoid having too much drawing going on while Pd is trying to make sound. If a subwindow is closed, Pd suspends sending the GUI update messages for it; but not so for miniaturized windows as of version 0.32. You should really close them when you aren't using them. 
2.5.3. determinism 
All message cascades that are scheduled (via "delay" and its relatives) to happen before a given audio tick will happen as scheduled regardless of whether Pd as a whole is running on time; in other words, calculation is never reordered for any real-time considerations. This is done in order to make Pd's operation deterministic. 
If a message cascade is started by an external event, a time tag is given it. These time tags are guaranteed to be consistent with the times at which timeouts are scheduled and DSP ticks are computed; i.e., time never decreases. (However, either Pd or a hardware driver may lie about the physical time an input arrives; this depends on the operating system.) "Timer" objects which meaure time intervals measure them in terms of the logical time stamps of the message cascades, so that timing a "delay" object always gives exactly the theoretical value. (There is, however, a "realtime" object that measures real time, with nondeterministic results.) 
If two message cascades are scheduled for the same logical time, they are carried out in the order they were scheduled. 
“ 

[block~ smaller then 64] doesn't change the interval of message-control-domain-calculation?,
Only the size of the audio-samples calculated at once is decreased?
Is this the reason [block~] should always be … 128 64 32 16 8 4 2 1, nothing inbetween, because else it would mess with the calculation every 64 samples?
How do I know which messages are handeled inbetween smaller blocksizes the 64 and which are not?

How does [vline~] execute?
Does it calculate between sample 64 and 65 a ramp of samples with a delay beforehand, calculated in samples, too - running like a "stupid array" in audio-rate?

While sample 1-64 are running, PD does audio only?

[metro 1 1 samp]  

How could I have known that? The helpfile doesn't mention this. EDIT: yes, it does.
(Offtopic: actually the whole forum is full of pd-vocabular-questions)
How is this calculation being done?
But you can „use“ the metro counts every 64 samples only, don't you?

Is the timing of [metro] exact? Will the milliseconds dialed in be on point or jittering with the 64 samples interval?
Even if it is exact the upcoming calculation will happen in that 64 sample frame!?

---

• b )
  
  There are [phasor~], [vphasor~] and [vphasor2~] … and [vsamphold~]
  https://forum.pdpatchrepo.info/topic/10192/vphasor-and-vphasor2-subsample-accurate-phasors

“Ive been getting back into Pd lately and have been messing around with some granular stuff. A few years ago I posted a [vphasor.mmb~] abstraction that made the phase reset of [phasor~] sample-accurate using vanilla objects. Unfortunately, I'm finding that with pitch-synchronous granular synthesis, sample accuracy isn't accurate enough. There's still a little jitter that causes a little bit of noise. So I went ahead and made an external to fix this issue, and I know a lot of people have wanted this so I thought I'd share. 
[vphasor~] acts just like [phasor~], except the phase resets with subsample accuracy at the moment the message is sent. I think it's about as accurate as Pd will allow, though I don't pretend to be an expert C programmer or know Pd's api that well. But it seems to be about as accurate as [vline~]. (Actually, I've found that [vline~] starts its ramp a sample early, which is some unexpected behavior.)
[…]
“

---

• c)
  
  Later I discovered that PD has jittery Midi because it doesn't handle Midi at a higher priority then everything else (GUI, OSC, message-domain ect.)

EDIT:
Tryed roundtrip-midi-messages with -nogui flag:
still some jitter.
Didn't try -nosleep flag yet (see below)

---

• d)
  
  So I looked into the sources of PD:

scheduler with m_mainloop()
https://github.com/pure-data/pure-data/blob/master/src/m_sched.c

And found this paper

Scheduler explained (in German): 

https://iaem.at/kurse/ss19/iaa/pdscheduler.pdf/view

wich explains the interleaving of control and audio domain as in the text of @seb-harmonik.ar with some drawings
plus the distinction between the two (control vs audio / realtime vs logical time / xruns vs burst batch processing).
And the "timestamping objects" listed below.

And the mainloop:

Loop
- messages (var.duration)
- dsp (rel.const.duration)
- sleep

With
[block~ 1 1 1]
calculations in the control-domain are done between every sample? But there is still a 64 sample interval somehow?
Why is [block~ 1 1 1] more expensive? The amount of data is the same!? Is this the overhead which makes the difference? Calling up operations ect.?

---

Timing-relevant objects
from iemlib:

[...]
iem_blocksize~   blocksize of a window in samples
iem_samplerate~  samplerate of a window in Hertz 


------------------ t3~ - time-tagged-trigger --------------------
-- inputmessages allow a sample-accurate access to signalshape --
t3_sig~          time tagged trigger sig~
t3_line~         time tagged trigger line~


--------------- t3 - time-tagged-trigger  ---------------------
----------- a time-tag is prepended to each message -----------
----- so these objects allow a sample-accurate access to ------
---------- the signal-objects t3_sig~ and t3_line~ ------------
t3_bpe           time tagged trigger break point envelope
t3_delay         time tagged trigger delay
t3_metro         time tagged trigger metronom
t3_timer         time tagged trigger timer

[...]

What are different use-cases of [line~] [vline~] and [t3_line~]?
And of [phasor~] [vphasor~] and [vphasor2~]?

When should I use [block~ 1 1 1] and when shouldn't I?

[line~] starts at block boundaries defined with [block~] and ends in exact timing?
[vline~] starts the line within the block?
and [t3_line~]???? Are they some kind of interrupt? Shortcutting within sheduling???

---

• c) again)
  

https://forum.pdpatchrepo.info/topic/1114/smooth-midi-clock-jitter/2

I read this in the html help for Pd: 
„
MIDI and sleepgrain
In Linux, if you ask for "pd -midioutdev 1" for instance, you get /dev/midi0 or /dev/midi00 (or even /dev/midi). "-midioutdev 45" would be /dev/midi44. In NT, device number 0 is the "MIDI mapper", which is the default MIDI device you selected from the control panel; counting from one, the device numbers are card numbers as listed by "pd -listdev."
The "sleepgrain" controls how long (in milliseconds) Pd sleeps between periods of computation. This is normally the audio buffer divided by 4, but no less than 0.1 and no more than 5. On most OSes, ingoing and outgoing MIDI is quantized to this value, so if you care about MIDI timing, reduce this to 1 or less.
„

Why is there the „sleep-time“ of PD? For energy-saving??????
This seems to slow down the whole process-chain?

Can I control this with a startup flag or from withing PD? Or only in the sources?

There is a startup-flag for loading a different scheduler, wich is not documented how to use.

---

• e)
  
  [pd~] helpfile says:

ATTENTION: DSP must be running in this process for the sub-process to run. This is because its clock is slaved to audio I/O it gets from us!

Doesn't [pd~] work within a Camomile plugin!?

How are things scheduled in Camomile? How is the communication with the DAW handled?

---

• f)
  
  and slightly off-topic:
  There is a batch mode:
  https://forum.pdpatchrepo.info/topic/11776/sigmund-fiddle-or-helmholtz-faster-than-realtime/9

---

EDIT:

• g)
  I didn't look into it, but there is:
  https://grrrr.org/research/software/

clk – Syncable clocking objects for Pure Data and Max
This library implements a number of objects for highly precise and persistently stable timing, e.g. for the control of long-lasting sound installations or other complex time-related processes.

---

Sorry for the mess!
Could you please help me to sort things a bit? Mabye some real-world examples would help, too.