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.

-UPDATE-
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].

-CYBERLOG-

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 English Edition :
Nek'Sum 6.rar
Nek'Sum 5.rar
Nek'Sum 4.rar
Nek'Sum 3.rar
Nek'Sum2.rar
Nek'Sum.zip

Patch Download Mandarin Edition :
Nek'Sum 6 - Mandarin Edition.rar

Mandarin special edition :

Snapshots :

Hi all,

Part of my patch involves a looping sampler with envelope generator. I had it working just fine with sliders to control the points of the envelope but they were kinda clunky GUI-wise so I am trying to draw an envelope on top of the sample array using Purr Data's [draw]. This is giving me some issues:

1. I want a grid of instances of my sample abstraction, like a drumrack, and I want individual ADSR envelopes with each sample. In vanilla I could put a [namecanvas] inside the array but this doesn't seem possible anymore with Purr Data. I figured the way to go would be to put the array in a graph-on-parent subpatch, and use [namecanvas] and [draw] to draw the envelope on top of it. But the bounds rectangles do not seem to be following even though the graphs are, and I'm wondering if I need to use something like [donecanvasdialog( to hack it into shape. Image of this phenomenon attached. The first label is covered up by its symbol box as intended but the next two show up on top of it. When I make another instance on the parent parent patch, the array shows up all the way at x=0 no matter where I put the abstraction. Maybe I need to pass the (x,y) coords of each abstraction as arguments too?

2. In vanilla I could set the arguments of [drawcurve] to variables and it would automatically let me interact with those via click-dragging. I see the "drag" mouse event in the documentation for the new SVG functions, but I am used to the old way and wondering what the new way to do this is.
3. It seems like my initial attempts at using [draw] were drawing underneath whatever was already there, is there a way to make it draw on top instead?

I have put many many hours into this crazy just intonation synthesizer project, have made a ton of progress and would love to share it with you guys once I have something a little more polished, I am just trying to get this GUI a little nicer and it is giving me headache. So thanks in advance for any guidance you may be able to offer.

Now that it is possible to generate shader visuals with sound information in Pure Data (it was before with Gem, right?),
I was wondering how it can work the other way around. To generate sound or at least sound information with shaders and send it to Pure Data. There are some very interesting examples of how to use the GPU for sound generation. This one is Shadertoy again:
https://stackoverflow.com/questions/34859701/how-do-shadertoys-audio-shaders-work https://www.reddit.com/r/musicprogramming/comments/2cbd2s/shadertoy_has_added_glslsynthesized_audio/
This seems also interesting: https://www.fsynth.com/
Anyway, I read out one horizontal pixel line per frame and use the rgb information for generating MIDI notes.
I also use the mScale abstraction from @ingox for scaling the notes.
The player generates also MIDI notes from images, it is only silent if the whole scanned line is very dark or very bright .
My first approach was to generate audio from the pixel information like in the examples above, but the sound was always distorted (but I am sure it could work... ).
I am also interested in other methods to generate sound from visuals and visuals from sound.

GLSL_Video_Effects_V01_MusicPlayer.zip

Here is an example from the MusicPlayer:

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...

I finished the Ofelia / Lua Markov Generator abstraction / patch.
The markov generator is part of two patches but can easily be used as an abstraction.
I want to use it for pattern variations of a sequencer for example.
It just needs a Pure Data list as input and outputs a markov chain of variable order and length.
Or draw into the array and submit it to the markov generator.
The first patch is an experiment trying to create interesting sounds with the markov algorithm.
In addition I used the variable Delay from the Pure Data help files:
LuaMarkovGeneratorSynthesizer.pd

The second patch creates markov chains at audio rate, it is quite cpu heavy but works until the 10th markov order.
It is quite noisy but I was courius how it will sound:
LuaMarkovGeneratorAudioRate.pd

And here is the Lua code.
The core of the code is adapted from this python code: https://eli.thegreenplace.net/2018/elegant-python-code-for-a-markov-chain-text-generator/
A few things that I do not really understand yet, but finally it works without errors (it was not easy sometimes ):

-- LUA MARKOV GENERATOR;
function ofelia.list(fv);
;
math.randomseed(os.time()- os.clock() * 1000);
;
print("LUA MARKOV GENERATOR");
local markovOrder = fv[1];
print("Markov Order: ", math.floor(markovOrder));
;
-- make dictionary;
;
local function defaultdict(default_value_factory);
;
local t = {};
local metatable = {};
metatable.__index = function(t, key);
if not rawget(t, key) then;
rawset(t, key, default_value_factory(key));
end;
return rawget(t, key);
end;
return setmetatable(t, metatable);
end;
;
-- make markov matrix;
;
local model = defaultdict(function() return {} end);
local data = {};
for i = 1, #ofelia.markovInputList do;
data[i] = ofelia.markovInputList[i];
end;
print("Data Size: ", #ofelia.markovInputList);
for i = 1, markovOrder do;
table.insert(data, data[i]);
end;
for i = 1, #data - markovOrder do;
local state = table.concat({table.unpack(data, i, i + markovOrder - 1)}, "-");
local next = table.unpack(data, i + markovOrder, i + markovOrder);
model[state][next] = (model[state][next] or 0)+1;
end;
;
-- make tables from dict;
;
local keyTbl = {};
local nexTbl = {};
local prbTbl = {};
for key, value in pairs(model) do;
for k, v in pairs(value) do;
table.insert(keyTbl, key);
table.insert(nexTbl, k);
table.insert(prbTbl, v);
end;
end;
;
print("Key: ", table.unpack(keyTbl));
print("Nex: ", table.unpack(nexTbl));
print("Prb: ", table.unpack(prbTbl));
;
print("Make a Markov Chain...");
;
function ofelia.markovChain();
;
-- make start key;
;
local startKey = {};
if ofelia.randomStart == 1 then;
local randomKey = math.random(#keyTbl);
startKey = randomKey;
else;
startKey = 1;
end;
;
local markovString = keyTbl[startKey];
local out = {};
for match in string.gmatch(keyTbl[startKey], "[^-]+") do;
table.insert(out, match);
end;
;
-- make markov chain;
;
for i = 1, ofelia.markovChainLength do;
;
-- weighted random choices;
;
local choices = {};
local weights = {};
for j = 1, #keyTbl do;
if markovString == keyTbl[j] then;
table.insert(choices, nexTbl[j]);
table.insert(weights, prbTbl[j]);
end;
end;
;
-- print ("choices:", table.unpack(choices));
-- print ("weights:", table.unpack(weights));
;
local totalWeight = 0;
for _, weight in pairs(weights) do;
totalWeight = totalWeight + weight;
end;
rand = math.random() * totalWeight;
local choice = nil;
for i, weight in pairs(weights) do;
if rand < weight then;
choice = choices[i];
break;
else;
rand = rand - weight;
end;
end;
;
if math.type(choice) == "integer" then;
choice = choice * (1.0);
end;
;
table.insert(out, choice);
local lastStep = {table.unpack(out, #out - (markovOrder-1), #out)};
markovString = table.concat(lastStep, "-");
end;
;
return {table.unpack(out, markovOrder + 1, #out)};
end;
end;
;

Thanks for all the suggestions about this. I'm going to keep plugging away and report back when I find the fix, though I'll probably ultimately take th8a's suggestion of using tables for the envelope segments so I can eliminate the hacky way I'm using threshold~.

I've been building in lots of print and env~ objects to try to figure out where the exact problem is. I believe I've successfully determined that it's NOT the voice stealing or the threshold~ object. All the midi info seems to be getting routed to the right voices, and the decay segment seems to be playing correctly even in notes that get stuck on, which it's the purpose of the threshold~ object to trigger.

For some reason the midi off control seems to be sent to the envelope, but it isn't registering it. I can fake another off event with messages and the envelope releases normally at that point. I've been playing around with a slightly more complex synth patch that uses the same envelope abstraction, which is actually a little more helpful because it has multiple oscillators for each voice, and they do NOT all seem to get stuck on at once. In fact, the base oscillator seems to be the only one that gets stuck on, whereas the 2 suboscillators do not, which suggest to me that I might have screwed up the construction of how the oscillator patch interacts with the envelope. But I'm still only closer to figuring it out; I haven't had much time to mess around with it lately.

Hello!

I am trying to make an modulation envelope that works with the lop~ filter. The lop~filter uses a control inlet for the filter frequency where vcf~ and bp~ uses a signal inlet. And the envelope I have made works perfectly for the vcf~ & the bp~ but not the lop~.

I tried using snapshot~ to convert from signal to control, but the result is not good, even when I feed the snapshot~with a very fast metro to refresh it rapidly.

My patch looks like this:

The subpatch on the left side is the sequencer so you can see what signal I feed into the envelope. When I am live with the patch I can see that the envelope receives a trigger signal. So I am pretty sure the inlet/trigger part is working, so I dont think that is the issue.

On right side is the envelope that I cannot get working with the lop~ filter.

Does anyone have a suggestion to:
a. What I can do to either get the decay envelope I all ready have working in another way than using snapshot~.

b. Make a new decay envelope that uses control signal. Or maybe there is all ready one? I havent been able to find one....

Any help appreciated!

Thanks, Jaffa!

Hi. I've played with this method before a bit. A real 1-pole lowpass filter with an impulse passed in is equivalent to multiplying every previous sample by a constant factor to get the next sample, which is also equivalent to an exponential envelope. But you can also add a constant factor for every sample in order to make a linear envelope. So it turns out you can make a variable-slope filter by combining: multiply and add on the previous sample by 2 different factors. If you are interested I have further details in this blog post:
https://sshader.wordpress.com/2014/09/05/programming-an-adsr-envelope/?iframe=true&theme_preview=true

It's not that cpu friendly when you change the settings because you have to take the sample-length-of-the-stageth root or something like that, I haven't looked into it in a while though. However, afterward it simplifies to an add and multiply at every sample

here are the codes: http://forum.pdpatchrepo.info/topic/8490/examp-exponential-envelopes-with-exponential-linear-curve-control

New version 7 (currently testing)

• added automatic loosening of minimum fitness limit for the case that a population of sounds gets stuck in a local maximum in the fitness landscape (really nerdy jabbering, but trust me, it's useful ^^)
• added automatic "jumping" out of local maximums after a certain number of fruitless climbing-trials

EWOLVERINE v.7 by Henry Dalcke.pd

plans:
• bugfix: prevent a newly audible sound from being selected after manually stopping the target drive
• simulated annealing in target drive mode: span "temperature" value onto fitnesslandscape and decrease step length (modwheel) and probability value in the splice-pattern-generator the closer the fitness gets to optimal fitness value
• interactive mode: automatic narrowing of the range of generated parameter values around a mean value that's derived from the repeated selection of similar values of individual parameters throughout the generations (increases the number of similar sounds per generation that are located around a certain coordinate in parameter space; increases the likelihood of the generation of the desired sound in a smaller amount of time)
• stop-condition for automatic stopping of target drive
• make default settings for modwheel-position, splice-pattern-generator's probability, anti-stuck and allowed minimum fitness value in target drive adjustable from GUI
• adjustable MIDI output message blocker (useful for instruments with a fixed MIDI implementation, for instance: If you want to breed a bass drum in a drum synth with multiple instruments, you may not want to ruin the parameter adjustments of the snare drum meanwhile you're selecting for good bass drums)
• storage for self-created splicer patterns (maybe in connection to the MIDI output message blocker)
• low-value-weighted probability for the generation of MIDI-CC-values in new populations; switchable per MIDI-CC either manually or randomly (increases the probability for the generation of short attack and decay values in synth's envelopes)
• bigger populations for each sound-set: 4 more random sounds per set (A/B) to select from
• discontinuous MIDI messaging interrupted by assignment switching CC events (special build for FM-Heaven) - low priority
• possibility to interpolate between new random population's sounds to smoothly re-direct the modwheel-morphing path while morphing
• selection-history recorder that one can use to re-load the selected sounds of each past generation
• a visualizer that generates a "tree of life" from directions (keys C,D,E,F) and steplengths (modwheel) of formerly selected individuals and their respective distances to their parent sounds

So I've made this module to allow for stochastic variation of dynamic envelopes. It allows you to choose between three envelope types or determine the probability of each occuring. With the "ran"(dom) setting, the envelope lengths can be determined autonomously, or you can input a bang (third inlet) to coordinate the envelopes with other modules.

Depending on the length of the envelope, I can sometimes hear the low "resolution" of the "moderate" and particularly the "sharp" envelope, as they are only a four-point approximation of a curve. I can add more points of course, though, ideally, I should probably add a mechanism that takes the length of the envelope into consideration when determining the amount of points and the proportions of the envelope. Of course, if there are already excellent abstractions out there of which I'm unaware, I'd be happy if you could share them with me, so that I can avoid (further) re-inventing the wheel.

N.B: Open demo.pd to test the module.

P.S. It's possible that I've re-invented the wheel in multiple ways in this module, e.g. in the probability determination found in [dynamics]>[pd envelope_type]>[pd envelope_type_pool_and probability].　Any advice regarding pre-existing objects is appreciated.

EDIT: re-uploaded without [gate] and in .zip format.
envelope.zip