Ganymede: an 8-track, semi-automatic samples-looper and percussion instrument based on modulus instead of metro
Ganymede.7z (includes its own limited set of samples)
Background:
Ganymede was created to test a bet I made with myself:
that I could boil down drum sequencing to a single knob (i.e. instead of writing a pattern).
As far as I am concerned, I won the bet.
The trick is...
Instead of using a knob to turn, for example, up or down a metro, you use it to turn up or down the modulus of a counter, ie. counter[1..16]>[mod X]>[sel 0]>play the sample. If you do this then add an offset control, then where the beat occurs changes in Real-Time.
But you'll have to decide for yourself whether I won the bet. .
(note: I have posted a few demos using it in various stages of its' carnation recently in the Output section of the Forum and intend to share a few more, now that I have posted this.)
Remember, Ganymede is an instrument, i.e. Not an editor.
It is intended to be "played" or...allowed to play by itself.
(aside: specifically designed to be played with an 8-channel, usb, midi, mixer controller and mouse, for instance an Akai Midimix or Novation LaunchPad XL.)
So it does Not save patterns nor do you "write" patterns.
Instead, you can play it and save the audio~ output to a wave file (for use later as a loop, song, etc.)
Jumping straight to The Chase...
How to use it:
REQUIRES:
moonlib, zexy, list-abs, hcs, cyclone, tof, freeverb~ and iemlib
THE 7 SECTIONS:
- GLOBAL:
- to set parameters for all 8 tracks, exs. pick the samples directory from a tof/pmenu or OPEN_IND_DIR (open an independent directory) (see below "Samples"for more detail)
- randomizing parameters, random all. randomize all every 10*seconds, maximum number of bars when randomizing bars, CLR the randomizer check boxes
- PLAY, L(imited) or I(nfinite) counter, if L then number of bars to play before resetting counter, bpm(menu)
- MSTVOL
- transport/recording (on REC files are automatically saved to ./ganymede/recordings with datestamp filename, the output is zexy limited to 98 and the volume controls the boost into the limiter)
- PLAYHEADS:
- indicating where the track is "beating"
- blank=no beat and black-to-red where redder implies greater env~ rms
- MODULAE:
- for information only to show the relative values of the selected modulators
- WEIGHTS:
- sent to [list-wrandom] when randomizing the When, Accent, and Offset modulators
- to use click READ_ARRAYS, adjust as desired, click WRITE, uncheck READ ARRAYS
- EVEN=unweighted, RND for random, and 0-7 for preset shapes
- PRESETS:
- ...self explanatory
-
PER TRACK ACCORDION:
- 8 sections, 1 per track
- each open-closable with the left most bang/track
- opening one track closes the previously opened track
- includes main (always shown)
- with knobs for the sample (with 300ms debounce)
- knobs for the modulators (When, Accent, and Offset) [1..16]
- toggles if you want that parameter to be randomized after X bars
- and when opened, 5 optional effects
- adsr, vcf, delayfb, distortion, and reverb
- D-W=dry-wet
- 2 parameters per effect
-
ALL:
when ON. sets the values for all of the tracks to the same value; reverts to the original values when turned OFF
MIDI:
CC 7=MASTER VOLUME
The other controls exposed to midi are the first four knobs of the accordion/main-gui. In other words, the Sample, When, Accent, and Offset knobs of each track. And the MUTE and SOLO of each track.
Control is based on a midimap file (./midimaps/midimap-default.txt).
So if it is easier to just edit that file to your controller, then just make a backup of it and edit as you need. In other words, midi-learn and changing midimap files is not supported.
The default midimap is:
By track
CCs
---TRACK--- | ---SAMPLE--- | ---WHEN--- | ---ACCENT--- | --- OFFSET--- |
---|---|---|---|---|
0 | 16 | 17 | 18 | 19 |
1 | 20 | 21 | 22 | 23 |
2 | 24 | 25 | 26 | 27 |
3 | 28 | 29 | 30 | 31 |
4 | 46 | 47 | 48 | 49 |
5 | 50 | 51 | 52 | 53 |
6 | 54 | 55 | 56 | 57 |
7 | 58 | 59 | 60 | 61 |
NOTEs
---TRACK--- | ---MUTE--- | ---SOLO--- |
---|---|---|
0 | 1 | 3 |
1 | 4 | 6 |
2 | 7 | 9 |
3 | 10 | 12 |
4 | 13 | 15 |
5 | 16 | 18 |
6 | 19 | 21 |
7 | 22 | 24 |
SAMPLES:
Ganymede looks for samples in its ./samples directory by subdirectory.
It generates a tof/pmenu from the directories in ./samples.
Once a directory is selected, it then searches for ./**/.wav (wavs within 1-deep subdirectories) and then ./*.wav (wavs within that main "kit" directory).
I have uploaded my collection of samples (that I gathered from https://archive.org/details/old-school-sample-cds-collection-01, Attribution-Non Commercial-Share Alike 4.0 International Creative Commons License, 90's Old School Sample CDs Collection by CyberYoukai) to the following link on my Google Drive:
https://drive.google.com/file/d/1SQmrLqhACOXXSmaEf0Iz-PiO7kTkYzO0/view?usp=sharing
It is a large 617 Mb .7z file, including two directories: by-instrument with 141 instruments and by-kit with 135 kits. The file names and directory structure have all been laid out according to Ganymede's needs, ex. no spaces, etc.
My suggestion to you is unpack the file into your Path so they are also available for all of your other patches.
MAKING KITS:
I found Kits are best made by adding directories in a "custom-kits" folder to your sampls directory and just adding files, but most especially shortcuts/symlinks to all the files or directories you want to include in the kit into that folder, ex. in a "bongs&congs" folder add shortcuts to those instument folders. Then, create a symnlink to "bongs&congs" in your ganymede/samples directory.
Note: if you want to experiment with kits on-the-fly (while the patch is on) just remember to click the REFRESH bang to get a new tof/pmenu of available kits from your latest ./samples directory.
If you want more freedom than a dynamic menu, you can use the OPEN_IND(depedent)_DIR bang to open any folder. But do bear in mind, Ganymede may not see all the wavs in that folder.
AFTERWARD/NOTES
-
the [hcs/folder_list] [tof/pmenu] can only hold (the first) 64 directories in the ./samples directory
-
the use of 1/16th notes (counter-interval) is completely arbitrary. However, that value (in the [pd global_metro] subpatch...at the noted hradio) is exposed and I will probably incorporate being able to change it in a future version)
-
rem: one of the beauties of this technique is: If you don't like the beat,rhythm, etc., you need only click ALL to get an entirely new beat or any of the other randomizers to re-randomize it OR let if do that by itself on AUTO until you like it, then just take it off AUTO.
-
One fun thing to do, is let it morph, with some set of toggles and bars selected, and just keep an ear out for the Really choice ones and record those or step in to "play" it, i.e. tweak the effects and parameters. It throws...rolls...a lot of them.
-
Another thing to play around with is the notion of Limited (bumpy) or Infinite(flat) sequences in conjunction with the number of bars. Since when and where the modulator triggers is contegent on when it resets.
-
Designed, as I said before, to be played, esp. once it gets rolling, it allows you to focus on the production (instead of writing beats) by controlling the ALL and Individual effects and parameters.
-
Note: if you really like the beat Don't forget to turn off the randomizers. CLEAR for instance works well. However you can't get the back the toggle values after they're cleared. (possible feature in next version)
-
The default.txt preset loads on loadbang. So if you want to save your state, then just click PRESETS>SAVE.
-
[folder_list] throws error messages if it can't find things, ex. when you're not using subdirectories in your kit. No need to worry about it. It just does that.
POSTSCRIPT
If you need any help, more explanation, advise, or have opinions or insight as to how I can make it better, I would love to hear from you.
I think that's >=95% of what I need to tell you.
If I think of anything else, I'll add it below.
Peace thru Music.
Love thru Pure Data.
-s
,
Dynamically patched vslider with local send symbol
@oid This is a problem from my 2nd ever dynamic patch, so I wouldn't try to read deep meaning into my questions . Like my first dynamic patch, it's just a patch that generates the repetitive, static parts of other patches--a way to reduce the tedium of having to edit multiple send/receive names by hand, that's all. I'm expecting to have to cut and paste from this helper patch into the patch I'm really trying to write, so the value of $0 in the generating patch is irrelevant. Is that reasonable? In a patch that needed its UI to be dynamically generated, your way would make total sense, but I'm def not there yet. Also, regarding your other topic, I think the message that dynamically generates a vslider can itself be static, so I'm not sure that add2 technique is applicable.
@ingox OK, now I'm getting the same results as you, which is odd because the patch I've presented is just a small example from a larger patch that was giving me trouble. After discovering the $\$0
syntax I applied it to that larger patch, saw that it too was working, and then posted this topic. But now my larger patch is broken, which makes me believe that the system is behaving differently since running your patches (and that I wasn't previously hallucinating). But that can't be true, right?
So here's another small patch to demonstrate how my larger patch is (now) broken: dynamicPatchVerticalSlider2.pd
See how \$0
is just generating a 0
in the send symbol? When I save and reload it to test the fader (which doesn't work), the backslash gets dropped from the creation message!
So next I try falling back to the syntax I got working earlier, and the generated vslider send symbol looks good
and on reloading it I can confirm that it is good, but now I can't use my generating patch because $1 is backslash escaped!
"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!
Question about Pure Data and decoding a Dx7 sysex patch file....
For the Blofeld editor, well, it's a one way communication editor(for now), the editor only sends data to Blofeld, I can not change a parameter directly on Blofeld and then the editors parameter follows. I didn't do that yet, but it's on the to do list.
In my last post, when I refer to a sound dump, it's the same as a patch dump. But what I did there was only to start the sound dump on Blofeld by sending the "request sound dump" sysex string from Pd to Blofeld, to dump the current sound from Blofeld and then receive the sound dump in Pd. I did not try to decode the sound dump to get the individual parameters. So can't use that for the Dx7 approach.
I did get an idea from your posts, though, how I might be able to "backwards engineer" the sysex patches from Dx7:
- Use the free Dexed dx7 and export a patch sysex dump for reference.
- Then use the same patch and change ONE single parameter and export the patch as sysex dump.
- Compare the two sysex dumps and see which values have changed. The value changed is the parameter I am looking for. I can then assign it to a fader in my Dx7 editor.
- Do it a few times with a few different parameters, until I find a pattern. Or just do it for every single parameter, to be on the safe side......
(Dexed Dx7 editor/Vst - https://www.kvraudio.com/product/dexed-by-digital-suburban/downloads)
I know, it's not the smartest way, but it worked for Blofeld and since this is "only" around 150 params in total it should be manageable, as a weekende project
About the 32 voices, ahh yes, you are probably right, it's the amount of presets, not actual polyphonic voices. Would love to get that working too, to get all 32 voices/presets of a voice card dump. There are a lot of them around.
Thanks again. I actually though sysex messages for full patch dump was more complicated. If all parameters are just individual numbers in the sysex string, it's doable, just a bit time consuming.
Patch that will play different chords with [midi] input
Hello dear PD patchrepo community !
I'm currently trying to make a PD patch that will basically produce different chords when I use different keys on my midi keyboard. I stumbled upon one patch which seems to be a good basis for my work so far but it's too limited ; I'm not very technical savy ( more of a musician actually ) but for my course ( bachelor in sound engineering ) I'm supposed to make a patch that generates chord when I play a note on my MIDI keyboard.
I'd like to generate different chords ( for example minor chords, major chords, and scales for example ) which would be triggered when I use keys on my midi keyboards; do you think this is feasible ?
So far this is what I got;
Just to make it clear for example I'd like my patch to generate a C major seventh cord by inputing the C key on my midi keyboard and add more versatility to my patch by adding extra functionalities such as being able to make a reversed chord too...
I'm struggling to build this patch and any help would be greatly appreciated !
Thanks a lot !
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.
Shared references to stateful objects?
This is how i see it:
┏━ | ━━━━━━━━━━━━━━━━━━ | ┳━ | ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ | ┓ |
---|---|---|---|---|
┃ | Functional programming | ┃ | Pure Data | ┃ |
┡━ | ━━━━━━━━━━━━━━━━━━ | ╇━ | ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ | ┩ |
├ | Function | ┼ | Abstraction | ┤ |
├─ | ────────────────── | ┼─ | ──────────────────────────────── | ┤ |
├ | Define function in code | ┼ | Create abstraction as separate file | ┤ |
├─ | ────────────────── | ┼─ | ──────────────────────────────── | ┤ |
├ | Call function | ┼ | Send a message to left inlet of the abstraction | ┤ |
├─ | ────────────────── | ┼─ | ──────────────────────────────── | ┤ |
├ | Arguments | ┼ | Input into the inlets and creation arguments | ┤ |
├─ | ────────────────── | ┼─ | ──────────────────────────────── | ┤ |
├ | Return values | ┼ | Output of the outlets | ┤ |
├─ | ────────────────── | ┼─ | ──────────────────────────────── | ┤ |
├ | Local variables | ┼ | $0 in object names | ┤ |
├─ | ────────────────── | ┼─ | ──────────────────────────────── | ┤ |
├ | Recursive function | ┼ | Manual recursion by using [until] outside of the abstraction | ┤ |
└─ | ────────────────── | ┴─ | ──────────────────────────────── | ┘ |
Nek'Sum - An advanced drone/texture monophonic synthesizer <- [v6.0] + // Mandarin Edition //
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 :
issue with array bounds rectangle inside gop subpatch (purr data)
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:
- 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?
- 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.
- 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.
Feedback FM algorithm
@RandLaneFly Your pet subject has had people scratching their heads for a long time now..... https://cycling74.com/forums/dx7-problem-feedback-generator
They discussed a duplicate modulator at the time.
And also a subpatch at blocksize 1 write/reading an array with [tabsend~] and [tabread~]
It does seem likely that once your modulator has calculated its values for a 64 block and fed them back the delay will cause additional complex modulation that is maybe what you see in your FM8 waveform and not in that from the DX7.
Were your spectra all sourced in the digital domain or was there some analogue involved? Some of it looks like analogue noise and some like digital clipping.
David.