SirSickSik Contributions

#1033

do you know something about how to handle this thread to make the fft buffer continuous?

#1034

I've added a bigger fft analyser to the disp folder that's able to show lower frequencies and has a bigger display than the factory one.
I wanted the amplitude to show in dB, though it seems the squared array math function isn't provided by the axoloti firmware. Perhaps I can find the code to do this somewhere else, but I'll try to find that later on.

#1035

where's the code from? id really need to see it in context with the rest of the code.

however, my assumption, from this code fragment, is that the sleep is to allow time another thread to populate the incoming buffer and also give other threads a bit more processing time. (you don't want a tight loop, needs to yield)

if this is the case, then what you would normally do is to use a thread signalling mechanism, as its detailed in the ChibiOS manual under synchronisation , however in audio work, you need to be very careful with this, since it can create issues with holding up the audio thread (which is why lockless queue are popular)

id probably try a conditional variable and see how it goes, it'd definitely be more responsive... but you'll have to see what it does to cpu load, and if it creates issues on the audio thread.
(note: Ive not messed with this specifically on ChibiOS, but lots on other OSs :wink: )

#1036

Seriously mate, I'm flattered that you posted such a snippet of code and expect me to understand it, but lol, no chance (not yet anyway).

The only thing I can figure out from that first snippet of code is that if a certain condition is true, do something, and only do so while another condition is also true :blush:

Can't tell you how frustrated I am right now, I can't even access my own axo to try the object you just made. Regardless, I'll get to play with it sooner or later, and I'm super-pleased to hear about your spectrum object cause it's something I've always felt was sorely missing from the axo development environment!

#1037

the code is from the fft analyzer object (spectral folder). the rfft being used has an entry to choose between fft and ifft (0/1), so I found out I could use this code to resynthesize sound being read by the analyzer.
Though, this morning I've figured out how I could put the calculating part into the normal local krate code instead of keeping it as a thread. Though this looks like to have fixed the update rate, which made the sleeptime disappear, I now still have problems with alligning the waveform generation without any AM happening as the hanning window still creates an amplitude modulation. Then again, taking the hanning window away causes an interupt in the waveform.

Anyways, if I use the most basic form of fft and then ifft, it only takes about 7% of cpu... even though the waveform is not perfect yet from the ifft, I was pretty stunned by the low usage while calculating quite big tables. When I added a for-loop to alter some indices of amplitudes, the board shot up to 60%. But this might probably brought down a lot by using a set of ARM array maths.

Using the inbuild array maths of the ARM saves a load of cpu on array calculations and seeing that they're not much used yet in modules, it might be a good thing to get into as developers to enable more interesting, low cpu forms of array usage in the axoloti (presets, morphs, wavetables, matrix modulations etc)

#1038

for fft you normally need an overlap, to smear out the effect of the hanning window.

#1039

yes, I'm gonna try that next. but I'm afraid that I'll also run into some phasing problems of certain frequencies when I do that. Anyways... there's finally a good start to work and improve on..

#1040

buuuhuuhuuh, at the time I got the fft resynthesis sort-a-working, the sound started to glitch :weary:

#1041

Yeah, but you're the SickSik, so can fix anything!

#1042

I'm also in contact with someone who has actually pulled it off. But her modules are coded for the computer (though also C++), but I'm afraid in the end the whole resynthesis thing cost a bit too much. All the time I've had these artifacts and I thought it was only because of the ringmodulation of the hanning window, but it seems there was also a short glitch in there of which I first thought was only a discontinuity between waves, fixable by a window, but no.
So getting the fft out of the thread doesn't seem to be an option and I have no experience with dealing with threads themselves.
In the end, what I was doing seemed to be the right way as it showed an almost perfect continuous triangle on the display. But the axoloti is just not up to it to pull it off live cpu wise.. :frowning:

#1043

Well thumbs-up to you regardless. It sounds as if you were really milking the hardware for as much as it can handle!

No doubt the refinements and frugality of the coding you just did for the current hardware will have a very positive effect when run on the new board urklang is working on. I'm guessing it'll fly on that board!

#1044

The new version of Axoloti, that @urklang is working on, should be able to pull it off :slight_smile:

#1045

these modules I've just written to enable me to control several axoloti's with lots of internal controls from just a single midiCC control mapping of the beatstep pro. As it's a project-under-construction, I won't yet, or maybe not at all, upload the modules to the library. So if you have a beatstep pro and want to be enlarge your control capabilities, just load this project and use it's modules. Note though, you'ld probably need a book with diagrams to remember which control is which... Still though, if used well, you'ld come a far way using only the randomise, load,save,copy,paste,mix features of the edit module! So, you could also skip the whole midi-control receive thing and have a blast randomising and mixing presets.

For this to work create a beatstep pro control mapping like:
-all controllers to channel 16 (encoders, buttons, pads)
-encoders: midiCC 1-16
-buttons: midiCC 17-32
-pads: midiCC 33-48

the upper left two encoders control:
-midiCC1=the device selection (up to 6 midi devices internal/usb/din/host and their own midichannel)
-midiCC2=the control layer (46 controls per layer. up to 128 layers. all layers are stored in a single table)
for each layer, all the other controllers (3-48) control their own position in the layer, but send their value to another layer and device depending on the selected layer using midiCC2 and selected device using midiCC1.

To enable this, 4 modules are used:
1- the main midi receive module that receives the midi from the beatstep pro and sends it's midi thru to the right device and control layer in that device. Only if you also select "internal" device for one of the devices, you need to add the modules below. Otherwise the other modules will go into the patches of the receiving devices.

2- the device table module receives this data and sends it to the right layer and position inside the table. This only needs to be added once to a patch in a device that receives data from the main receive module (above). As it's up to 128 layers of 46 controls, I don't think you'll ever need a second.. :wink:

3- the table-read modules are then used as "knobs". Each reads from it's own fixed position in a fixed layer. Updating the position in that layer with another value, updates the output value of the module. min/max values set the range of the "knob" output. These modules can be connected to your modules to control them eg. oscillator, filter, effect, etc.
You can also read out a part of a layer using a sequencer and table read modules.

4-as this internal table won't be saved together with the patch, it needed a preset load/save module. Next to this, due to the 7-bit nature of midi, this would only allow stepped values. So I added some more functions to alter the control table:
-copy/paste the device table into an internal "copy" table for adjusting/undo functions
-instant randomise device table
-mix device table with a randomised internal table (allows for small offsets of the stepped midi in the device table)
-save device table to SD-card to save presets
-load table from SD-card into an internal preset table and mix it with the device table (allows for morphs to the next preset, though this would some more external modules)

As all the midiCC's of the beatstep pro are already in use, this means these morphing/editing functions should be done from another midi controller or be controlled from the hardware inputs of the axoloti (unless you don't use the midiCC receiver module and just use the edit module to randomly create, load, save and mix presets)

