SirSickSik Contributions


#830

hmm ok... didn't know what inlining meant, but just looked it up. If so, this might indeed mean it wouldn't save size..but..
if you use object oriented coding, this SHOULD save space..
eg:
if you have 4 codes for waveforms and make functions of these and use 4 slave modules:
-if you use a "core" module, it defines these functions once, after which they can be used by other modules (which will indeed copy the code inline). for 4 slave modules, this would end up being the 4 functions in the "core" module and 4 "selected" functions inline in the code being used in the 4 slave modules, thus a total of 8 functions.
-if you add the functions to the "slave" modules themselves, each will have the 4 functions AND the selected function inline in the code being used, making a total of 20 functions.

So it seems to me it should really matter...


#831

Thanks for the heads-up on what the compressor is doing, I totally understood that, makes sense now!

Gotta ask about an inlet for that knob though, not to be ungrateful or pushy or anything, I'm just asking because I know how to add the inlet myself (Sputnki showed me how to do that), but the thing is, If I do it then it would only be on my compressor, no one else would be able to get it from the library.

Please let me know if you plan to add it some time, cause if not I can add it to my own no problem. It's just that there would be no point me adding it if you were going to do it. Either way, sooner or later, this beauty is definitely going into a rackmount with an Axo dedicated to it - totally love the thing!


#832

I'm afraid it won't be that simple to add the inlet the "normal way" by just adding it. The knob used is the frac32.u.map.kdecaytime.reverse, which has an inversed logaritmic scaling..
Though this can be fixed by using a normal "pitch" S-map control and using:

int32_t smooth;
MTOF(param_smooth+inlet_smooth,smooth)

and then use "smooth" instead of param_smooth in the current smoothing function.
Thing is.. I wanted to use this knob as higher values give longer timing AND the time-values actually correspond to the actual timing..

also, you can still automate this knob by using a modulation source or midi.. (though I wonder if the modulation source takes into account that the knob is logaritmic..I never use the modulation sources..)


#833

Thanks for the heads-up, Remco.

That's a real bummer (for me anyway), but at least it can be done through modulation sources and MIDI, so it can still be done, and that's what matters. If it turns out looking ok, I'll post a pic once I get around to building it into a physical rackmount unit :yum:


#834

128-output "preset" morphing module, based on the nord modular G2 is under construction.
It features several internal arrays to combine, mutate and randomise (between) presets and save newly created presets to a new slot.
This version outputs only bipolar signals, so there will be some conversion modules needed to scale these outputs and convert them to the right output and perhaps modulation source to be able to connect them to knobs/sliders.
Still a test-version, as I wonder whether 128 outputs might be a bit of an overkill and whether they can even ever be all used without going over max memory/cpu.. XD
But with three simple oscillators cross-modulating each other, this already does some funky weird ass shit!


#835

Hi, @SirSickSik
Maybe you can pack 16 krate outputs into a single srate output. Even if it needs unpacking it can be handy.
I use this shamelessly in some personal patches..
See the objects community/tiar/conv/pack_k_to_s and unpack_s_to_k


#836

NEW MODULE

DISP

"menuLOG"
this module can be used to send selected names of menu-parameters over to the log window.
There are 3 attributes to set it up:
"paramName" sets the parameter name------------------->!!!! include the " " !!!!
"selections" sets the amount of menu entries
"names" sets the seperate names for the entries------>!!!! include " " and { } !!!!

example:
for paramName:
"waveformA OSC1="
for selections:
5
for names:
{"sine","tri","saw","ramp","sqr"}

when the selection changes, eg. 3, it sends over the new selected entry to the log window like:

waveformA OSC1=
ramp


#837

Hey @SirSickSik

Was just checking some of your objects out. I discovered that in sss/filter/bppSVF object, the cutoff inlet is not connected to anything, codewise, so it doesnt work. I fixed in my local version, but I thought I'd let you know.


#838

thanks for letting me know! Fixed and synced


