AV Soundscape // Mars // Patch available for download
Download the patch here: https://patchstorage.com/av-soundscape-mars/
Data visualization patch for "mars" soundscape. RGB and movement data were extracted to a .wav file using GEM. The data was then used to sonify using different instruments along with various random algorithms to create more variety.
AV concept and data programming done on TouchDesigner by Andres Ponce Soundscape and sound programming done on Pure Data by Miguel Moreno Interface was added in post using DaVinci Resolve.
Original Video: https://www.instagram.com/p/CLzSsO9Ji49/
--
Link Tree: https://linktr.ee/MikeMorenoDSP
Did random seed change?
@seb-harmonik.ar said:
The rationale is that the behavior of a patch SHOULD be completely reproducible if desired (and that's the intent).
@jameslo said:
How could you reproduce them (in order to study them) if the pseudo-random number sequence wasn't deterministic?
There might be exceptions, but in every pseudorandom number generator I've ever heard of, the sequence does repeat, provided that it's been seeded with a consistent value first.
SuperCollider seeds the random number generator at startup based on some value calculated from the system time. If you want replicable behavior, you do thisThread.randSeed = /* some value explicitly under your control */
at the moment of your choosing.
Pd [random] does implement a "seed xxx" message, so it isn't correct to suggest that Pd's constant initial seed is the way to get a replicable sequence. That's lucky if that's what you want, but it isn't necessary, and it may not be ideal either.
The problem with the counterargument here is that the [random] behavior depends on factors outside the user's direct control. If you really want a replicable sequence, the way to be certain of that is to send a "seed xxx" message to the random number generator at a moment that is under your control. Otherwise, you have no control over other components that might be pinging the random number generator. (Suppose, for instance, your patch depends on an abstraction which pings a [random] from a [loadbang]. Then, later, the abstraction author thinks, no, I shouldn't do that, I should get that first random value only on demand. Then you move your patch to another machine, re-download the abstraction from its source, and bang the behavior is different.) edit: that's a bad example, never mind.
Viewed from that perspective, one could say that the current Pd behavior misled the OP to believe that it wouldn't be necessary or desirable to control the seed... and then something changed somewhere in the system. That's actually quite a bad situation -- OP relied on happenstance for a mission-critical sequence of notes, and it isn't clear how to recover the original behavior.
Now this part is interesting, from whale-av: "There seems to be a shift......... the 2nd 3rd 4th etc. created are the same as the 1st 2nd 3rd etc. used to be." One possible explanation could be that, in the old version, something was consuming one random value before the user patch did (so the user patch never saw the true first value) -- so in the old system, the "first" random value would have been the second to be generated. Then, in the later case, the first value to be seen is the real first value. (But that might be -- or, is probably -- something in the test scenario and not in Pd itself.)
hjh
Extract filter params from impulse response?
Early in the pandemic I learned that I could ping a filter, record its impulse response, and convolve another signal with that impulse response to approximate that filter, admittedly in the most inflexible, CPU-hogging, and memory-wasting way. But hey--it was exciting to learn that it was possible!
Is it possible to go the other way, from an impulse response to the parameters for some arrangement of low pass/hi pass/band pass filters? Not for an arbitrary impulse response, but for decaying resonances, like the sound of a tap on the bottom of a plastic cup? The solution doesn't have to be exact, analytic, in real-time, or completely automated, nor does it have to use Pd exclusively. I just want to find a way to model these sounds other than using my ear + trial and error.
Edit: I just tried this--in Reaper, I recorded plastic cup tap, convolved it with white noise, listened and looked at its spectrum. On another track, I tried to match the sound and spectrum using the same white noise through 5 bands of parametric EQ and got closer than I thought I would. I then tried to port that parametric to Pd and pinged it. It only slightly resembles the original cup, but my port of that filter could be junk.
Edit 2: my port IS junk! I just made Pd ping the Reaper EQ and it sounds much closer!
Edit 3: but I still welcome any suggestions on how to do this better. I see that there is an FIR filter in Reaper that allows me to enter an arbitrary frequency response, but I can't alter that response dynamically so it defeats the purpose.
New version of Pd - [pink~] and [freeverb~] disappeared
I have been running some old patches in the latest version of Pd and get error messages for [pink~] and [freeverb~] indicating they are not supported. Are there newer versions that provide pink noise and reverb?
Question about arrays
@ingox @dfkettle The ping hack probably doesn't work when writing the array on OSX..... but does in Purr Data....... so that might be a problem for the sharing of the patch.
https://forum.pdpatchrepo.info/topic/12892/how-can-i-trigger-a-message-when-any-array-value-is-changed
The problem can be solved for OSX with the experimental mouse plugin...... you will find it in the same thread.
Plugins need to be where Pd can find them as it starts up though....... so they must be in the bin folder or another that is "known" to Pd.
That means if you distribute the plugin you will need a "readme" to tell people how to use it as [declare -path] in your patch will not tell Pd where it is until after Pd has started.
See also @jancsika 's note about the array size and ping (same thread)........ (GUI_BYTESPERPING).
David.
Question about arrays
Thanks! It does exactly what I want. Where can I learn more about "ping" and other Pd messages? I never would have guessed that a "ping" msg is sent when you update an array. I found this page on the web site and downloaded the zip file containing examples, but couldn't find any example for "ping".
https://puredata.info/community/pdwiki/PdInternalMessages
And why is the [delay] needed?
Animation jitters!?
@JackOats I have messed around with it a little..... ping-pong.pd
Adding a [line] to smooth the x and y values helps....... but it was not jittering as badly as in your video before I started.
Putting a [print] on Y some numbers were repeating...... which would be jitter.
Adding [+ 2] to the timing for [line] seems to have solved that.
If it is smooth on your system then [line] could be the solution for the other patch.
Connecting [print] to data is a good way of troubleshooting many things but especially fast changing numbers.
David.
Animation jitters!?
@whale-av - Does this work?
Ping Pong.001 copy.pd Ping Pong.001 copy.pd
This is a different patch from the one I sent - but the 'Jitters' problem is the same.
How to send multicast audio in Pure Data?
@romulovieira-me After further reading...... yes... you probably need to tell the interface on the receiving computer to join the group.
This is useful reading........ https://tldp.org/HOWTO/Multicast-HOWTO-2.html ....
But if you ping 239.0.0.1 from your sending computer you will probably find that r-inspiron3442.local is already a group member (as osc is working).
If that is the case then [streamin~] is the problem as it never makes a request to the os to receive a multicast address.
If the ping is not returned then do a google search for "Linux '(whichever) IGMP" to find out how to join the group.
David.
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