Nek'Sum - An advanced drone/texture monophonic synthesizer <- [v6.0] + // Mandarin Edition //
Nek'Sum-6 drone/texture monophonic synthesizer is compose of 5 stages :
First stage -> 3 main OSC with noise mixer option and generative synthesis support with 5 types of waves (tri,sqr,saw,supersaw,generative).
Second stage -> Filter stage with morph option and 4 filters types : Pass through, Lowpass, Highpass, Bandpass for the first stage.
Third stage -> 3 LFO (sin,tri,sqr,saw) modulators for the second stage.
Forth stage -> 3 Phasor's for the third stage.
Fifth stage -> 1 Deep Reverb with Lowpass filter for the forth stage.
It is capable of generating a large soundscape of drone/texture sounds inspired by The Doctor.
Thanks to Seven of Nine Nek'Sum is now at version [v6.0]
- Added Mandarin edition after cyber-brainstorming with Jade Chia-Jung [v6.0].
- Translation of the Ancient Egyption logo into obscure dialect of Anquietas language, thanks to Daniel Jackson [v6.0].
- Thanks to Nox cyberart society now the GUI is much better [v5.0].
- Added reset, randomization and resize for the generative synthesis [v5.0].
- Added generative synthesis support for each oscillator [v4.0].
- Added a noise mixer with 4 types of noise for each oscillator (orange,yellow,blue,pink) [v3.0].
- Added a morphing mechanism for filter stage [v3.0].
- This new version has a better GUI interface powered by a Borg-Casimir engine [v2.0].
Project manager : Oma Desala
Programming/UX design : Boran Robert Andrei
QA engineer : Anubis
Generative synthesis system design/Lead engineer : Seven of Nine
DSP engineering : Jade Chia-Jung, The Doctor
Testing/debugging system engineer : Lt. Colonel Samantha Carter
Language consultant : Daniel Jackson
Patch Download Mandarin Edition :
Nek'Sum 6 - Mandarin Edition.rar
Mandarin special edition :
JASS, Just Another Synth...Sort-of, codename: Gemini
JASS, Just Another Synth...Sort-of, codename: Gemini
JASS is a clone-based, three wavetable, 16 voice polyphonic, Dual-channel synth.
- 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~
- 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~
- 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
- 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
|pgmin||123,124,125,126,127; They set midi mode|
|bendin||pbend-cc=7>pitchbend; otherwise to the cc# from below|
cc - basic (for all midi-configs)
cc - "X" mode/pgmin=123
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.
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.
Crackled Audio from PD on Raspberry Pi 4
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?
Lower limit to phasor~ frequency?
@yannseznec there is a limit in precision for any finite numerical representation. However, for floating point that becomes more complicated to calculate. The relevant code is
x->x_biginc = (x->x_target - x->x_value)/(t_float)nticks; x->x_inc = x->x_1overn * x->x_biginc;
and in the dsp function:
x->x_1overn = 1./sp->s_n;
so the inc will be (target value - current value)/(total time in samples). Time in samples will be rounded to the block size. I believe whether or not this number will increment the line~ depends on how big or small the current value of the line~ is. (again, it's complicated since it's floating point).
for instance if the current value of line~ is 1 then inc would have to be less than 2^-24 to not be able to increment I think. this would correspond to going from 1 to 2 over 16777216 samples, or ~6 minutes 20 seconds @ 44100 samplerate. (so you couldn't go from 1 to 2 any slower than that and have it represent the correct values within the block). Every time the value of line~ doubles so does the smallest representable increment.
however, line~ also uses the biginc variable, which means that after every block it will be able to update using a bigger increment. This means that line~ will still be able to increment up to blocksize times more than that calculation ^ after every block, though values inside every block would be the same. (so ~6 hours 46 minutes @ blocksize 64 according the above calculation I think)
if going from 0 to 1 all of those values would be doubled (it could represent increments corresponding to twice that time, bounded by the lowest representable increment that corresponds to going from 0.5 to 1)
there are other considerations of precision as well. If the increment can only be represented with a certain number of binary digits when added to the current value then there will be round-off errors in the values generated. (but if you need values of that precision you would have round-off errors somewhere else anyways probably)
another numerical bound on the use of line~ is the use of an int to represent ticksleft. If we assume this is a 32-bit signed integer then there can only be 2,147,483,647 blocks, which is ~36 days @ 44100 samplerate and a blocksize of 64. (this would be longer than whatever limitation the floating-point would impose tho I think)
this is all assuming that the size pd uses for samples and floats are 32-bit floating point. If pd is compiled to use 64-bit doubles instead then all of those values would be 2^29 times longer
edit: actually, looking at the code vline~ does use doubles for everything, so if you need really long ramps you should have no problem if you use vline~ instead of line~, even in normal non-double pd. It would take a time longer than 6,472 years for a vline~ going from 1 to 2 to stop being able to increment within a block of 64 samples @ 44.1k. (and a time of 414216 years to stop incrementing at all across blocks)
In the case of vline~ the bounding factor of precision might be in the representation of time actually since it doesn't use ticksleft
edit 2: it couldn't represent incrementing ~1.45 ms which is the time for a block of 64 @ 44100 samples if the current time were ~ 2^53 ms, which would be 9007199254740992, or 285,421 years before stopping to work completely.
long story short: you should be able to use vline~ (but not line~) for ramps of at least a few years long (depending on the range of its values) before it stops incrementing within a block. For the specific case of going from 0 to 1 @ 44.1k, you should be able to run a vline~ for ~129,000 years before it stops incrementing within a block (though it would still increment between blocks)
@EMR66 As explained, you will never be able to write an audio file at a precise length without changing the sample rate for each and every wave frequency.
[writesf~] is working correctly but your requirement cannot be satisfied (in any software..... see above).
If your requirement for a precise (time length) of file is for some purpose outside of Pd then you will never solve your problem.
If you read the file back into Pd (or any other software) it can be interpolated and play correctly.
It will also be possible to analyse the wave, as it is a single frequency, and print the time that you expect.
Pd is maybe the only software that would make that solution fairly easy to program.
But if you expect to write an audio file of a calculated precise length for every possible frequency then you will have to change the sample rate for every frequency and they will all have to be resampled for playback which will impact sample precision.
So once again, what is the purpose of your required "precise" length of file?
There will probably be a way to achieve the same thing, but writing an audio file of "precise" duration will not be possible and you are wasting effort trying to do so.......
BlurPD - digital logic framework system for Pure Data [v3]
BlurPD is a framework system to extend Pure Data with the ability to make
digital logic circuits while taking advantage of the DSP capabilities of Pure Data. In order to design and simulate interesting circuits, ASIC chips, DSP processors or entire CPU's, all in Pure Data. It is made from jucy fundamental modules (Lego blocks) that when put together turn Pure Data into a madness of bits ...
Bug Fixes & Notes [v3]
- GATES : not,and,nand,or,nor,xor,xnor,cfg,icfg,dna,ro,and3,or3,nand3,nor3,xor3,xnor3
- PLEXERS : 2x1multiplexer,1x2demultiplexer,1x2decoder
- MATH : adder,subtractor,multiplier,divider,comparator,comparator2
- IC : bpd1g8n (integrated 8xNAND gates)
- TOOLS : redled,blueled,greenled,yellowled,magentaled,cyanled,sigv,pininv,gateanalyer
- WIRING : pininput,pinoutput,pin0,pin1,dipswitch,idipswitch
- MODULES : the core library for BlurPD built-in modules
- ICMODULES : the core library for "IC" modules
- DSP : btom,sin~,pha~,ipha~,cos~
- DSPTOOLS : scope~
New Stuff [v3]
- Changes to the Help system. Better GUI and integration [v3]
BlurPD archive (older versions)
Multibit modules for more complex circuits [v3]
4-bit Boran-Tsung function using a 4-bit ALU (arithmetic logic unit) circuit made with BlurPD [v3]
4-bit Xi'n function using a 4-bit ALU circuit made with BlurPD [v3]
Snapshot of the modules system and help system [v3]
Making generative sounds using new DSP modules [v2.9]
Polymorphic circuit [v2.7]
Application 1 of BlurPD system from [v2.3]
Application 2 of BlurPD system from [v2.3]
Hexadecimal display [v2.3]
The Ancients [v2.2]
Complex analysis using a DIP-switch analyzer [v2.1]
DIPSwitch from [v2.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!
[1/4] 'Zebrify' ... failed!
[2/4] 'ZRev' ... failed!
[3/4] 'Zebra2' ... failed!
[4/4] 'Zebralette' ... failed!
found 0 plugins
PD's scheduler, timing, control-rate, audio-rate, block-size, (sub)sample accuracy,
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.
The first time, I had issues with the PD-scheduler vs. how I thought my patch should work is described here:
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~]
“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.) […] “
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.)
Tryed roundtrip-midi-messages with -nogui flag:
still some jitter.
Didn't try -nosleep flag yet (see below)
So I looked into the sources of PD:
scheduler with m_mainloop()
And found this paper
Scheduler explained (in German):
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
[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.?
[...] 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)
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.
[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?
and slightly off-topic:
There is a batch mode:
I didn't look into it, but there is:
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.
[pix_share_read] and [pix_share_write] under windows
@whale-av, here is a log running pd with -lib Gem -verbose.
tried both 32bit and 64bit pd 0.48-1...
tried ./Gem.m_i386 and failed tried ./Gem.dll and failed tried ./Gem/Gem.m_i386 and failed tried ./Gem/Gem.dll and failed tried ./Gem.pd and failed tried ./Gem.pat and failed tried ./Gem/Gem.pd and failed tried C:/Users/Raphael Isdant/Documents/Pd/externals/Gem.m_i386 and failed tried C:/Users/Raphael Isdant/Documents/Pd/externals/Gem.dll and failed tried C:/Users/Raphael Isdant/Documents/Pd/externals/Gem/Gem.m_i386 and failed tried C:/Users/Raphael Isdant/Documents/Pd/externals/Gem/Gem.dll and failed tried C:/Users/Raphael Isdant/Documents/Pd/externals/Gem.pd and failed tried C:/Users/Raphael Isdant/Documents/Pd/externals/Gem.pat and failed tried C:/Users/Raphael Isdant/Documents/Pd/externals/Gem/Gem.pd and failed tried C:/Users/Raphael Isdant/AppData/Roaming/Pd/Gem.m_i386 and failed tried C:/Users/Raphael Isdant/AppData/Roaming/Pd/Gem.dll and failed tried C:/Users/Raphael Isdant/AppData/Roaming/Pd/Gem/Gem.m_i386 and failed tried C:/Users/Raphael Isdant/AppData/Roaming/Pd/Gem/Gem.dll and failed tried C:/Users/Raphael Isdant/AppData/Roaming/Pd/Gem.pd and failed tried C:/Users/Raphael Isdant/AppData/Roaming/Pd/Gem.pat and failed tried C:/Users/Raphael Isdant/AppData/Roaming/Pd/Gem/Gem.pd and failed tried C:/Program Files/Common Files/Pd/Gem.m_i386 and failed tried C:/Program Files/Common Files/Pd/Gem.dll and failed tried C:/Program Files/Common Files/Pd/Gem/Gem.m_i386 and failed tried C:/Program Files/Common Files/Pd/Gem/Gem.dll and failed tried C:/Program Files/Common Files/Pd/Gem.pd and failed tried C:/Program Files/Common Files/Pd/Gem.pat and failed tried C:/Program Files/Common Files/Pd/Gem/Gem.pd and failed tried D:/pd-0.48-1.windows.64bit/extra/Gem.m_i386 and failed tried D:/pd-0.48-1.windows.64bit/extra/Gem.dll and failed tried D:/pd-0.48-1.windows.64bit/extra/Gem/Gem.m_i386 and failed tried D:/pd-0.48-1.windows.64bit/extra/Gem/Gem.dll and succeeded D:\\pd-0.48-1.windows.64bit\\extra\\Gem\\Gem.dll: couldn't load tried D:/pd-0.48-1.windows.64bit/extra/Gem.pd and failed tried D:/pd-0.48-1.windows.64bit/extra/Gem.pat and failed tried D:/pd-0.48-1.windows.64bit/extra/Gem/Gem.pd and failed tried D:/pd-0.48-1.windows.64bit/doc/5.reference/Gem.m_i386 and failed tried D:/pd-0.48-1.windows.64bit/doc/5.reference/Gem.dll and failed tried D:/pd-0.48-1.windows.64bit/doc/5.reference/Gem/Gem.m_i386 and failed tried D:/pd-0.48-1.windows.64bit/doc/5.reference/Gem/Gem.dll and failed tried D:/pd-0.48-1.windows.64bit/doc/5.reference/Gem.pd and failed tried D:/pd-0.48-1.windows.64bit/doc/5.reference/Gem.pat and failed tried D:/pd-0.48-1.windows.64bit/doc/5.reference/Gem/Gem.pd and failed Gem: can't load library```
Getting chaos-0.2 to run in Purr Data