#839

NEW MODULE

DELAY

"massVerb"
a combination of a FND-network of 4 delaylines and 12 frequency-modded allpass filters. Delaylines are saved in SDram to allow very big spaces.

Room-shape is created by internal parameters which can be randomised and then loaded/saved using the factory table save/load modules (or manually by updating the array using object references):

-size (rndT) of the 4 delaylines (array[0] up to array[3])
-allpass center positions (rndAP) (array [4] up to array[15])
-allpass modulation rate (rndMR) (array[16] up to array[27])

Has extra controls for:
-reverb input gain (pre)
-overall size and decay
-"duck" for ducking the decay length when output signal becomes "too hot" and prevent overloading the buffer.
-"mod" and "modwidth" control the base modulation rate and the width of the allpass frequency modulation
-"rndRate" sets the amount of the random rate offsets to offset from the base modulation rate.
-4 pan-controls for panning the 4 input signals (positioning within the room)
-dry amount for adding the original, panned signal to the output


#840

NEW MODULE

PATT

"autoDraw2"
CV-automation module
actually just an update that adds 7 more windows, so you can see a far longer pattern.
One window was just a bit too small to make a nice automation..
Also fixed some minor bugs for moving the readout of the table and repositioning the start after adding a new part.


#841

Hi SirSickSik, best wishes for this new year

I havn't tried your last creations, but I'll be playing around with them as soon as this message is written.
I just tried to use your object : shufflingGateSequencer (that I really liked using before) and for some strange reason, If I save the table and then load it up again (Pload) I only get half of each bar (from step 7 to 14) the others are gone (at this on all 4 bars). Otherwise it works as usual. Do you know what has happened ?

Thanks


#842

Sorry to mingle in, but could it be because of your are using wrong table for storing the presets? I am not 100% sure, but you should probably be using a 32 bit table, if you are not all ready using it.


#843

Ahhh, Silly me :frowning:
Thanks a lot @jaffasplaffa it was exactly that ! Seems obvious now. Need a new brain I think !
Thanks again, and back to beat making :slight_smile:


#844

No problem.

I did the same thing many times :slight_smile:


#845

Finger-Tonnetz.axp (35.4 KB)

Here is a patch I've put some time into developing, it is using a very old Novation Launchpad to trigger notes and generate logic for chord transformations. Why? Because I got one free. Alternately I have used TidalMIDI to generate sequences that are time-based.

Yes, there are probably more efficient ways to arrange some of the elements of the patch, however my delight is not in being efficient but rather arriving at a melodious and functional result as rapidly as possible.

Thanks for making this object, @SirSickSik it's fucking awesome.


#846

Just wanted to say thanks for you inventive work! :+1:
I've made a bunch of Glitch Beast / Factotum combinations using a single QuNeo setup that works really well for standalone jams and processing.


#847

let's hit "sync library"..... "click" :slight_smile:

NEW MODULES

SAMPLER

"loadtrain1", "loadtrain2", "sampleplayer1", "sampleplayer2"

