NoxSiren - Modular synthesizer system <- [v15]
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: esp with midi fixes)
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
vstplugin~ 0.2.0
[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
PD's scheduler, timing, control-rate, audio-rate, block-size, (sub)sample accuracy,
@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?
PD's scheduler, timing, control-rate, audio-rate, block-size, (sub)sample accuracy,
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.
Getting chaos-0.2 to run in Purr Data
edit: solved
Midi controller not seen by Pd, but seen by system. Rpi3. Pd .49
@alexandros Thank you for your reply! Interesting. This worked. I had to launch Pd first then type in: aconnect 'Your Controller Name':0 'Pure Data':0
And that worked for Pd to receive midi data from my controller, but it didn't work for my controller to get messages from Pd (I have leds on my controller).
After some research I found aconnectgui, which is a gui to make midi connections.
After you install it you can launch it by typing aconnectgui in the terminal.
So I could connect everything that way, but that still won't work for me as I am going to use my Pi headless.
After more googling, I found I can just type the name of the midi client number in aconnect to make my connections. So for me that was:
aconnect 20:0 128:0
this connected my controller (20) to Pd (128)
To get Pd's midi out to my controller I had to do:
aconnect 128:1 20:0
Took a while but I figured it out.
Also, If my controller is plugged in when I turn on the Pi it is client number 20. If I plug it in later it's another number, so to keep it consistent I will always plug it in before i turn on the Pi.
It seems there is no way to save all these connections in Pd correct? My controller still is not showing up in the midi menu of Pd. So I guess I have to create a shell script or something to be fired up after Pd launches. If there is a way to save these setting in Pd please let me know.
Thank you for your help. If I can figure out this last bit I'll be set.
Midi controller not seen by Pd, but seen by system. Rpi3. Pd .49
Hi,
First of all I want to say thank you to this forum community. I have been doing Pd for a few years, so still total newbie, but I have made a lot of progress due to the immeasurable amount of knowledge and help from this community.
I got a disk image from this thread:
https://forum.pdpatchrepo.info/topic/11626/pd-48-on-raspberry-pi-3/14
I have a Raspberry Pi 3, running Pure Data .49.
In my previous disk image Pd automatically recognized my midi controller. But in this new one Pd does not see my controller at all. I saw another post detailing my exact problem, but it was not solved. I would guess that others that must be having this problem, or that it will be coming up going forward. I'll go into detail, but this thread details a very similar issue:
https://forum.pdpatchrepo.info/topic/11485/rpi-no-midi-input-or-output-found
Also, my disk image has Jack installed on it. After spending hours trying to figure out Jack, and qjackctlm (with zero success), I thought I would just ask here. I'd rather not use Jack if possible as everything was works fine without it on my other disk image.
When I launch Pd, with my midi controller plugged in, it does not recognize it. Either in OSS-Midi or ALSA.
In the terminal, if I run: amidi -l
I see my controller MIDI/MOCA for LUFA MIDI 1
So I think everything is fine with the Pi.
If I run: pd -listdev in terminal I see my midi controller being recognized as an audio input and output device, but it says:
no midi input devices found
no midi output devices found
so it does not see my interface as a midi device
Any suggestions at all on my to get Pd to see my midi controller? I'm kind of stuck and have tried everything I can think of.
Thank you again for any input.
rPi no midi input or output found
I've been doing a bunch of experiments with PD on a Raspberry Pi, with custom-built MIDI control via a Teensy microcontroller. I've been using Raspbian lite with no GUI. This was working really well until recently.
For various reasons I updated my Raspberry Pi to the latest Raspbian (Stretch) which also allowed me to get a slightly more decent build of PD, 0.47.1.
Since doing that I can't seem to get any MIDI input in PD, no matter what startup flags I use. Most tellingly, if I run pd -nogui -listdev
I get the following list:
audio input devices:
- bcm2835 ALSA (hardware)
- bcm2835 ALSA (plug-in)
- Teensy MIDI (hardware)
- Teensy MIDI (plug-in)
audio output devices: - bcm2835 ALSA (hardware)
- bcm2835 ALSA (plug-in)
- Teensy MIDI (hardware)
- Teensy MIDI (plug-in)
API number 1
no midi input devices found
no midi output devices found
--
I find it very odd that it lists my Teensy MIDI device as an audio input and output, and also says that no midi input or output devices have been found. It is somewhat understandable that my patches will not therefore recognise any midi activity, but I don't understand why PD isn't seeing the MIDI devices.
If I run aconnect -o
I can see that the Raspberry Pi recognises the device:
client 14: 'Midi Through' [type=kernel]
0 'Midi Through Port-0'
client 20: 'Teensy MIDI' [type=kernel,card=1]
0 'Teensy MIDI MIDI 1'
and if I run aseqdump -p 20
the MIDI data comes streaming through normally. I'm interpreting this to mean that the MIDI device is working, and the alsamidi system is working on the rPi. My only explanation is that something has changed in PD 0.47.1 to create this bug?
I am thinking about starting from scratch and installing Raspbian Jessie instead to test and see if this works, but I'd like to avoid that if possible! Any ideas?
Audio Settings for multichannel with MOTU 828 mk3
Hi Matthieu,
I see your post is a little bit old but I'm experiencing the exact same problem now with my setup.
I'm using a Windows 7 machine with a MOTU 828x sound card connected via USB to the PC and Pd 0.48.1 vanilla.
Here what I've done:
- I've checked the "Use Stereo Pairs for Windows Audio" inside the "MOTU Audio Console";
- opened PD and selected "standard MMIO" as driver from the "Media" menù;
- now here's the list of outputs as it appears from the drop-down menu of "Media/Audio Setting.../Output device":
- MOTU Analog 3-4
- Loudspeakers (devide High ...
- MOTU Main-Out 1-2
- MOTU ADAT optical A 3-4
- Digital Output MOTU Audio
- MOTU ADAT optical A 1-2
- MOTU Analog 1-2
- MOTU ADAT optical A 7-8
- MOTU ADAT optical B 3-4
- MOTU Analog 7-8
- MOTU Analog 5-6
- Digital Output
- MOTU SPDIF 1-2
- MOTU ADAT optical B 1-2
- MOTU ADAT optical A 5-6
- MOTU Phones 1-2
As you see this list is pretty messed up and the names of logical consecutive output channels are not consequential. I would like to have 8 analog outputs from my MOTU so I selected the first item on the list (MOTU analog 3-4) then specified a total of 22 channels.
I'm obliged to set 22 as the total number of output channels because in my list MOTU Analog 5-6 are the last analog elements present. Because items in the list represent pairs of channels, this item corresponds to logical channel 21 and 22.
- Then I created the dac object this way:
[dac~ 13 14 1 2 21 22 19 20]
Here's an image
This way I'm able to hear sound on all analog outputs of the MOTU even if I'm experiencing variuous 'clicks' and a series of "resyncing audio" messages inside the PD console...
I confess, this method is the only way I'm able to make this setup work but it seems to me to be pretty messy and not intuitive at all.
What seems to be even worse is that analog audio outputs inside the device list seems to change their order at each computer restart, so every time I have to restart from scratch.
- Is there some easier solution to this problem?
- Maybe a preference file I can create for PD to load at each startup containing all these settings?
- or there may be a way to programmatically select correct "analog outputs" from the device list in my patch (even if string parsing doesn't seem to be so easy in PD to me).
- Would launching PD from console, maybe from an ad-hoc script, solve the problem?
Thank you so much for your support
M