Having lots of switches into Pd
@alexandros
This code sort of works with wip_multiple_PWM.pd
// merging works but pwm leds are choppy.
// number of elements in arrays need to
// match for() cycles in void setup and void loop
int pinsIn[2] = {2, 4};
int pinsAnalog[8] = {0, 1, 2, 3, 4, 5, 6, 7};
int pin = 0;
int val = 0;
int pinsOut[2] = {7, 12};
//TMP setup pwm:
// variables to hold pin numbers
int pwmLED1 = 3;
int pwmLED2 = 5;
int pwmLED3 = 6;
int pwmLED4 = 9;
int pwmLED5 = 10;
int pwmLED6 = 11;
// variables to hold pin states
int pwmLEDvalue1;
int pwmLEDvalue2;
int pwmLEDvalue3;
int pwmLEDvalue4;
int pwmLEDvalue5;
int pwmLEDvalue6;
//should this be omitted and use the a
// variable to hold and assemble incoming data
int temporary;
//END TMP pwm setup
void setup()
{
//set up a total of pins for digital input (has to match number of elements in array)
for(int i = 0; i < 2; i++)
pinMode(pinsIn[i], INPUT);
for (int i = 0; i < 2; i++) {
pinMode(pinsOut[i], OUTPUT);
digitalWrite(pinsOut[i], LOW);
}
//DEFAULT works with thermistors,
//INTERNAL with transitor thermostats
analogReference(DEFAULT);
pinMode(A0, INPUT_PULLUP);
pinMode(A1, INPUT_PULLUP);
pinMode(A2, INPUT_PULLUP);
pinMode(A3, INPUT_PULLUP);
pinMode(A4, INPUT_PULLUP);
pinMode(A5, INPUT_PULLUP);
pinMode(A6, INPUT);
pinMode(A7, INPUT);
//TMP test pwm setup:
pinMode(pwmLED1, OUTPUT);
pinMode(pwmLED2, OUTPUT);
pinMode(pwmLED3, OUTPUT);
pinMode(pwmLED4, OUTPUT);
pinMode(pwmLED5, OUTPUT);
pinMode(pwmLED6, OUTPUT);
Serial.begin(115200); // perhaps use a faster baud rate
}
void loop()
{
Serial.print("knobs"); // use "knobs" as a keyword so you can receive
// the knob values as a list with a [r knobs] in Pd
for(int i = 0; i < 8; i++){
unsigned int knob = analogRead (pinsAnalog[i]);
Serial.print(" "); // first print a white space to separate the "knob" keyword from the values
// and the values from each other
Serial.print(knob); // then print the actual knob value
}
Serial.println(); // finally print a newline character to denote end of data for keyword "knobs"
// the same technique applies to the switches too
// receive the switch values as a list with [r switches]
Serial.print("switches");
for(int i = 0; i < 2; i++) {
int switchVal = digitalRead(pinsIn[i]);
Serial.print(" ");
Serial.print(switchVal);
}
Serial.println();
//handle digital outputs
if (Serial.available()) {
static int temp;
byte in = Serial.read();
if (isDigit(in)) {
temp = temp * 10 + in - '0';
}
else if (in == 'p') {
pin = temp;
temp = 0;
}
else if (in == 'v') {
val = temp;
temp = 0;
digitalWrite(pinsOut[pin], val);
}
}
//TMP merge test PWMs:
while(Serial.available()){
byte inByte = Serial.read();
if((inByte >= '0') && (inByte <= '9'))
temporary = 10 * temporary + inByte - '0';
else{
if(inByte == 'p'){
pwmLEDvalue1 = temporary;
temporary = 0;
}
else if(inByte == 'q'){
pwmLEDvalue2 = temporary;
temporary = 0;
}
else if(inByte == 'r'){
pwmLEDvalue3 = temporary;
temporary = 0;
}
else if(inByte == 's'){
pwmLEDvalue4 = temporary;
temporary = 0;
}
else if(inByte == 't'){
pwmLEDvalue5 = temporary;
temporary = 0;
}
else if(inByte == 'u'){
pwmLEDvalue6 = temporary;
temporary = 0;
}
}
analogWrite(pwmLED1, pwmLEDvalue1);
analogWrite(pwmLED2, pwmLEDvalue2);
analogWrite(pwmLED3, pwmLEDvalue3);
analogWrite(pwmLED4, pwmLEDvalue4);
analogWrite(pwmLED5, pwmLEDvalue5);
analogWrite(pwmLED6, pwmLEDvalue6);
//digitalWrite(dspLED, dspLEDstate);
}
}
This is the code without PWM control. It works fine.
//number of elements in arrays need to match for() cycles in void setup
int pinsIn[4] = {6, 7, 8, 9};
int pinsAnalog[8] = {0, 1, 2, 3, 4, 5, 6, 7};
int pin = 0;
int val = 0;
int pinsOut[4] = {2, 3, 4, 5};
void setup()
{
//set up a total of pins for digital input (has to match number of elements in array)
for(int i = 0; i < 4; i++)
pinMode(pinsIn[i], INPUT);
for (int i = 0; i < 4; i++) {
pinMode(pinsOut[i], OUTPUT);
digitalWrite(pinsOut[i], LOW);
}
//DEFAULT works with thermistors,
//INTERNAL with transitor thermostats
// ELLER var det tvartom???
analogReference(DEFAULT);
pinMode(A0, INPUT_PULLUP);
pinMode(A1, INPUT_PULLUP);
pinMode(A2, INPUT_PULLUP);
pinMode(A3, INPUT_PULLUP);
pinMode(A4, INPUT_PULLUP);
pinMode(A5, INPUT_PULLUP);
pinMode(A6, INPUT);
pinMode(A7, INPUT);
Serial.begin(115200); // perhaps use a faster baud rate
}
void loop()
{
Serial.print("knobs"); // use "knobs" as a keyword so you can receive
// the knob values as a list with a [r knobs] in Pd
for(int i = 0; i < 8; i++){
unsigned int knob = analogRead (pinsAnalog[i]);
Serial.print(" "); // first print a white space to separate the "knob" keyword from the values
// and the values from each other
Serial.print(knob); // then print the actual knob value
}
Serial.println(); // finally print a newline character to denote end of data for keyword "knobs"
// the same technique applies to the switches too
// receive the switch values as a list with [r switches]
Serial.print("switches");
for(int i = 0; i < 4; i++) {
int switchVal = digitalRead(pinsIn[i]);
Serial.print(" ");
Serial.print(switchVal);
}
Serial.println();
//handle digital outputs
if (Serial.available()) {
static int temp;
byte in = Serial.read();
if (isDigit(in)) {
temp = temp * 10 + in - '0';
}
else if (in == 'p') {
pin = temp;
temp = 0;
}
else if (in == 'v') {
val = temp;
temp = 0;
digitalWrite(pinsOut[pin], val);
}
}
}
and here is the code from tutorial5 from Arduino for Pd'ers. It goes with arduinoforpdrs_tut5.pd
// variables to hold pin numbers
int pwmLED = 9;
int dspLED = 2;
// variables to hold pin states
int pwmLEDvalue;
int dspLEDstate;
//variable to hold and assemble incoming data
int temporary;
void setup()
{
pinMode(pwmLED, OUTPUT);
pinMode(dspLED, OUTPUT);
Serial.begin(9600);
}
void loop()
{
while(Serial.available()){
byte inByte = Serial.read();
if((inByte >= '0') && (inByte <= '9'))
temporary = 10 * temporary + inByte - '0';
else{
if(inByte == 'p'){
pwmLEDvalue = temporary;
temporary = 0;
}
else if(inByte == 'd'){
dspLEDstate = temporary;
temporary = 0;
}
}
analogWrite(pwmLED, pwmLEDvalue);
digitalWrite(dspLED, dspLEDstate);
}
}
I am aiming at using same type of array handling as for the digital outs.
Thanks a lot
"Nested instances" for distributing CPU load
Hello! First time poster here.
I'm looking in to the possibilities with sending signals between instances of PD.
My 'dream' scenario would be to have a setup something like this:
One "control" branch which handles most interaction with the real world, presets, signal routing and conditioning, etc. this would optimally be running at 96k (0.5x192k) sample rate.
One "sound generation" branch. Basically oscillators and some sound shaping, running 192k.
One "filtering and output" branch, running at 192k but with upsampling to 2x for the filter section. The "baseline" level of this branch would be hosting some envelope generators and the audio output.
So what I'm hoping for is to:
Send signals from both "real world" and the "control" branch, directly into "sound generation" and "filtering and output" in parallel. Having them arrive simultaneously at each destination.
This, while the audio would be running in a straight series manor:
Generation->Filtering->Output. (Hopefully not landing in the 192k level of the filtering branch before being upsampled and filtered..)
So...
Would this be possible? Maybe its just as simple as using sends and throws? Or are we forced to build in levels, so to say? Having control signals go through "Sound Generation" before heading on to "Filtering and output".
The documentation in how this feature works seems like a well kept secret I'm trying to find examples how others handle these things but I've been coming up short.
A bonus question, simple yes or no
Is communicating either control or audio, through the PD~ object, faster than the other?
I hope I spark some inspiration in someone who might put my spinning head to rest! I'm looking forwards to sharing this project when it's done, I think i've managed to get a very pleasing sound. The main reason for the layout I'm pondering is basically to have "note" and "velocity" sent directly to both "sound generation" and "filtering and outout", to minimize latency between keydown and envelope trigger. Maybe I'm just being stupid
Cheers!
Having lots of switches into Pd
@alexandros thanks, it all works!
I merged the codes for in and outs and also changed so you can set up all of the pins with arrays (as you did in the latter code). Then you can set up the pins in any order.
Here is the Arduino code. Do you spot any errors I may have introduced?
//number of elements in array need to match for() cycles
int pinsIn[4] = {2, 7, 10, 11};
int pinsAnalog[3] = {0, 2, 3};
int pin = 0;
int val = 0;
// some random pins
int pinsOut[4] = {3, 4, 5, 6};
void setup()
{
//set up a total of pins for input (has to match number of elements in array)
for(int i = 0; i < 4; i++)
pinMode(pinsIn[i], INPUT);
for (int i = 0; i < 4; i++) {
pinMode(pinsOut[i], OUTPUT);
digitalWrite(pinsOut[i], LOW);
}
Serial.begin(115200); // perhaps use a faster baud rate
}
void loop()
{
Serial.print("knobs"); // use "knobs" as a keyword so you can receive
// the knob values as a list with a [r knobs] in Pd
for(int i = 0; i < 3; i++){
unsigned int knob = analogRead (pinsAnalog[i]);
Serial.print(" "); // first print a white space to separate the "knob" keyword from the values
// and the values from each other
Serial.print(knob); // then print the actual knob value
}
Serial.println(); // finally print a newline character to denote end of data for keyword "knobs"
// the same technique applies to the switches too
// receive the switch values as a list with [r switches]
Serial.print("switches");
for(int i = 0; i < 4; i++) {
int switchVal = digitalRead(pinsIn[i]);
Serial.print(" ");
Serial.print(switchVal);
}
Serial.println();
//handle digital outputs
if (Serial.available()) {
static int temp;
byte in = Serial.read();
if (isDigit(in)) {
temp = temp * 10 + in - '0';
}
else if (in == 'p') {
pin = temp;
temp = 0;
}
else if (in == 'v') {
val = temp;
temp = 0;
digitalWrite(pinsOut[pin], val);
}
}
}
In Pd I was not able to use [r switches] or [r knobs] but had to use [route]. Is this the correct way to use [serial_print]?
And here it is on the breadboard:
Having lots of switches into Pd
I would suggest to not mix the analog values with the digital ones. The first code could be changed to the following (using Serial.print() with the [serial_print] abstraction):
void setup()
{
for(int i = 2; i < 14; i++)
pinMode(i, INPUT);
Serial.begin(115200); // perhaps use a faster baud rate
}
void loop()
{
Serial.print("knobs"); // use "knobs" as a keyword so you can receive
// the knob values as a list with a [r knobs] in Pd
for(int i = 0; i < 6; i++){
unsigned int knob = analogRead (i);
Serial.print(" "); // first print a white space to separate the "knob" keyword from the values
// and the values from each other
Serial.print(knob); // then print the actual knob value
}
Serial.println(); // finally print a newline character to denote end of data for keyword "knobs"
// the same technique applies to the switches too
// receive the switch values as a list with [r switches]
Serial.print("switches");
for(int i = 2; i < 14; i++) {
int switchVal = digitalRead(i);
Serial.print(" ");
Serial.print(switchVal);
}
Serial.println();
}
As for writing to several outputs you need to set which output you want to write to and then the value you want to write. Here's an example that writes to several different digital outputs:
int pin = 0;
int val = 0;
// some random pins
int pins[4] = {3, 4, 5, 6];
void setup() {
for (int i = 0; i < 4; i++) {
pinMode(pins[i], OUTPUT);
digitalWrite(pins[i], LOW);
}
Serial.begin(115200);
}
void loop() {
if (Serial.available()) {
static int temp;
byte in = Serial.read();
if (isDigit(in)) {
temp = temp * 10 + in - '0';
}
else if (in == 'p') {
pin = temp;
temp = 0;
}
else if (in == 'v') {
val = temp;
temp = 0;
digitalWrite(pins[pin], val);
}
}
With the code above you can send messages like this one print $1p$2v
in Pd to the [comport] object. $1 is the number of the pin you want to light up starting from 0 and incrementing by 1 (so the first pin used which is pin 3 in the Arduino code would be 0 in the Pd patch), and $2 is the value, 0 or 1.
Note though that in the first code (and the code you posted), you're using all digital pins as inputs so there's no pin left to use as output. If you want to combine these two chunks of code you'll have to use less pins as inputs and leave some to be used as outputs.
NoxSiren - Modular synthesizer system <- [v15]
NoxSiren is a modular synthesizer system where the punishment of failure is the beginning of a new invention.
--DOWNLOAD-- NoxSiren for :
-
Pure Data :
NoxSiren v15.rar
NoxSiren v14.rar -
Purr Data :
NoxSiren v15.rar
NoxSiren v14.rar
--DOWNLOAD-- ORCA for :
- x64, OSX, Linux :
https://hundredrabbits.itch.io/orca
In order to connect NoxSiren system to ORCA system you also need a virtual loopback MIDI-ports:
--DOWNLOAD-- loopMIDI for :
- Windows 7 up to Windows 10, 32 and 64 bit :
https://www.tobias-erichsen.de/software/loopmidi.html
#-= Cyber Notes [v15] =-#
- added BORG-IMPLANT module.
- introduction to special modules.
- more system testing.
#-= Special Modules [v15] =-#
- BORG-IMPLANT (connects ORCA MIDI system to NoxSiren system)
#-= Current Modules [v15] =-#
- VCO (voltage-controlled-oscillator)
- VCO2 (advance voltage-controlled-oscillator)
- WAVEBANK (additive synthesis oscillator)
- ADSR (Attack-Decay-Sustain-Release envelope)
- C-ADSR (Curved Attack-Decay-Sustain-Release envelope)
- CICADAS (128 steps-Euclidean rhythm generator)
- CICADAS-2 (advance 128-steps polymorphic-Euclidean rhythm generator)
- COMPRESSOR (lookahead mono compressor unit)
- DUAL-COMPRESSOR (2-channel lookahead mono compressor unit)
- STEREO-COMPRESSOR (lookahead stereo compressor unit)
- MONO-KEYS (virtual 1-voice monophonic MIDI keyboard)
- POLY-KEYS-2 (virtual 2-voice polyphonic MIDI keyboard)
- POLY-KEYS-3 (virtual 3-voice polyphonic MIDI keyboard)
- POLY-KEYS-4 (virtual 4-voice polyphonic MIDI keyboard)
- POLY-KEYS-5 (virtual 5-voice polyphonic MIDI keyboard)
- POLY-KEYS-6 (virtual 6-voice polyphonic MIDI keyboard)
- BATTERY (simple manual triggered machine for drumming.)
- REVERB (reverb unit with lowpass control)
- STEREO-REVERB (stereo reverb unit with lowpass control)
- RESIN (advanced rain effect/texture generator)
- NOISE (generates black,brown,red and orange noise)
- NOISE2 (generates yellow,blue,pink and white noise)
- COBALT (6-stage polyrhythm generator)
- SHAPER (basic shaper unit)
- FOLDER (basic wave folding unit)
- STEREO-FOLDER (stereo wave folding unit)
- DUAL-FOLDER (advance wave folding unit)
- POLARIZER (transform a signal into bi-polar, uni-polar, inverted or inverted uni-polar form)
- CLOCK (generates a BPM clock signal for sequencing other modules)
- CLOCKDIVIDER (a clock divider with even division of clock signal)
- CLOCKDIVIDER2 (a clock divider with odd division of clock signal)
- DELAY-UNIT (delay unit)
- STEREO-DELAY (stereo delay unit)
- CHORUS (chorus unit)
- STEREO-CHORUS (stereo chorus unit)
- SEQ (advance 16-step/trigger sequencer)
- KICK (synthesize kick unit)
- KICK2 (synthesize flavor of KICK module)
- KICK3 (synthesize flavor of KICK module)
- SNARE (synthesize snare unit)
- CLAP (synthesize clap unit)
- CYMBAL (synthesize cymbal unit)
- RAND (RNG generator for other modules parameters)
- FMOD (feedback modulation unit)
- AM (amplitude modulation unit)
- RM (ring modulation unit)
- LFO (low-frequency-oscillator)
- LFO2 (advance low-frequency-oscillator)
- COMBINATOR (combine two waves)
- COMBINATOR2 (combine three waves)
- COMBINATOR3 (combine four waves)
- STRING (Karplus-Strong string synthesis unit)
- STRING2 (advance Karplus-Strong string synthesis unit)
- DETUNER (parametric 4-channel detuner unit)
- CRUSHER (basic audio resolution unit)
- STEREO-CRUSHER (basic stereo audio resolution unit)
- DUAL-CRUSHER (advance audio resolution unit)
- FILTER (basic filter)
- VCF (voltage-controlled-filter)
- MAR (Moog-analog-resonant filter)
- VCA (voltage-controlled-amplifier)
- DUAL-VCA (advance voltage-controlled-amplifier)
- FMUX (multiplexer with fast A/D internal envelope)
- MMUX (multiplexer with medium A/D internal envelope)
- SMUX (multiplexer with slow A/D internal envelope)
- FDMX (demultiplexer with fast A/D internal envelope)
- MDMX (demultiplexer with medium A/D internal envelope)
- SDMX (demultiplexer with slow A/D internal envelope)
- MIXER (mix 1-4 possible waves)
- SCOPE (oscilloscope analyzer)
- MASTER (fancy DAC~)
- BOX (useless decorative module)
NoxSiren integrated modules menu system.
JASS, Just Another Synth...Sort-of, codename: Gemini (UPDATED: esp with midi fixes)
JASS, Just Another Synth...Sort-of, codename: Gemini (UPDATED TO V-1.0.1)
jass-v1.0.1( esp with midi fixes).zip
1.0.1-CHANGES:
- Fixed issues with midi routing, re the mode selector (mentioned below)
- Upgraded the midi mode "fetch" abstraction to be less granular
- Fix (for midi) so changing cc["14","15","16"] to "rnd" outputs a random wave (It has always done this for non-midi.)
- Added a midi-mode-tester.pd (connect PD's midi out to PD's midi in to use it)
- Upgrade: cc-56 and cc-58 can now change pbend-cc and mod-cc in all modes
- Update: the (this) readme
INFO: Values setting to 0 on initial cc changes is (given midi) to be expected.
JASS is a clone-based, three wavetable, 16 voice polyphonic, Dual-channel synth.
With...
- The initial, two wavetables combined in 1 of 5 possible ways per channel and then adding those two channels. Example: additive+frequency modulation, phase+pulse-modulation, pulse-modulation+amplitude modulation, fm+fm, etc
- The third wavetable is a ring modulator, embedded inside each mod type
- 8 wave types, including a random with a settable number of partials and a square with a settable dutycycle
- A vcf~ filter embedded inside each modulation type
- The attack-decay-release, cutoff, and resonance ranges settable so they immediately and globally recalculate all relevant values
- Four parameters /mod type: p1,p2, cutoff, and resonance
- State-saving, at both the global level (wavetables, env, etc.), as well as, multiple "substates" of for-each-mod-type settings.
- Distortion, reverb
- Midiin, paying special attention to the use of 8-knob, usb, midi controllers (see below for details)
- zexy-limiters, for each channel, after the distortion, and just before dac~
Instructions
Requires: zexy
for-entire-state
- O: Open preset. "default.txt" is loaded by...default
- S: Save preset (all values incl. the multiple substates) (Note: I have Not included any presets, besides the default with 5 substates.)
- SA: Save as
- TEST: A sample player
- symbol: The filename of the currently loaded preset
- CL: Clear, sets all but a few values to 0
- U: Undo CL
- distortion,reverb,MASTER: operate on the total out, just before the limiter.
- MIDI (Each selection corresponds to a pgmin, 123,124,125,126,127, respectively, see below for more information)
- X: Default midi config, cc[1,7,8-64] available
- M: Modulators;cc[10-17] routed to ch1&ch2: p1,p2,cutoff,q controls
- E: Envelopes; cc[10-17] routed to filter- and amp-env controls
- R: Ranges; cc[10-17] routed to adr-min/max,cut-off min/max, resonance min/max, distortion, and reverb
- O: Other; cc[10-17] routed to rngmod controls, 3 wavetypes, and crossfade
- symbol: you may enter 8 cc#'s here to replace the default [10-17] from above to suit your midi-controller's knob configuration; these settings are saved to file upon entry
- vu: for total out to dac~
for-all-mod-types
- /wavetable
- graph: of the chosen wavetype
- part: partials, # of partials to use for the "rn" wavetype; the resulting, random sinesum is saved with the preset
- duty: dutycycle for the "du" wavetype
- type: sin | square | triangle | saw | random | duty | pink (pink-noise: a random sinesum with 128 partials, it is not saved with the preset) | noise (a random sinesum with 2051 partials, also not saved)
- filter-env: (self-explanatory)
- amp-env: (self-explanatory)
- rngmod: self-explanatory, except "sign" is to the modulated signal just before going into the vcf~
- adr-range: min,max[0-10000]; changing these values immediately recalculates all values for the filter- and amp-env's scaled to the new range
- R: randomizes all for-all-mod-types values, but excludes wavetype "noise"; rem: you must S or SA the preset to save the results
- U: Undoes R
for-each-mod-type
- mod-type-1: (In all cases, wavetable1 is the carrier and wavetable2 is the modulator); additive | frequency | phase | pulse | amplitude modulation
- mod-type-2: Same as above; mod-type-2 May be the same type as mod-type-1
- crossfade: Between ch1 and ch2
- detune: Applied to the midi pitch going into ch2
- for-each-clone-type controls:
- p1,p2: (self-explanatory)
- cutoff, resonance: (self-explanatory)
- navigation: Cycles through the saved substates of for-each-mod-type settings (note: they are lines on the end of a [text])
- CP: Copy the current settings, ie. add a line to the end of the [text] identical to the current substate
- -: Delete the current substate
- R: Randomize all (but only a few) substate settings
- U: Undo R
- cut-rng: min,max[0-20000] As adr-range above, this immediately recalculates all cutoff values
- res-rng: min,max[0-100], same as previously but for q
- pbend: cc,rng: the pitchwheel may be assigned to a control by setting this to a value >7 (see midi table below for possibilities); rng is in midi pitches (+/- the value you enter)
- mod-cc: the mod-wheel may be assigned to a control [7..64] by setting this value
midi-implementation
name | --- | Description |
---|---|---|
sysex | not supported | |
pgmin | 123,124,125,126,127; They set midi mode | |
notein | 0-127 | |
bendin | pbend-cc=7>pitchbend; otherwise to the cc# from below | |
touch | not supported | |
polytouch | not supported |
cc - basic (for all midi-configs)
# | name | --- | desciption |
---|---|---|---|
1 | mod-wheel | (assignable) | |
7 | volume | Master |
cc - "X" mode/pgmin=123
cc | --- | parameter |
---|---|---|
8 | wavetype1 | |
9 | partials 1 | |
10 | duty 1 | |
11 | wavetype2 | |
12 | partials 2 | |
13 | duty 2 | |
14 | wavetype3 | |
15 | partials 3 | |
16 | duty 3 | |
17 | filter-att | |
18 | filter-dec | |
19 | filter-sus | |
20 | filter-rel | |
21 | amp-att | |
22 | amp-dec | |
23 | amp-sus | |
24 | amp-rel | |
25 | rngmod-freq | |
26 | rngmod-sig | |
27 | rngmod-filt | |
28 | rngmod-amp | |
29 | distortion | |
30 | reverb | |
31 | master | |
32 | mod-type 1 | |
33 | mod-type 2 | |
34 | crossfade | |
35 | detune | |
36 | p1-1 | |
37 | p2-1 | |
38 | cutoff-1 | |
39 | q-1 | |
40 | p1-2 | |
41 | p2-2 | |
42 | cutoff-2 | |
43 | q-2 | |
44 | p1-3 | |
45 | p2-3 | |
46 | cutoff-3 | |
47 | q-3 | |
48 | p1-4 | |
49 | p2-4 | |
50 | cutoff-4 | |
51 | q-4 | |
52 | p1-5 | |
53 | p2-5 | |
54 | cutoff-5 | |
55 | q-5 | |
56 | pbend-cc | |
57 | pbend-rng | |
58 | mod-cc | |
59 | adr-rng-min | |
60 | adr-rng-max | |
61 | cut-rng-min | |
62 | cut-rng-max | |
63 | res-rng-min | |
64 | res-rng-max |
cc - Modes M, E, R, O
Jass is designed so that single knobs may be used for multiple purposes without reentering the previous value when you turn the knob, esp. as it pertains to, 8-knob controllers.
Thus, for instance, when in Mode M(pgm=124) your cc send the signals as listed below. When you switch modes, that knob will then change the values for That mode.
In order to do this, you must turn the knob until it hits the previously stored value for that mode-knob.
After hitting that previous value, it will begin to change the current value.
cc - Modes M, E, R, O assignments
Where [10..17] may be the midi cc #'s you enter in the MIDI symbol field (as mentioned above) aligned to your particular midi controller.
cc# | --- | M/pgm=124 | --- | E/pgm=125 | --- | R/pgm=126 | --- | O/pgm=127 |
---|---|---|---|---|---|---|---|---|
10 | ch1:p1 | filter-env:att | adr-rng-min | rngmod:freq | ||||
11 | ch1:p2 | filter-env:dec | adr-rng-max | rngmod:sig | ||||
12 | ch1:cutoff | filter-env:sus | cut-rng-min | rngmod:filter | ||||
13 | ch1:q | filter-env:re | cut-rng-max | rngmod:amp | ||||
14 | ch2:p1 | amp-env:att | res-rng-min | wavetype1 | ||||
15 | ch2:p2 | amp-env:dec | res-rng-max | wavetype2 | ||||
16 | ch2:cutoff | amp-env:sus | distortion | wavetype3 | ||||
17 | ch2:q | amp-env:rel | reverb | crossfade |
In closing
If you have anywhere close to as much fun (using, experimenting with, trying out, etc.) this patch, as I had making it, I will consider it a success.
For while an arduous learning curve (the first synth I ever built), it has been an Enormous pleasure to listen to as I worked on it. Getting better and better sounding at each pass.
Rather, than say to much, I will say this:
Enjoy. May it bring a smile to your face.
Peace through love of creating and sharing.
Sincerely,
Scott
Building a Linux Desktop
@cheesemaster I don't think much matters with a modern computer.
This is interesting for Linux...... http://puredata.info/docs/faq/how-can-i-run-pd-with-realtime-priority-in-gnu-linux/?searchterm=linux audio but as it says...... probably out of date now with Jack.
You can set realtime priority for audio in Linux..... which helps a great deal..... but unless to are running [pd~] as well to spread load across cores Pd will only use one.
I have 6 Toshiba I5 Notebooks..... this.zip
that do everything for me on shows including running video and Pd at the same time with wireless osc control.
But I also have an I3 HD3000 machine (same model) that I run a show monitoring system on...... Pd based with massive amounts of OSC and monitor mixing and backing track playback........ in windows..... with no problems.
I paid $100-$200 each for them on Ebay.
However....... the fan noise is not great...... so don't buy any of those for your use.
Large RAM can be useful, and an SSD obviously, but processor speed is irrelevant for audio nowadays.
Ports...... USB...... more than one on-board hub..... because if you connect a USB1 device to the same hub running USB2 audio it will knock the whole hub down to USB1.
USB2 is enough for at least a 30in 30out soundcard...... avoid firewire as it will break expensively at some point.
Beware of Wi-Fi cards that could behave badly causing interrupts and so clicks.... that might not be true in Linux though..... but do some research.
Again..... USB...... Macs connect their keyboards and cd drives through an onboard hub so it is essential that they have a second one free for any soundcard. If they have a USB3 then that can be used for a USB2 soundcard though.
Native instruments only had advice for windows before, but have this for OSX...... which could be relevant being UNIX....... https://support.native-instruments.com/hc/en-us/articles/210296445-Mac-Tuning-Tips-for-Audio-Processing
David.
P.S. @Eeight has just come on line and is an expert so.........
Purr Data 2.10.0 released
Purr Data 2.10.0 is now available:
https://github.com/jonwwilkes/purr-data/releases/tag/2.10.0
Changes:
- iem_spec2/spec2_tabreceive_enable~: fix array error handler and set sane default array name value
- fix partconv crashers in bsaylor lib and add perfroutine for array errors
- adaptive/nlms3~: fix typo that caused a double free
- fix lyonpotpourri crashers in dsp, perform and constructor routines
- at least keep the inoperable streamout13~ and streamin13~ from crashing when instantiating
- use some sane default values in ekext/lpreson~ to prevent segfault
- quick fixes to keep cxc/mean~ from crashing when dsp is turned on
- greatly reduce undefined behavior in all dsp objects
- fix hex2dec so that it actually does something useful
- fix #523: crash with manual width adjustment on subpatch
- add ability to change makefile flags for Gem from toplevel makefile
- fix stray bugs detected by obs
- unauthorized/cooled~: increase string buffer size to accommodate the terminating nul character
- unauthorized/cooled~: fix memory access bug trying to concatenate into a string constant
- iemmatrix/mtx_dispersive_dline: add missing void return type
- allow make options like -j8 to be passed to the Gem compilation, which takes awfully long on a single cpu.
- cxc/cxc_split: fix use of un-initialized pointer
- ggee/serial_bird: fix undefined behavior with the ++ operator
- ext13/scramble~: fix header for scramble~
- jasch_lib/detox/detox: reformat for sanity's sake, fix array overflow, undefined behavior
- linux desktop: remove the -rt -audiobuf options from the desktop files.
- linux desktop: change DEFAULTADVANCE to 20 ms for Linux.
- linux desktop: remove leftover TargetEnvironment=Unity lines in menu entries for Purr Data
- linux desktop: add some comments and a few more useful desktop action examples to the main desktop file, so that the user understands how to adjust these if needed.
- linux desktop: replace pd-gui -> nw in the ForceQuit actions, which is the proper name of the GUI program on Linux
- linux desktop: remove useless %U arguments from desktop actions.
- linux desktop: invoke desktop actions via /bin/sh.
- linux desktop: migrate the desktop actions from the ancient Unity syntax to the current freedesktop.org standard
- linux desktop: remove sticky options from the desktop files. For now, keep -rt -audiobuf 20.
- Gem: sync with https://github.com/umlaeute/Gem, QT4L and startup issues have been fixed
- linux: fix the Debian control files once again, since the dependency auto-detection needs a Depends line in there.
- debuild: Support for ARM (e.g., Raspbian)
- update nw-update to nw.js 0.24.4 to fix font issues under Linux
- backport 'add-to-path' from vanilla rev. c917dd19, to make Gem happy.
- usability improvements in the documentation browser.
- switch Gem to the latest from upstream.
- add missing dlls for fluid~ on Windows. Fixes #540.
- Debian packaging: Demote python and fluid-soundfont dependencies, as suggested in #540.
- polish the externals/Makefile clean targets, and delete redundant files in repo
- fix compile options for Xcode 10 - fftease and lyonpotpourri externals.
- update pd-lua to latest upstream.
- fix compile options for Xcode 10 - externals and abstractions.
- fix compile options for Xcode 10.
- ios header needs to be included before base64.h, to avoid compile errors on macOS 10.14.
- fix improper string access in pd_getdirname on Mac.
- fix list cat crasher, update help patch, add missing test abstractions
- get rid of obsolete and unneeded unicap and sndobj dependencies on Linux.
- mark some globals as extern to fix compilation if g_canvas.h is included more than once
Please report bugs here:
MusicPlayer extension for the Ofelia effect VideoPlayer ;)
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:
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;
;