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.
Optimizing pd performances to fit an RPI 3
@Nicolas Danet Thanks for the tip, I didn't knew about Perf on linux it's very handy. I ran a test on each patch/subpatch and got the following:
So I will serach about -GI__printf_fp_l _IO-vfscanf vfprintf plus_pcrf8 and delay_tsc to see to what they match in PD. But if GI_printf and vfprintf are calls used by PD for the GUI object then @alexandros was right and I will replace all GUI object by text ones.
@EEight My problem with switch~ is not that I don't know how to use its syntax but more because splitting each sound processing patch in my patch would divide it into at least 16 different subpatch(probably more). And as far as I experimented the pd~ object I have noticed that running 9 subpatches took more ressources than just running 3. Considering this I'm not sure that implementing switch~ to my patch will introduce a significant gain of processing power. And it is the case it would be effecient if I only used few tracks out of the 8 track grroovebox that I'm working on, disable Fx ect.. and as soon I want to use the full capabilities of the patch it would crash because all the audio processing patch would run with the DSP and the CPU performances would rise again to what I got now.
Maybe I didn't explain it very clearly, so I will rapidly explain it again. My main problem here is that my intitial patch(we'll called it v1) uses 10-12% of CPU, and my motherpatch for different processes(let's call it v2) uses 18-20% + subpatch 1 running at 12-15% and subpatch 2 8-10%. So I got a v1 is runniingn 50% on one core and V2 and its subpatches is running at 30-40 with peak at 60% on four cores. Which is kind of the worst optimization of the history of computing ^^. Though ginving the Perf result I have something to investigate to see where the problem come from. I'll give you update as soon as I found out what to do.
EDIT: I did a bit of search it seems that IO-getc, GI-printf, IO-vfscanf and vfprintf are all functions used to manages stram of data. I'm not sure but I'm sending the value from my GUI/input patch to my auddi processing patch via netsend, maybe the way I'm doing it is not optimal, maybe I should switch to osc~ because it's more effective to stream large numbers of value. Maybe I messed up the way to through values into the subpatches(because if my netsending method is messy it does not explain why I see the same problematic function calls in the subpatches). It coould also be link to the GUI elements since data streaming could be used in in those. But it does not explain why there's the function call in my mother patch that isn't using any GUI elements. To get better result I will find directly in PD source code.
EDIT 2: I found vfprintf in this PD source file "pa_debugprint.c" so it don't validate the few hypothesis I made before, but in my pd window I got repeated messages like "output snd_pcm_delay failed: Unknown error 476 astate 3" they could be the reason of this. Then I also found plus.perf8 here "d_arithmetic.c" it seems relied to operators (/ * = -) I use them to set value to my synth ect... so getting rid of them would be very difficult if not impossible.
Optimizing pd performances to fit an RPI 3
Hello everyone, I'm currently working on somekind of "fork" of a patch I found(it's a groovebox patch coded by Martin Birkmann). It consume quite a lot of CPU, on my current Laptop equiped with an Intel® Core™ i3-6006U CPU, it ran up 50% on the first core. Since i want to be able to run it on a Raspberry Pi 3, running the patch at about 1 ghz on a single core is just not possible. Then I looked up how I could optimizes the use of the cpu, I tried to use some puredata command flag, tried to simplify and hide most of the GUI and even tried to split up the patch with subprocesses with pd~.
First flags, changes of priority, realtime ect... doesn't do anything for the use of CPU. Secondly hiding some GUI maybe help to grab 1% or 2% of CPU. Finaly, I had great hope that pd~ would allow to spread the CPU all across the proccessor allowing me to run it on the RPI 3, but no it's strange the mother patch of the subprocesses is running at 18-20% of CPU use(about 60% on a single core) consuming more than the initial patch that runs at 10-12% of CPU use. And when I'm running the pd subprocesses they also grasp a load of cpu use, They consume about as much as the mother patch, which is quite the opposite of what I wanted...
So is it normal that the use of pd~ just increases the need of CPU time for pd ? Is there another way to split the audio processing in different pd instances s the calculation is shared by different cores ? Is there some things I could improve in the audio processing section that could help lowering the use of CPU ?
Then I have another problem whenever I wanted to activate the dsp when I was on my RPI pure data craches. Is there someone here that knows why ? What command should I use to use the dsp without crash on a rpi ?
If you don't see any solution to my problem then you maybe can help me in an another way? Since my problem is mainly optimisation, if you have some recommandation to gave about some pure data open source groovebox patch that run well on low spec system it would be great.
Velocity toggle or something?
@flight453 i have made an abstraction for this, feel free to use as you like. velocity-senitivity.pd just download it and call it in your patch.
when you call a patch (or any normal file) in pd through directory traversing in objects, there are some rules (idk if i know all, because i have just stumbled upon them randomly):
a: to call a patch in the same directory (folder) as your main patch, just type out the name, excluding the ".pd" at the end, so velocity-senitivity.pd becomes velocity-senitivity.
b: to call a patch inside a directory which is inside the same directory as your main patch, just type the directory name for the directory inside the shared directory, then a "/" and then the filename, again, excluding ".pd", so velocity-senitivity.pd inside the directory "abstractions" which shares the directory with your main patch, becomes abstractions/velocity-senitivity. you can go as many directories in as you like, so abstractions/midi&more/velocity-senitivity
c: if it is outside your directory type one "." for as many directories you have to go outside and then "./" (yes, that is a "." followed by a "/") and then your patch name, again, excluding ".pd".
d: you can type what rule "c" says and not entering the patch name, and then type what rule "b" says. here's an example of this in action .../abstractions/midi&more/velocity-senitivity, so the ".../" means that you shold go back 2 directories, and "abstractions/midi&more/" means that you should go inside the folder "abstractions", and then "midi&more", and "velocity-senitivity" is the the patch that you want to use.
e: just typing out the full directory, again excluding the ".pd"
you'r welcome
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.
Lua / Ofelia Markov Generator Patch / Abstraction
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;
;
Table-using Abstraction can be used multiple times in one patch
@Maggie17 Sometimes it is easier with words........
Dollar $ variables in Pure Data patches.
A dollar variable is a thing that can be given a new value.
The new value can be a float or a symbol.
- If the Dollar variable is in an [object] box
A Pd patch can be saved and used inside another patch. We then call it an abstraction.... and it is just like a programming sub-routine.
If you want to use it many times then you have a problem, that they are all the same, so if you put an object [receive woof] they will all receive any message that you send with [send woof].
That might well be what you want to do.
But what if you want to send the message to only one of them?
You can give it an [inlet], but your patch will get messy, and what if your patch needs to make its own mind up about which abstraction it wants to send the message to, maybe depending on which midi note it received?
The solution is to give the abstraction arguments... some parameters that define it and make it different to the other copies.
For example [my_abstraction]
Let’s give it some arguments [my_abstraction 5 9 woof]
Inside the abstraction, as it is created (you open its parent patch) the dollar variables will be replaced. Wherever you see $1 written IN AN OBJECT it has been replaced by the number 5.
Number 5 because 5 is the first argument and has actually replaced the $1. You still see $1, but if you bang a [$1] object it will output 5.
[f $2] will output 9
[symbol $3] will output woof
So if you have an object [receive $1-$3] then it has now become [receive 5-woof]
And if you want to send it a message from outside, from another patch or abstraction, you will need to use [send 5-woof]
Every Pd patch, which remember includes your abstractions, also has a secret number. The number is unique and greater than 1000. As Pd opens each patch it gives it the number, increased by one from the last number it gave.
That number will replace $0 as the patch is created. You can find out what the number is by banging a [$0] object and connecting its output to a number box, or [print] object.
$0 can be used in any object as part of the name or the address, which means that a message cannot escape from the abstraction. A sub-patch like [pd my-subpatch] will be given the same number.
But from outside your abstraction you don’t know what it will be when the patch is created, so it is not useful. (A lie, you can find out, but as it can change every time you open your patch it is not worth the bother).
Use it to send messages within your patch [send $0-reset] to [receive $0-reset] for example, because the message is absolutely unique to its window, so you know it cannot interfere with other abstractions. - If the Dollar $ variable in a [message( box
Dollar $ variables are also replaced, but not as the patch is created (drawn by Pd as you open it).
Dollar zero $0 has no meaning in a message box. It will produce a zero if the message is banged, but that is it.
It is a mistake, a patching error, to put a $0 in a message box.
$1 $2 $3 $4 etc. in a message box are replaced by incoming atoms (individual floats or symbols or whatever) when they arrive. $1 will be replaced by the first atom in the list, $2 the second etc.
So if you have a message box [$1 $2 $3( ..... and you send into it a list [3 48 lala( .....then it will output 3 48 lala
That is not really very useful.
But it is actually very powerful.
Make a list in a message box........ [33 12 wav(
And bang it into a message box [open my-track$2-$1.$3( and you will get the output.........
open my-track12-33.wav
Which could be just the message that you want to send to [soundfiler]
David.
foo_pd - Pure Data plugin for foobar2000
This is a spiritual successor to amPd. It's much more stable and has many more features than amPd:
-
reads/writes metadata to/from patches. This is done by storing the info in the form of comments, in a canvas called [pd meta] or [pd info]. If no such canvas exists, foobar will add it in the top left-hand corner of your patch.
-
comes with a Win32 Dialog UI element, containing sliders, toggles, buttons, and edit-text/button combos to send messages to your patch.
- foobar looks in your patch for a canvas called [pd mix] and uses the parameters of whatever sliders, bang objects, or toggles it finds there to give your UI controls similar functionality.
How playback works
- libpd sends a 1 to vol, then a bang to play.
- Generally this is where, in your patch, you have an [r play] hooked up to your metro, and an [r vol] connected to a [*~ ] before your output reaches [dac~].
- the length of the song is arbitrarily set by the user.
- This affects the trackbar's cursor visibility and ability to set a position.
- If the length is 0, there will be no trackbar cursor. Otherwise, the cursor, when moved, will send its position in seconds to pos. From there, it's up to your patch to take that information from [r pos] and work it into song events.
- The patch will not actually stop and move on to the next track until libpd receives a bang from [s stop].
How the mixer works
- all mixer controls go inside of [pd mix]
- horizontal and vertical sliders are turned into slider controls in the UI element
- labels assigned to sliders in the patch become labels for the UI element's slider controls. The same applies for send symbols.
- min and max values of sliders on the UI element work in integers only, so if you want a gradual shift from, say, 0 to 1, write "gradient" in the slider's receive symbol, and the slider's range will be broken down into roughly 200+ individual steps.
- there are currently 7 sliders in the UI element
- bang objects with no label become simple buttons in the UI
- their send symbols will be reflected in the button's name and they will send a bang when clicked.
- there are currently 3 buttons
- bang objects with a label assigned become message buttons
- these have an edit text field associated with them, where you can type out any message you want and send it to the destination.
- the bang's label is placed inside of the edit text field as a suggested message to send.
- pure data strips commas out of labels, so I'm using apostrophes to denote where commas should go. ex: do this' then this
- there are currently 2 message buttons, with the 'any' button being a potential 3rd.
- a bang object with a label written in the format dest : msg will be assigned to the 'any' button.
- the 'any' button has an editable destination field, giving you access to basically any receive symbol in your patch.
- also substitutes as a third normal message button, when the other two are already in use
- toggles become checkboxes
- each checkbox can have a label and send symbol assigned to it
- there are currently 4 checkboxes
- right-clicking a track shows the context menu entry Pd Player -> Load mixer.
- basically, you can load mixers of tracks not currently playing for some potentially interesting exchanges between patches. After loading the mixer, you still need to hit the Refresh button to show the changes.
foo_pd's copy of libpd.dll contains only the externals that I needed to run the example patches. If you want your own patches to work with foo_pd, you might need to make another build using MSYS2. If you're not sure which objects aren't instantiating, foobar's console prints all of pd's messages while audio is being processed. I'll also add more externals over time.
I'll be maintaining foo_pd at https://github.com/myQwil/foo_pd where you can also find the latest builds
foo_pd.zip
Last Updated: Feb 26, 2021 3:55pm EST
Lissa Executable / ofxOfelia compile error (Solved)
@cuinjune I tried to compile the lissa seq patch. but when i open the executable it opens only a small empty window.
i also tried to compile a help patch for testing, with the same result.
but your example works fine(Win32Example).
Foot Pedal Behaviours Abstraction
@image_engine I have absolutely no idea why it should be the case...... but the GUI will be laggy if the audio settings are too tight........ even when the DSP is not in use AND IS TURNED OFF. It makes no sense, but it is so. Maybe an audio chain is built as the patch is built, even when there are no audio objects?
[input_event]...... I might be wrong, but my foggy old brain is trying to tell me that [input_event] was not part of extended. If you have made a fresh installation on W10 it might be missing.
Here it is again from my "pd/extra" folder........ in.zip
The two files were in "extra"...... not in a sub-folder.... which makes me a little more certain that they were not included in extended.
Of course the Win 10 api might have been re-written and the .dll might be deprecated.
I don't know if the execution order is critical for the pedal up flag...... but that would be the first place to look if the patch behaved badly. It could matter if you changed something else for some reason. But on the left side the send_ped_up can send [0( from the box above when banged by [sel 1 3] and [1(...[1( or [0(....[1( depending on the order from [sel 1 2 3 4]. Can that cause problems because of the arrival of a new input in the middle of a pedal input? I don't know...... but it could be best to "fix" the order so that there is no doubt about the logic.
Yes, I inserted the two bangs to get rid of the double cords from the select object...... but also, as you say, it helps with a de-bug...... as it reminds the reader that outputs 2 and 4 are getting only bangs, while outputs 1 and 3 are getting logic (0/1).......
I would use logic (0/1) as you have done....... as the patch is all about logic. Number 0 is logical false and so "means" "off" and is a natural reset. You could create tags for messages using symbols and then [route] instead of [select]. I had never thought about that, but it is a very interesting idea . It serves no purpose in a running patch, and creates extra work building the patch........ BUT......
..... In the past I have set a slow [metro] to make such a patch "live" and used "magic glass" or labelled [print] objects for debugging. In a very complex logic patch it could be very useful to tag the messages. It can be hard to spot message ordering problems just using the terminal window and even harder with "magic glass". With symbol tags you would easily see where the messages originated. It's a very good idea! Up-vote deserved!
Sorry...... that sparked some ideas.
Tagging and routing by symbols will be a bad idea because the logic decisions need to be taken by 1/0 true/false and so the value needs to head up the list.
But tags could be appended....... to show the route taken.
[route] would always be used instead of [select]...... so that the appended message is preserved...... and then the logical value re"-"placed using [list prepend].
I might start a new thread I think..... to gather ideas and criticism.
A set of specific "normal" and "debugging" objects would be useful, as, for example [myselect 0 1] (which contained values to "send onwards" unlike [sel] ) could be renamed to [myrouter 0 1 router5].
Aarrgh...... probably a huge hole in which to stop digging......
..... and I bet it exists in extended already........?????
P.S.
Is your patch working as you wish?
And reading again.... after all that!..... I think you meant "message or float" and not "symbol or float" to send the zero.
I don't know of any difference, and they send exactly the same data, but the message [1( is more useful for debugging than the float [1] because you can click it and send the message.......
David.
debugger.pd