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.

Hello!
I’ve been working on a sound installation that records your voice on a public space and then plays it back on a FM radio transmitter.

Since then, I’ve been searching for different voice activity detection (VAD) algorithms for Pure Data and found very little.
So far, my best lead is this article: https://medium.com/linagoralabs/voice-activity-detection-for-voice-user-interface-2d4bb5600ee3

So I thought I’d share my simple algorithm for VAD in public spaces and ask:

How would you approach detecting voice activity in real-time in a public space with a lot of noises and non-voice signals?

Here's my patch: VAD.pd

a few people who have joined Netpd sessions have asked about how to adapt their patches to work within the system...
according to the git page:

• Create your own instrument by typing '/new mysupersynth' into
  unpatch's symbol box. A new instrument named 'mysupersynth'
  shows up in unpatch's instrument list. Edit mysupersynth.pd and
  save it. You might want to check existing instruments to get an
  idea of how to cook your own instrument. There will be section
  about this topic on http://www.netpd.org/docs .
  NOTE: instruments belong to netpd/instruments, their abstractions to
  netpd/instruments/abs.

@4ZZ4 did you try to right-click on objects that you don't understand and opened the corresponding help files? in most cases, the help files contain everything you need to know about object and how it works.... take a look at th help file of [route], it's easy to understand, if you try out the patch and see what it does. regarding th usage of $ variables please read this here: https://booki.flossmanuals.net/pure-data/dataflow-tutorials/dollar-signs.html. [change] only outputs the values reaching it, when they change (so, when it's not the same number as before for example). but thats not all: again - check it's help file and try to play with the object, connet some message boxes with numbers to it's inlet ( for example [1(, [2( ...) and a {print] object to its output and see what getting printed to the console and what happens, when you click one message twice.
the [r chn( sets the midi channel for the [noteout] object... i have to confess, this is not obvious for a beginner: it gets it's value by the message in the maybe2.pd file, which is connected to [loadbang]. the [t b f] or [trigger bang float] cares for, that the addition operation in the [+] object is getting triggered, whenerver one of both inlets receives a value. otherwise, the operation would only be triggered when the "hot inlet" (the left one of [+]) receives a value. voice stealing specifies what happens, if you run out of voices: for ecxample you have a [poly 4 1] -> imagine, you hit a chord on your midi keyboard with 5 keys simultanously -> you run out of voices, because your [poly] is only set to 4 voices (not 5). with the second argument of [poly 4 1] (the 1) you tell poly to begin "overwriting" the oldest voice with the note, that caused running out of voices. sorry for my poor english, i hope you got me. ok, this must be enough for the moment, but you can find all these anwers in the internet or in the help files and the countless pd tutorials out there. please considr making some of these, it will need some time, to learn pd.
ah, and all the infos above come without any warranty!

PS: the "e"-key on my laptop seems to be on strike sometimes!

hey folks! looking for some advice here. i have a custom instrument setup where i can switch between timbres based on a certain key range. there are eight ranges of four MIDI notes each and any one of these regions can be assigned to the base instrument, running on MIDI channel 1, or any one of five other instruments (running on channels 2-6). the switching method basically works as it's supposed to, but there are two strange behaviors

1. if i play quickly it can result in stuck notes as i switch between instruments. i have a method where i can send note off data to instruments via the interface, which mostly works to turn notes off, but not 100% of the time.

2. if i hold a note in one region down assigned to one instrument, and then quickly play another assigned to a different instrument, it will sometimes get confused and apply the sound from the first to the second. so if i have a piano timbre in the first region and play a key assigned to a synth timbre the piano will play notes in the second region as well for a time. i've found that if i play notes in a third different region it resets itself properly and the next time i play the second region it will be properly assigned. so in this case somehow the channel switching seems to be happening too late occasionally.

these bugs can sometimes result in interesting happy accidents, but as i work with it more (as well as playing faster or switching quickly between timbres) i want to have it be more consistent in response.

anyway here's my keyrouter object. the active region is set by the inlet. the output is rearranged to put the channel first so i can route it to the correct instrument. there's probably some kind of race condition that behaves properly when the region and timbre switching is clean (playing more staccato or detached) but if notes are held down or the speed of switching increases it starts dropping noteoffs. any input or info appreciated!

keyrouterTest.pd

@emji It looks like you have made [voice] as an abstraction..... so it is easy.
Make the 4 voices [voice 1] [voice 2] [voice 3] [voice 4] ....... with a space between "voice" and the number.
Then connect the number box to a [s $1-voice_s]
In [voice 1] the send object will become [s 1-voice_s]
In [voice 4] it will become [s 4-voice_s]
See https://forum.pdpatchrepo.info/topic/9774/pure-data-noob/4
David.

Hello,
I'm new with PD. Currently I'm working on an audiovisual project. For that I use a polyphonic synth I found on the patch-repository called SYNTH-0. I uploaded my modified version (for use in purr or l2ork) here.SYNTH-0.5.zip . With it I'm trying to send values to VVVV, which does all the visual part.

Now from this patch I would like to send out 4 numbers of the 4 voice signals as they go through the filter & adsr-envelope. I've gotten pretty far. The problem is the following: the patch uses the "poly"-object, which routes the midi-input 4 times to a subpatch called voice, which then again contains the envelopes and produces an output.


Within "voice" I attached a number-box and an object to send to my sending subpatch, which transfer data to VVVV via FUDI. The thing is: with that I get numbers for one out of the 4 voice patches, I'd like to receive all 4 of them in a pack however. If I attach a numberbox in a subpatch that is 4 times called the same name but is factually 4 different instances, how does pd make the decision which of the 4 to send out with a send object? Might be that I'm missing out on something fundamental about subpatches. Glad for any help!

Does anybody succeed to transfer models from stk such as https://ccrma.stanford.edu/software/stk/classstk_1_1Saxofony.html to PD but not embedded that pd can use or refer to the classes of stk but by "translating" the physical or mathematical meaning from stk to pd? This should be possible because the elements modelled in stk are available in pd also: delaylines, filters, oscilators,...

However, I did not succeed with blown or bowed instruments just a plugged instruments gave an astonishing natural sound: This one that is from pd:

3.4.2.10 Karplus Strong
http://www.pd-tutorial.com/german/ch03s04.html
(I suppose this is an easy one, because the model does not need to take care about energy that is permanently fed in which happens when you bow or blow)

My idea is to take these instruments as a starting point and create "similar" instruments.

Till now no technique gave such a natural sound as 3.4.2.10, therefore I want to "build" other instruments this way. FM, subtractive, additive synthesis...-nothing really gave warm sounds.
Granular syntesis or "playing" a waveform on the other hand do not give access to properties of an instrument in the way that I could change the material of an instrument.

I already use subpatches to come down to blocksizes of 1 - still no success...
Often just noise.

Thanks
Frank

Hi everyone. I have frequently revised designs for polyphonic envelopes. i've often misunderstood things about vline~ and scheduling voices in such a way to avoid unwanted clicks while also keeping things on time and snappy.

i'd be really happy to know what your methods are for envelopes.

i submit this patch, a reflection on envelope practices and how i address certain challenges. envwork.pd

this patch makes these assertions:

1- because vline~ maintains sample accuracy by scheduling events for the next block, you can switch dsp on in a subpatch with block~ while sending a message to vline~ and the dsp will be active by the start of the vline~ output. This also works if you need to configure a non-signal inlet before triggering a voice. send a message to such an inlet concurrently with a vline~ message and the parameters will update on the block boundary before the vline~ plays.

2- accounting for note stealing can cause issues in a polyphonic patch. if the stealing note has a slow attack and the envelope of the stolen note is not closed, there will be a click as the pitch of the new note jumps. the voices in my patch apply slight portamento to smooth out this click. if, however, the attack time of the stealing note is faster than this slight portamento it is counterproductive and will soften the attack of stolen notes. Stolen notes need every bit of snap they can get because the envelopes may be starting at a non-zero value. so i limit the time of the portamento to the attack time.

3- to make sure a note that is still in its release phase is treated as a stolen note, it is necessary to monitor the state of the envelopes like so:

switching the dsp off too close to the end of the release causes clicks. after testing, my system liked a full 50ms of extra delay after the end of a release before it was safe to switch off dsp. I don't think this is attributable just to the scheduling delay of vline~ but it's a small mystery to me. possibly there's a problem with my voices.

This all gets a little more complex when there are multiple envelopes per voice. The release time that affects the final output of the voice must reset all envelopes to when it is finished and before dsp is switched off. Otherwise an envelope with a long release affecting something like filter frequency can be held at a non-zero value when dsp is switched off and spoil the starting state of the vline~ on a new note.

finally, on vline~ and sample accuracy and timing, let me type out what i believe is the case. i could be wrong about this. if you programmed a synth using line~ for the envelopes, it would be faster than vline~ but not all notes equally faster. all notes would sound at the block boundary. Notes arriving shortly after the last block boundary might take 90% of the block period to sound. notes arriving just before the block boundary might take 10% of the period to sound.

vline~ will always be delayed by 100% of the block boundary. but the events will be scheduled sample-accurately, so the vline~ will trigger at exactly the real time intervals of the input. a synth with line~ envelopes will trigger any two events within a single block at the same time.

this should mean that vline~ envelopes can be accurately delay compensated and stay absolutely true to input timing, in the case of something like a Camomile plugin.

however, if one was to build a synth for something like a raspberry pi that will act as hardware, would it be better to use line~ envelopes and gain a little bit of speed? is the restriction of locking envelopes to block boundaries perceptible under normal playing conditions?! i could test some midi input and see if the notes in a chord ever achieve a timing spread greater than the block period anyway...

Hello,
we are working on an interactive sound-installation. It is a wooden bell that opens vertically by sliding up it´s segments to make space for one person that sits down to listen to a guided meditation after the bell closes again. It´s all about the perception of one self and how it changes when one isolates from society and vision. The people will hear themselves over headphones and be instructed by a voice to make an "Ohm" and say several things that are secretly recorded and played back later in a way to expose the inner dialogue.
... using a timer*, I time-trigger recordings, playback of those, and sound-effects (reverberation, pitch-shift). In the end the participants will hear their own voice talking to them, but in two different pitches, one voice a little lower pitched talking as the inner-enemy and then a higher pitched voice commenting on this, creating a dialogue, giving the participants the chance to observe that theatre-play inside of their head.
To close the session, they will be asked to make another Ohm...and as background they will hear the recorded Ohm they made when they started plus the recorded and looped Ohms of all the participants who were under the bell before them (if possible, first one om...then the next joins and another...and then maybe fading it to three or more other Oms, before the whole choir joines the megaOm).

*! I want to modify this patch to use it´s timer, recorder and playback- features. The karaoke-text-display is not needed, cause everything will be instructed by a backgroud-voice (lostintro.wav).
To test the patch simply click on start, to open the patch right-click in the window, then open the object pd audio, where the recorders and playbk objects are hiding.

1. I can´t find a pitch-shift object except one in an old RjDj library called e_pitchshift.pd, but I didn´t yet managed to make it work in the patch. Any suggestions of an object that shifts the pitch by two semitones up/down? ...also I wonder how to implement this to make the workflow as easy as possible, because there will be a lot of samples. I guess it is the easiest to include it in playbk.pd, and use two different ones, one with playing back the samples with a higher pitch and one with a lower pitch. (?)

2. To combine and loop all recorded "ohms" into one file, i will need sth like a looper-object/patch, I am sure there are plenty out there. My biggest concern is, the different volumes of peoples voices, thats why I am wondering if there is a normalization-object?

3. I once found a trigger for recordings in an RjDj patch (that I can´t find anymore), that checked the db of the incoming signal and only when detecting a sound it started to record - I was wondering if I could use it to control, if people really say/sing things and if not repeat the question (or give more time to record? ...maybe substitute that even with the timer-triggered recordings?)

4. well, not really top priority, but I would love to make the whole patch run on a raspi. I already struggeled with the raspi for a while - who knows...maybe there is someone in Berlin who could help me to set this up during the next weeks?

5. I want to timetrigger a change of the reverberation of the live-signal at the beginning ...the great @whale-av helped me once to optimize this patch (lostgeneration) and deactivated the reverb (found in the down-left corner of the pd audio -object) ..unfortunately I can´t figure out how to reactivate it. Where do i have to connect the "r revtime"? right to/between the "dac~" object???

6. last but not least a little stupid question, but as i don´t even know the name of this "~" symbol it is hard to google. How to make the keyboardshortcut for this little ~er ? tired of having to copy paste it each time ?

Bämgreetings and thanks for any help or suggestion!