Hi, sir, I just wanted to congratulate you for the MultiNoise osc; I just use it all the time for my Harsh Noise Wall project! This Random input is simply perfect!
SirSickSik Contributions
Amazing work in this thread that just continues to inspire @SirSickSik did you end up completing the custom super synth all these modules were contributing to? Given the quality of your work I'd love to see it in action
I've made several setups, but I haven't been completely satisfied yet about the way I had to control all of it (bit hard with a small midi controller with no visual feedback of controlled parameters).
Though this is one of the latest track I recorded with my axo-case, (ab)using a beatstep pro (only c-scale notes are actually used to play notes from a 7-note scale, all others control others aspects like preset-randomisation, scale/key changing, so I could sequence those too. So only the actual drum sequencer plays the gates of all the voices&drums and some extra parameters.
Also I'm currently putting a bit more energy into my modular system to get that one ready. Of which one part is getting that new small axol and make me a live fft-oscillator module and a giant reverb/fx module.
next "suitcase setup" track:
completely generated by 5 axoloti's. Just uses a single "core" drum sequence (variations are made on the fly using some algorithms), all other patterns and changes are created at function-controlled-random, no manual control here! Everytime I restart the axoloti's, it will sound different, even scale&chord progressions are randomised. Before this recording, I quickly recorded 16 samples of me saying some short nasty stuff with a nasty voice.
switch(axoloti_board_number)
{
case 1:
-midi control board generating a clock that randomly chooses between seconds and thirds and sends a message to all boards which it has chosen, so everything follows in the timing. Next to this, also the current play position is send, so everything is always locked to the same count. To make the timing of all modules really precise, I send out the current main k-rate tempo using 4 midi-CC, so all modules in other boards match the current tempo precisely.
-main "key" (rootnote of scale, tonnetz movement), scale (which note-spacings are used for the 7 notes of the scale) and a chord sequencer (which of the 7 notes may actually be used). Loosely based on the eurorack sinfonion and a bit further extended. Making sure all the voices keep in tune with each other no matter what.
-drum pattern midi generators: 16 step, 4 level sequencers with random flam and roll. One dedicated to kick and one for hihats (functioning as the legs). Then two others for the "arms" of the drummer, which will use patterns to select the different drums while taking into account how far the arm could have maximally moved based on the speed of the incoming triggers. Then one last one to force one of these sequencers to play the snare when needed.
-several of the same sequencers to trigger the bass, drone and "guitar" and voice-samples.
-16-sample 1.5sec/sample recorder and granular playback.
;break;
case 1:
-drum patch with the pattern-generator/"arm-allocator" featuring basskick, snare, 3 toms, 1 multi-function percussion, hihat, cymbal, fm-bell and 2 random percussion generators (all different kinds of synthesis). Kick goes out left channel, voice from board 1 gets mixed with the other percussion and being send out on right channel.
;break;
case 2:
-bass generator, started out as a vowel-oscillator, but proved to be awesome for a kind of "slap"-bass.
-percussion/voice/bass (no kick) stereo glitch fx with around 20 simultanuous fx (with a controllable "chance" randomly selected with a "max" amount of effects that can be simultanuously active). Bass goes through left channel, percussion&voice through right channel of glitch fx. Kick bypasses the glitch and is then mixed with the percussion output and going through a soft-drive. Drums are then output to the left channel, bass to the right channel.
;break;
case 3:
-mono voice/drone generator. Ifft-based oscillator that morphes through a bank of 2048 preset fft-spectra to set amplitudes of root and overtones of the waveform (throat), then windows/multiplies it by an 8-preset fft-window spectrum (serves as a fixed filter that doesn't follow the pitch, like the mouth changing the spectrum of the throat sound).
Also has a strummed semi-random overtone "plucker" to trigger individual overtones which can then damp and spread out their energy to neightbouring harmonics. Some extra functions serve to relocate/morph the amplitudes of the harmonics to other harmonics to continuously change the spectrum. Also the phase-values of the ifft are being slowely modulated independently to create an always evolving waveform. When the waveform-sample is generated, 4 sample-oscillators use this waveform, but can have different (random&fixed) pitch-offsets to create a kind of chorusing effect.
Percussion is send forward to the left channel output, bass is mixed with the drone voice and goes out right.
;break;
case 4:
"guitar" generator. Also a kind of vowel oscillator, but instead of having 3 seperate sine oscillators being synced and amplitude modulated by the main oscillator, this one just consists of 1 oscillator that morphs through sines, driven by the same phase, but having this phase multiplied at different amounts to create different harmonic overtones (up to 32 different rates still only takes 7%, as basically at every moment, it's just one phase and 3x a sine calculation instead of 32 different sines). This is followed by a set of distortions with biquad band-pass filters to set the distortion's character.
Actually, the amount of filters in all the patches is quite low, as the synthesis-modes used already limit the amount of harmonics being generated for most of the voices.
At the end of the chain, all channels are finally being mixed together and send out in stereo (yes, I do still need one more fx to create a nice stereo image)
;break;
}
NEW MODULES (ok, I uploaded some more in the meantime, but forgot to mention it, but there are some really useful ones now for when you use multiple axoloti's and want them to perfectly stay in sync ánd tune. I've made these module to create my 5-board axoloti setup)
MIDI
-"clkIN" and "clkOUT"
two modules that work together between different axoloti boards to share (next to the normal midi messages) actual play position (14bit counter position), main chord/scale/temperament(use 137temperament module) being used, a main randomisation trigger and 3 extra "main" triggers. The clock message can be switched between 2nds and 3rds and also this setting is shared over midi, so all other boards can immediately follow and stay in track. This clock runs at a division of the current play position, which should be seen as the "1/4 beat", so clock runs on either 1/8 or 1/12.
It also shares the main tempo setting in 28bits (using 4 midi messages), so all boards know exáctly how fast their lfo's and envelopes should be to stay in sync.
-"scaleReceiver" is a module that will receive the scale-notes that are send by the clkOUT module and can be controlled by a positive integer selecting an allowed note. For each of the 7 notes in the scale there is a toggle switch to allow which notes may be actually played from the scale (eg only 1-3-5 or 9-11-13 for a Cmajor or Dminor respectively)
-"chord builder" works in conjunction with the "scaleReceiver" module to control which chord is build from the scale using a chord root note, spreading of the chord and harmonicity (how many notes a chord is build up from). Though for this, you need to select midiCC for the toggle switches.
-"THRU" was an already existing module but I found out it didn't yet forward áll midi messages, but now it does (except sysex)
DIST
-"quadist" is a quad-mode distortion: sine-shaper, hard clip, tube and morphing stacked soft clipper
FILTER
-"champ" is a chamberlin filter, which, to me, sounds really nice. If I remember correctly, I also added a version with a compressor in the resonance feedback.
-"lowpress" is a filter brought about by a small experiment based on the normal 6dB lp filter. I added resonance and 2 controls to boost mid (pressence) and low.
-"neuronium" is based on the idea of the jomox neuronium. 6 neurons act and react on each other and produce all kinds of weird noises. Usable as standalone noise generator or as some kind of filter/distortion by feeding the first 3 neurons external inputs. Uses quite a lot of cpu, but might be useful somewhere. Just try out the factory edrum modules together with a sine for a bass and send them to the influence inputs, even simple sounds can go wacky.
AUDIO
-"StOutVolNorm" a stereo audio output module that keeps track of the peak output and has a normalisation function to set the volume control so it's output peaks maximally come to 32 to prevent clipping at the audio output (and to normalise patches with different modules/settings)
PATCH
-"sendPatch" and "patchloader". These module use incoming midiCC to select patches on other boards from a control-board.
The sendPatch has 3 inputs to set the minimum and maximum patch index that may be selected by next, previous or jump (jump is just next, but with min and max set to the same patch index).
These command are send using midiCC and changed into a patch-change command in the receiving board. As it responds to a midi-message, there is no accidental retriggering of patchchanges.
It also has a timer and pre&post triggers so you can trigger certain events before or after switching (eg. updating the loaded patch to the right scale or tempo currently used or to send an all-notes-off if needed).
Hardc0re k1ck --- for Hohum Labs Axoctrl
Hi Sir,
I was looking in the library for these objects:
scaleReceiver, chord builder, neuronium
alas, I could not find them. My lib is synced though..
Any chance you forgot to upload them?
Thanks for all the great objects!
Isn't this just beautiful?
This controls a fft2waveform generator with a XYZ wave-morph recorder that is independently played for each of the 8 voices.
Scales are build up using the 12 buttons below and show up on the tonnetz-keyboard in red, which can be played with multitouch with up to 10 fingers!
This is just my home-controller to play with my axoloti's in a more intuïtive way. As a lot of my modules have quite a bunch of controls, it's sometimes hard to make it playable by a conventional midi controller. Using my touch screen allows me to make dedicated controllers for all the modules I write with a layout that better fits the usage.
That said, for people who are interested in the OSC/PILOT software: it seems to be still under development and some functions are shown in the menu, but not yet working. I got me the software as it finally allowed me to also send midi signals directly, but found out too late that midi-talkback isn't yet supported, which forced me to also install "touchdesigner" to convert the midi talkback into OSC before sending it to OSC/PILOT. Doing that kinda takes away the need for the program to have midi output, as this also could be done with "touchdesigner". So if you find a touch-program that seems to have more/better controller options, but only has OSC, just get touchdesigner with it and go for that...
NEW MODULE
"frqshiftQ" and "frqshiftQmix"
The first is a frequency shifter that takes in real&imaginary parts of a signal (eg. sine&cosine) and multiplies these with the internal quadrature (sine/cosine) oscillator to create up and down shifted versions of the input.
For custom waveforms, the contrib/jt/iq-split module can be used to create a real and imaginary pair (hilbert transform).
By inversion of the internal sine and swapping the real&imaginary input signals, a second shifted pair is created that itself is shifted 90 degrees in phase in comparison to the other shifted version, thus allowing easy stacking of frequency shifters without the need of any more phase-shifting filters.
An extra real&imaginary shift-input is added to use custom oscillator waveshapes to do the frequency shifting.
On facebook I just started the group "axoloti user community".
Please join, this way we can have an extra platform besides this forum to help each other out and probably you'll also get a quicker response on your questions as more people are continuously connected to facebook instead of this forum.
Just my opinion - Facebook is a terrible discussion forum. Unsearchable, strange attempts at sorting discussions by relevance. This forum is far superior.
And Facebook is basically evil, but that’s another topic.
An Axoloti Discord server could be fun too, supplemental to Facebook and this forum. I could see it being good for getting crossover users from other synth/music related servers. Don't want to derail the topic, but it sounded like a fun idea
as a non-facebooker, i strongly support this!
besides the obvious problems with FB, also i would find it very sad to fragment discussions for the sake of a few hours of percieved faster turnaround.
so far this forum seems wonderfully reactive, no question goes unanswered and everybody profits from reading about subjects, he/she might even never thougt about.
please lets keep information in one place!
What's wrong with this forum? Akso discord was a mess and a fb page can be useful to show our faces and how old we are , but not for technical purposes
I have some questions about Factotum, if you don't mind.
When I connect a physical pot to the 'length' input, it acts super weird. bitcrusher-like effect. With a dial object it acts normal. Any ideas why that is? The feedback knob does something similar, or rather, it does nothing at all with a gpio input in it, but with a dial object it works perfectly.
Is there a way to set the "end point" of the buffer/table, so that it doesn't have to go through the whole table before it records again? I have it so it's always recording, playing and overwriting (like a delay), but if I have a long buffer (say 10 seconds) and set the length to around 1 second, it records and plays back 1 second (and I can make that repeat with the feedback parameter), but I have to wait a full 9 more seconds for it to record again. It's a little annoying that I can't make it go back to the beginning of the table and record again earlier (say, at the same time as set by the length parameter).
Thanks for your time!
edit: added a pic of current patch to test the Factotum
For the pots connected to gpio pins, my go-to has always been gpio/in/analog to midi/intern/cc (remember to use a logic/change out of the gpio object into the trigger inlet of the intern object), then do what you did with the dial object, right click, and set it to the CC of the intern object. I can provide an image if needed.
For the record inlet on Factotum, you have it set to overwrite which is good, so I believe that you would want an external button to hold it down and record for the length of time you want, then adjust the 'length' knob which is the second one down on the Factotum object. If you're trying to do something else let me know and I'll try to help you out.
In case this helps at all too, the inlets can be used to modulate the object both with dials and LFOs, but by using the right-click-midi-CC method I've described above on one of the factotum knobs directly (like length), it gives you direct control of the parameter. It's my understanding that when you use the inlets, you're adjusting the parameter based on where the knob is at on the object. So if the "length" knob on factotum is all the way up, plugging a dial into the "length" inlet gives you different results than using the length knob itself.
- it might be that the physical input sends a bit of an iregular value. You could try putting a k-rate filter over it, does this have any influence on it's behavior?
The inputs add to the knobs on the module, so if you want to use an external control, set the control on the module to zero. - the length of the buffer that is used for playback and recording in "overwrite" mode is set by the time that you have recorded the first time (when recording goes off, it saves it's current writing position as the length of the buffer). So if recording is always on, it never sets it's maximum length. You could try to add a 1-sample trigger to set record to off for a short moment, so it saves the length you want to use.
I think in your case, you would only want to record once to set the length of your buffer and then only use overwrite to make it act as a delay. The overwrite function is basically the same as record, except it won't change the record length and will just loop within the length first set by the recording.
Btw. this might probably also explain the eratic behavior as you've never set the length by stopping the recording. This causes the length to be basically set to 0. The length parameters are multiplied by this value so you can play a part of this recorded length. So these should be seen as a ratio instead of a fixed size.