I'm lazy....
NEW MODULES
which?
Just go to "MyDocuments"/axoloti//contrib/objects/sss and sort on date 
-several updated modules (found some mistakes)
-couple of new oscillators (tabletrain=awesome XD ) and filters (3x parallel bandpass biquad)
-lots of sequencing/morphing/tools stuff
He mr SirSickSik Sir just wanted to say thx for all the useful modules. Clock2timing has fixed slot in all of my patches!
I was just wondering I think you asked about making 2b table once here in the forum. Did you manage to do something like that?
I want to store simple on/off stuff in tables, so even 8b tables waste my resources
instead of int\s you can also make use of bools, off or on..
instead of
"int32_t array"
try
"bool array"
( not definitaly sure ,I'm drunk at the moment, but it's something like this.... big smile, everything is going alright here... jus t waiting to get sober again..)
just woke up...
oh shit... I'm still drunk... gotta get sober for work quickly, what to do? let's start up the axoloti! hahahaha
btw, you can also just save your bool-sequence as a 8/16/32-bit value, allowing you to store 8/16/32 bools into each position of the array. Reading these out will be done like:
(8-bit)
gate=(array[count>>3]>>(count&7))&1,
(16-bit)
gate=(array[count>>4]>>(count&15))&1,
(32-bit)
gate=(array[count>>5]>>(count&31))&1,
NEW MODULES
PATT
"WCG12" and "WCG16"
"WCR12" and "WCR16"
"WCM12" and "WCM16"
WCG12/16 are second order weighted chance "note"-generators.(don't need to be notes, the WCG16 could very well be used for rhythmic sequences or velocity)
They will calculate the chance that particular notes/velocities/durations/octaves might follow up on two previous notes/velocities/durations/octaves.
Both modules have external inputs for overriding the "oldest" or last previous note, so multiple modules can be combined to cross-modulate each other's calculations.
As WCG12 is "normally" used to record note-chances, the note-input is wrapped between 0 and 11.
As WCG16 is "normally" used to record velocity-chances, the vel-input is clipped between 0 and 15.
WCR12/16 is used to record the chance-table using a keyboard. Connect a midi-to-cv module to the gate and note/vel inputs and play a (long) melody with your keyboard. Each time a note is played, it uses the two previous played notes to determine the position in the table and add a weight of 1 to the note that is played after this two-note-sequence.
When done, hit "send" to send the recorded chance-table to the "core" module (WCG12/16)
To reset the recorded table and start anew, hit "reset".
To alter a previous recording, hit "get". This will load the table of the core-module as if it is just recorded, so you'll be able to alter it if needed.
WCM12/16 are modules to manually change the chance-settings. The first two selectors select the two previous notes/velocities and the following small selectors set the chance of each note/velocity to follow up on this two-note/vel-sequence.
It's very useful to have this one next to the WCR12/16, as you might need to alter the chance-table manually sometimes.
For example, it might stick to minimum/maximum value. You can fix this by selecting 0 or 11/15 for the note/vel selectors and alter the chances manually to get it away from a repeating 0 or 11/15. (11 or 15, depending on whether you're using WCM12 or WCM16)
Demo patch. Also shows use of tabletrain osc, guitar synth, "morph"-tools and shimmer delay.
(though, you might need to create a 127-waveforms wavetable first)
chance pattern2.2.axp (43.3 KB)
and for people in need of making a sweet wavetable first, this patch has 3 different modules for auto-generating waveforms and a table-combinor to combine your created waveforms in a single table. Please follow instructions in the patch.
table combinor.axp (30.4 KB)
I've been a bit tad lazy about updating my list of modules here, but there are some new ones.
one of the new possibilities of the new firmware is to include multiple wave-displays in a single module (caused a crash before).
So I gladly used this new possibility to finally have my "BIGscope" module made!
It features 8 scopes in a row, so you can see longer waveforms (no need to use the stackable anymore) eg. when running on a low frequency, you couldn't see the whole waveform when using a single display.
SOME NEW MODULES ghehehe
well, at least one of these is the "sinelord" in the "sss/dist" folder.
I kind of ran into a mistake of my own thought, about applying a sine-shaped wavefolding...
I tried too hard such that I overlooked the fact that at a 45degrees a sine is ALWAYS a 1/1 ratio as long as that you've got your scaling right.
So... after FINALLY seeing that penny, laying there for ages (I seriously think too much to see simple things), I got the:
DIST
"sinelord"
-first of all a gain-stage, where you can add gain to your signal before it enters the shaper,
-low/high clip: points for positive or negative values turn from linear to sine-behavior->non-linear behavior when low/high clipping are not the same.
-strength: the strength/rate at which this turning occurs-> the higher the strength->the more overtones/octaving,
Funny thing about this calculation is that it states a hard clipping point and every value above this will be shaped into a sine of which the first values will have the same slope as the last values before it clips, thus automatically applying a "soft" curving of the signal.
Hey @SirSickSik 
I was playing around with the divremcF object. And I noticed that if you feed the input with a counting integer signal 0,1,2,3,4..... then, when the counter reaches 1024 on the input of the divremcF object, the divremcF stops sending anything from any of the outputs. BUT when the counter gets to 2048 it starts sending out again until it reaches 3072 it stops again.... and starts at 4096.. so bascially it starts and stops everytime the input reaches a multiplication of 1024.
A work a round for this is setting another DivremC object BEFORE the divremcF to prevent the input of the DivremcF of reaching 1014. But that is just a work around not really the best solution for this.
And I just wanted to ask if this is intentional?. Or there might be a way of removing the 1024 wrapping thingy, so I dont have to add another DivremC before the DivRemcF?
Thanks, Jaffa
The divremcF works the same way as the divremc module, only problem is... if your slider is at "48", it's not just at 48, but at 48*2^21, while the range is only 32 bit and the signal is bipolar. So as soon as you hit/go over the 32 bit range, the value will loose a "bit" as it can't store it.
So if you need to wrap a fractional (blue line) signal, you might first want to subtract the integer of the signal (converters folder) to get the small value aside, and send the integer value through the divremc to wrap it to some range and add it back to the small value (ok, this explanation sucks,..)
eg. wrapping between 0 and 10:
start value: 165.53
integer: 165.--------
subtract from start: 165.53-165=0.53
wrap between 0 and 10: modulus(165,10)=5
add to wrap: 5+0.53=5.53
Sorry, I dont understand that. I have not tested if the regular divremc does this too. But I will, since you say that it does it too, just to be sure
EDIT:
I was looking in the converters folders, in your as well as in factory library. In your folder I found 2 objects, see picture. In factory there is a bunch. Which one would I need? I tried to use conv/to f.... with no luck.. ALso tried sss/conv/pitch2khz with no luck....
Any tips would be appreciated
problem is, you're sending the integer output to a fractional input.
you should be using the normal divremc with the integer input.
if you send an integer output to a fractional input and send for example "1". The fractional input won't read this as a "1" but as a "1 * 2^21", thus 2097152. Well, as it can only hold 32 bits, you'll run out of space pretty soon, which is actually the 1024 that you mentioned earlier. As in, a bipolar range from -1024*2^21 to 1024*2^21 will take 32bits (when calculating unipolar ints the range would be 0 to 2048* 2^21.) Going over this 32bit range will just make it restart from 0 as it has no bits left to store the higher values, just in the same way the divremc module wraps the value between zero and denominator.
The fact that it sometimes produces unexpected offsets is when the denominator isn't in ratio to the power of 2. eg. when the input goes over 32bit, it will restart from 0 and thus also resetting the value going into the modulus operator calculation even if the rem-output shouldn't yet go back to 0 in respect to the denominator.
so long story short,
-use the normal divremc module (I also have a version with external integer control)
-remember that after 32-bits, the calculation always wraps back to 0 as it can't hold values higher then 32bit.
I thought might be the issue. Now I know. Thanks
In the particular case I am working on, it wont work well with the regular divremc object, cause I kind of need fractionals. It is for a custom build lfo that can be synced to clock. I tried many of the lfo in the com.lib. and none of them really syncs as hard as I was hoping. Thiw technique works for what I am tryin to accomplice. So I guess I have to live with having to add another divremc before the divremcf.
Thanks
NEW MODULE
my best filter yet I think, the "mostfilter3"
low on code lines, low on cpu use, but a very nice resonance response.
it's basically two modded "normal" 6dB filters that can be morphed from LP to HP to create a 12dB LP->6dB BP->12dBHP response, but the signal used to change the filtered signal itself is filtered at the same rate.
So, like the other "mostfilters", it's like a filter inside a filter, but with another, personally valued better, response,
Pairs really well with the "softcomp" distortion module (sss/dist/softcomp) to drive the filter's output.
and I just added a "spread" control to spread the cutoffs of the two filters
I look forward to test it. I really like the HQ LP filter yu have made too. THat one is REALLY nice
Sorry I've not been too active here lately, though that doesn't mean I'm not bringing out stuff. I'm just not really in the communication-thing in the middle of the winter, if you know what I mean.
Though that said, I'll be trying to dive a bit less into the coding of new modules and focus more on actually using them as I've been mostly uploading demo's of vst's and axoloti objects for the last couple of years haha
Still, if people need modifications on existing modules (fixing bugs/adding inputs/controls), let me know. I lately have bug-fixed a couple of old modules that didn't seem to work at all, so if you run into such a module, please let me know.
Currently I'm playing around with two boards. One playing a polyphonic midi-sequencer, 4 five-voice synths (guitarsynth) and a delay, the other doing a drumsequence (weightedseq) with simple edrums, and tabletrainOS as bass and it's sounding awesome! 
working on a new polyphonic midi recorder as the one I was working on was a bit problematic and I started out the wrong way saving the data (making it impossible to change the size of the array without losing data, even if the amount of data would fit in the smaller array).
Also, the new way should make it possible to save ANY normal midi-data polyphonically (exept sysex) at any rate and any "count-length" 
Hopefully I get it working at the end of the afternoon
Sounds very cool, SirSickSik!
I was about to ask if there was an object to record and play-back unquantized MIDI, but it sounds as if you're already onto it!
NEW MODULE
OSC
"blepped"
for anti-alliased oscillator enthousiasts, I've created a single oscillator for all the blep-function waveforms (factory oscillators) together with the tables that are made with the "waveformGenerator" module (the last couple of modules in my sss/osc/ list)
still working on it, but should be able to be used already
...
..
AND it's finished....
oscillator can now also be used polyphonically where the poly-index is able to select between different waveforms.
ps, the way I'm building it should allow easy editing of the codes, using the different waveforms by just adressing to the right waveform name:
sync=param_sync;
int32_t preset=param_wave>=5?param_wave-5:0;
preset=(preset-preset/attr_table.Waveforms*attr_table.Waveforms)<<attr_table.LENGTHPOW;
int wave=param_wave>5?5:param_wave;
for(i=0;i<BUFSIZE;i++){
in[i]=inlet_mod[i];
}
if(wave==0){SIN(inlet_pitch+param_pitch,param_mod,param_self);}
if(wave==1){TRI(inlet_pitch+param_pitch,param_mod,param_self);}
if(wave==2){SAW(inlet_pitch+param_pitch,param_mod,param_self,1);}
if(wave==3){SAW(inlet_pitch+param_pitch,param_mod,param_self,-1);}
if(wave==4){SQR(inlet_pitch+param_pitch,param_mod,param_self);}
if(wave==5){TAB(inlet_pitch+param_pitch,param_mod,param_self,preset);}
for(i=0;i<BUFSIZE;i++){
outlet_wave[i]=out[i];
just woke up and realised I could also build in a karplus-strong synthesis inside the oscillator, using the internal table, which is already included. anyway It just happens to be I just created a karplus strong that needed the same amount of controls
ehh, holy shit, it even asks less cpu then the blepped-oscillator modes, sweet!