first of all:
-please read.. they're complex enough. Also, first check the info of inputs/outputs/parameters/attributes on the module if you're not sure what to do. Most should be explained.
-loading modules can be used together in a, what I call, a "loading train", by connecting them in a row (connect out&inputs between modules).
-able to load .tab, .raw, . wav files, though only 1 format per module, but each module may load it's own format.
-2 tables are needed to save the samples themselves (16bit) as well as the array-starting/end-point for each sample (32bit).
-you can use either a single table to save all your samples to or use seperate tables for each sample-instrument. (remember, it's 2 tables per set! So using two sets requires 2 sample-tables and 2 start-tables!).
-The size of these tables is up to yourself. I mostly use 2091752bits (about 43 seconds) for 64 drum samples, some of which may be fairly long (up to 3 sec, but most are way smaller). If the selected samples don't fit in the buffer, it just stops loading new samples (a bug should be fixed, but not entirely sure, let me know if this might still cause errors!).
As each module has readouts for array-start/end, (last loaded) samplesize and sample positions, you can check whether the load was within the bounds.
The "first" sample-index and amount of samples being loaded by the module are also send as outputs of the module. These can be used to bound the sampleplayers to the right sample-start indexes (eg. only the part with the snares).
These values could also be saved into an extra table, that's saved together with the samples and samplestarts. This way you can save and load sampletables that use different setups and order of samples!

well, the modules themselves:
-loadtrain1:
loads up to 16 files from your SDcard. Names can be entered manually. This is used to load a predefined set of samples that are not necessarilly in consecutive order, have different file naming/suffix or belong to different folders. Names are set at startup and cannot be changed while being live. Mostly used for "fixed" samples of which you are sure you're always wanting to use them.

-loadtrain2:
loads an indexed-named set of samples from your SDcard set with a prefix and suffix, like BD003.raw. Samples can either be loaded in consecutive order (BD001,BD002,BD003,etc) with a sample-index-start and sample-index-end control OR
be loaded using a randomisation process. The latter is controlled by two controls for setting maximum and minimum sample index and the amount of samples that should be randomly loaded.

Both loadtrain modules can be used in any order, for example:
- two kick samples, loaded by name (loadtrain1),
- 6 random kick samples (loadtrain2 in random mode),
- 2 'fixed/preset' snares (loadtrain2 in consecutive order and using index-input to offset the name-index to select next 2 snare samples with each new sample-library-build)
- 5 modules to randomly load a bunch of snares/hihats/cymbals/glitch/instrument samples from different folders for the remaining samples.
Each time the "load" is triggered, it will load the same two kicks, the snares that are selected and a bunch of random other samples.

As for the sampleplayers:

-sampleplayer1 is a "complex" one. Two samples can be played together with an internal decay-envelope mixing from one to the other (direction can be both swapped and tilted and rate can be externally controlled). Sample 1 only plays once, but sample 2 can be looped using the loopstart and end points. Play can be pitchshifted and reversed and looping can also be set to alternating.
The module has "first" sample and "samples" range inputs to keep it only playing samples within the desired reach of the sample bank (eg. only the part where the snares are loaded).(If multiple loading-modules are creating a combined set (eg. all snares), the "samples" outputs of the loading-modules should be added together and the "first" output of the first loading-module should be used as the "first" input of the sampleplayer.)
An extra feature is the Swalk (sample-walk) that selects a different sample each time the sample loops. The number send to this input sets the stepsize to use for stepping through the sampleset (only the samples within "first" and "first+samples" index)

-loadtrain2:
this is a simple sampleplayer that's able to independently play 4 samples from the samplebank. Each sample has it's own pitch control, sample selection and gate-trigger. Only has one audio-output. Useful for quickly adding a bit more polyphony next to the heavier sampleplayer1 (of which I use only 3 in a patch).

and a little demo: https://soundcloud.com/sirsicksik/broken-axoloti-sampling


Module requests
#848

NEW MODULES

LOGIC

"rndLGC"
4 inputs, 16-multi-logic stages and 4 outputs that can select any of them and a randomisation trigger and chance.
Turn any 4 gate-patterns into something completely different. (eg. the track of the audio-link in the former message is made by 4 unchanged gate-patterns that are mangled by 2 slowely randomised rndLGC modules.)

SAMPLER

"liveRecord" and "livePlayer"
These modules are set up in the same way as the sampler (using a table for the samples and a table for the start-positions), but are used to live-record and play samples. Could very well be used a live granular sampler in conjunction with the samplers to further mangle up samples. Ehm, actual sharing of the tables between the samplers and the live-sampling hasn't been tried and might not work... So you probably need to use an extra set of table-allocators for this duo.


Rbrt Contributions
#849

could anyone tell me whether the new modules are present or there are any errors, as my axoloti patcher suddenly can't find my library anyore and I'm trying to figure out what the heck has happened..