let's hit "sync library"..... "click"
"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:
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.
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)
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