SirSickSik Contributions

#1094

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
#1095

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!

#1096

Isn't this just beautiful? :stuck_out_tongue:
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! :smiley:

spectral control.jpg1856x1057 500 KB

#1097
#1098

Nice work! What is the plan?

#1099

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...

#1100

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.

#1101

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.

#1102

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.

#1103

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 :slight_smile:

#1104

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!

#1105

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 :joy:, but not for technical purposes

#1106

I have some questions about Factotum, if you don't mind.

  1. 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.

  2. 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

this one.jpg852x952 123 KB

#1107

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.

#1108
  1. 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.
  2. 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.
#1109

Thank you both for replies!

I think you're seeing the recording bit wrong, or maybe I'm the one not understanding how I made it work for me, haha.

How I've done it is that a trigger is sent when the patch loads up, and another pulse is sent by the pulselength object to stop/reset the recording. So I've used that to set the rec to around the length of the buffer (2.7ish seconds for now, because the pulse length object only allows for around 3 seconds). Basically, it holds a button for the length of the table and then stops. So it's only set once,and then using the overwrite I can use it like a delay, sort of.

It makes sense to me now that I need to somehow retrigger rec every time I move the "length" parameter to make it correspond to the desired "delay time". So have the one physical pot move the 'length' AND sends a pulse that's equally long to 'rec'... But how would I one that? :joy:

#1110

Now that you know a little better how some of the functions work, I would recommend hooking up a simple ctrl/button or ctrl/toggle to the record inlet to see the bare-bones functionality of that inlet, within the framework of what you're trying to do. Apologies if you're already familiar with it at this point, but adding all of the additional objects adds layers of abstraction which complicates the process and may lead down unnecessary rabbit holes of debugging the issue.

I'm not quite sure what your goal is, since the loadbang (to my understanding) only occurs when the patch initially starts up/goes live. It sounds like you would like to record multiple times, in which case you'd need to either automate the button with something like a square LFO or use a button/toggle.

Don't mean to assume what you're doing, only speaking from experience. When I first got the Axoloti, I set up entire patches that were completely broken when I went live because I didn't know to test the individual pieces of the process. Just hoping that it may save you some time.

#1111

I appreciate the tips and tricks!

I did start out with a button to see how it worked, but I wanted it to be automated as I want it in my axoloti pedal and don't want to have to step on it every time I want to record and play something back to me. That's why I tried the pulse length object and why I'm now turning to you folks for a solution that might actually work. :sweat_smile:

It records continuously as is though (with the patch load pulse (which starts the recording) and pulse length object (which stops the recording)). So, it work like a delay now. The only issue is the buffer length is set only once, so when I move the length (time knob on a delay), it doesn't make the recording buffer smaller, only the play window (if you will).

Currently, with a (for the sake of making it easier to explain) 5 sec buffer with length at 100% and feedback at 50% the Factotum plays back to me all of the 5 seconds, and just keeps recording and playing back to me (so I can layer sounds on top of each other and they fade out over time, like every delay pedal in existence) . But, if I put length at 50% it will play back 2,5 but only record new things to add to the feedback every 5 seconds still. At even shorter delay times it sounds really weird because it will repeat only a really small snippet for 5 seconds before picking up something new. I know it's because of how I'm hitting the 'rec' input, setting the total buffer time, but I don't know and can't figure out how to do the following:

I'm asking if there's a way for me to automate hitting 'rec' at intervals that correspond with the 'length' parameter. So, one dial (pot) that sets the buffer size ('rec') and window size ('length') at the same time, so they're 1 to 1.

You say square lfo might work, and I've thought about that, but how do I make sure the frequency of that corresponds with the length parameter, because it seems (at the current moment) that having the 'length' be even 1ms longer than what 'rec' is set to will leave me with a 1ms sample playing suuuuper fast for the duration of the buffer length. And if the 'rec' duration is shorter than the buffer, it will at some point drift so much that it will do like an asymmetrical dual head delay thing. I'm more okay with this (kind of cool actually) than the 1ms one, because that scares the **** out of me when it has happened. REEEEEEEEEE! :joy:

#1112

"I'm asking if there's a way for me to automate hitting 'rec' at intervals that correspond with the 'length' parameter. So, one dial (pot) that sets the buffer size ('rec') and window size ('length') at the same time, so they're 1 to 1."

As I've said, the "length" parameter isn't a fixed time that sets the buffer-size, but is dependent on your recording time. So if you want a smaller buffer-time, you need to record again at a different timing, as the length-knob won't be adjusting the time of the buffer, but will just set how big a part of the buffer will be used to play back. Setting the window length on a 1-1 ratio to record size, you just need to keep "length" to full size...
Also, you're using it as a delay, but the module wasn't intended to be a normal delay in the first place, but that length-knob just isn't the "delay-time" like a normal delay. Trying to use a module for something it is not will sometimes work, but other times it just won't.. especially if you take parameters to do something else then they're actually doing...

I cannot just change the module so it will behave differently, as this might ruin the patches of many other people.. Even if I change something small, it might mean I increase the memory needed for the module, causing some patches to stop working that were maxed out in terms of memory use.

To prevent those small delaysizes and the "REEEEE", you need to set the buffersize to a size that you know you won't go over or force the recording to stop before it goes over the buffersize.

So first thing you need to do is to design a way to record to the buffer at a specific timing while at the same time, making sure it cannot go over the entire buffer time.
You are using the pulse-timer (which btw can go over the knob's-time by offsetting it in semitones using the external input -> +12=twice as long), but what about using a counter that is triggered by a LFO for counting but needs a reset to start again at 0 (it's one of the factory counters). Then you use a "<c" math module to set the max count that would output a high gate as long as the counter is below the max-value. The LFO will now set the beat tempo and the counter the length of beats to be recorded. To set the record time to something different, you'ld reset the counter while adjusting either the max count or change the LFO tempo (depending on what needs to be adjusted: are you changing your measure (max count) or are you playing slower then the original base tempo (lfo tempo)?).

Perhaps a better thing would be, is to re-look at what your intended use was and try to explain that to me. Perhaps I think it's interesting enough to write a dedicated module with the prescribed workings..

  1. what is the situation? external audio/midi sources going into axoloti or is it only axoloti based? In the first one, you'ld need a way to sync the bufsize to the external midi-tempo, in the other you could re-use the tempo set by the internal lfo's (which would give you a more exact timing).
  2. what kind of effect were you going for and how were you hoping it to react when changing controls/what kind of controls&operations do you need?
#1113

I will try to make the lfo and counter work and keep length at max, like you suggested. I've never used a counter object before, but I'm sure I can search the forum to see how to put one together, so thanks for that insight!

  1. No external midi. Just ins and outs on the axo board (plus power input), and knobs, toggles and footswitches for control. It's already a delay pedal, I'm just looking to expand it to do granular time stretch stuff (which the factotum does excellently as a live sampler mangler!), which is why I'm trying to incorporate it

  2. Ideally, I'd need 4 params for knobs and one for a toggle. stretch, length, feedback and 'grain size' for the knobs and forward/reverse playback on the toggle. Bonus would be a freeze-like effect (holding either the whole "sample" or just a single grain with the footswitch), but not too important.