midi split and send to layers.axp (46.6 KB)

#1046

oh, and ps.. the "knob" read-modules can also easily be editted to allow multiple outputs.
Just add more outputs like this-> sel+1..sel+2..sel+3

outlet_o1=___SMMUL(
attr_table.array[sel],diff)+min;
outlet_o2=___SMMUL(
attr_table.array[sel+1],diff)+min;
outlet_o3=___SMMUL(
attr_table.array[sel+2],diff)+min;
outlet_o4=___SMMUL(
attr_table.array[sel+3],diff)+min;

also, the sequencer modules could be editted to allow the sequencer to read through multiple layers to allow longer sequences. Just divide the count input by the width (which is an internal value of the sequencer module), multiply this with 46 (size of a layer) and add this as an offset of the array readout.

But take notice of how how many you add, both for adding outputs as well as the sequencer, as you might go into another layer or over the amount of values in the table if you're not careful (probably disconnecting your axoloti and force you to restart).

#1047

just one beatstep pro controlling a single axoloti :stuck_out_tongue:
only thing I'm doing is manually changing the key and change into the parallel or relative every once in a while (using 4 pads of the gate sequencer, so these can also be sequenced)

#1048

Absolutely loving the baseq module and the sequence database!

I'm using it with sample sounds of the LM-1 drum machine. So far I made 5 banks of samples at different tuning. It's possible to finetune the pitch with the table load pitch object if needed.
Here are the samples and a patch with a setup that works for me. I have the impression that for most sequences it's better to switch around open and closed hihats.

And a question: how to edit or create a new .tab-file? I'd like to add some sequences of my own to it. I tried a text editor (on linux), but no luck there.

Thanks!

#1049

just hook up a mic, put some foam over the mic and tick it, or make some shh, krggt,splsh or whatever sounds with your mouth.
ideas for editing functions are welcome
secret patch (10.7 KB)

#1050

go to sss/test and use 8x the baseditor and one basaveload

the sequence table is build like this:

96x a value between 0-127 for each step in the sequence for a single part
8x parts (as each sequence contains 8 channels of 96 steps)
so each sequence exists of 8 rows, each of 96 steps=768steps in total per sequence

ps. due to the way I've recorded the midi, I found out there are some mistakes here and there in the recorded sequences. it's a good idea to make your own set of drumsequences using the editor

#1051

baseq editor demo.axp (97.3 KB)

#1052

NEW MODULES

LOGIC
"multi2" and "multi3"
logic modules with multiple externally selectable logic functions
2-input has 8 different functions
3-input has 64 different functions (see code for which ones)
5 different "update" modes for when the logic function is changed or when the external trg input goes high (S&H the outcome and output the updated outcome at next sample for generative logic feedback networks)

LOGIC/DAC
"dac2" and "dac3"
turns 2 and 3 bit inputs into selector values, usable to control the logic mode/update modes with other logic modules.