Rbrt Contributions

[rbrt]

step seq BLOCKS

here are some modules for building step-seq's.
my main focus was to simplify visual feedback for controllers that feature bi-directional MIDI,
like the LIVID BASE or the NOVATION LAUNCHPAD.the help-patch should work with the
factory-mapping of the BASE.
I had a hard time recently to acieve this with 'regular patching',so I did an object for this,'seq midi feedback'
would be good to know if it works with the launchpad...

besides,there are some other custom objects that I feel make sense for step-sequencing.
-step toggle : will toggle an element at an index (or step).if the step == 0,it will be set to a defined value,if its non-zero,it will be set to 0.
-step set : will set a step to a value.optional,the step will ONLY be set to the value if it's already non-zero (useful to change velocities without creating new steps)
-read step : reads at an index and outputs the value.
outlet 'trig' puts out a pulse if the value is non-zero,outlet 'vhold' will hold the current value until the next pulse.

[rbrt]

...about these,I have to do some self-congratulation:

-disp bool : displays the boolean state of 16 elements of a table,starting at 'offset'
-disp float : displays the value of 16 elements of a table,starting at 'offset'.
(self-congratulation!!)
unfortunaltely,unipolar only since there's no bipolar slider-display.
-tset bool : sets 16 elements to either 0 or max
-test float : sets 16 elements to value.here,bidirectional.

-tclear : sets n elements inside a table to a value,probably most useful to clear the contents of a table.
'tclear' works at audio-rate.I did some testing on this,anway,there may be problems with very long tables.
(again,self-congratulation!)

[akirasrebirth]

Hello @rbrt

a question ... it's possible to use the loop_mangle to loop a part of a table without first record the table? I have an alloc/table object with an array containing 60 values. I have set the object to a size of 64 but I want to play in loop only the first 60 samples. How can I do that?

[rbrt]

hi there,
..shouldn't be a problem..
I'd recommend using 'loopv2/lmangle' first of all because it's simply BETTER...

basically,you can use 'offset' and 'range' to select the playback-area of
'lmangle',realative to the corresponding table's size.
if you attach a unipolar dial (ranging from 0 to +64) , to the 'range' - inlet,
and set it to 64, 'lmangle' will play back the entire table...

so,if your table is 64 samples in size but you only want to play back the first 60
samples,you should most probably set it to '60'...
if you want to 'shift' the playback-area while keeping the length of that area,
attach a dial to the inlet 'offset' for FUN effects...
let me know if this works/makes sense

cheers,rbrt

[akirasrebirth]

Thank you @rbrt !

I retried and now it's working fine. I had to attach a phasor to the loopstart. Nice object!
cheers

[rbrt]

patching

here's some stuff that attempts to simplify patching,with a dash of PD / MaxMsp..check the help-patch..

-loadbang: when a patch is going 'live' , loadbang puts out a pulse to get things going.
-automux: connects several inlets into 1 outlet.when the value at an inlet changes,that value is put out.
-k2i: converts 'blue fractional' into 'green integer'
-i2k: the opposite
-bang : the PD / MaxMsp bang-button
-t2p : puts ot a pulse at the 'rising edge' of the input.
-pass i: simply passes input to output.this may help when you want to remove or add parts of a patch without ending up with a lot of broken connections.

[rbrt]

bitwise display

fun new object for newbies to the world of BITS...and maybe helpful for anyone who gets lost between 1 and 0 sometimes
displays the first 16 bits of an integer in an appealing way

[Sputnki]

You could make the display object stackable by adding a chain output, with the input bitshifted right (or left, whatever is your implementation) by 16 bits. More useful, imo

[rbrt]

sounds like a good idea!

[rbrt]

launchpad blocks

here's some blocks for the 'novation launchpad' , providing colorful effects and matrix-madness o'plenty..
tested with a LP mini , they will NOT work with a LP mark I (this one is not class-compliant...)
would be interesting to know if they are working with the LP pro..
check out the help file, reggae - edition...

[M.Chocolat]

Hi there, i'm new to axoloti and i really enjoy your midi feedback and seq objects. It work fine with my quneo midi controller. Maybe it can be done with patching objects, but it would be great if you could create a steptoggle object with more inlet value in order to control note, velocity, length note for each steps like the Elektron parameter locks.
Great work by the way. (Sorry for my bad english).
Alain

[rbrt]

hi Alain,
thanks for liking my stuff!
..for example 'tablestore 4' (rbrt/data/tablestore 4 in the community library)
works for controlling 4 parameters of a particular step of a sequence..
and it will only change the step's data if the parameter actually changes which I thought makes sense..

but all the objects in rbrt/data are just done to store data more or less stupidly to a 'table',
I'm working on some objects that make more sense to me in a step-sequencer-context..
..yet it may take some time before I 'properly' release them..
to 'properly release' means that there already are some new objects for example in rbrt/seq ,
but before I don't write a post about them,they may eventually change

[rbrt]

...more blocks for the 'launchpad'

here's some more blocks for the 'novation launchpad MKII/mini',check out 'help' for what they do.
also,here's a link for a sequencer-patch using the objecst:
multicolor 4-part seq.axp (21.8 KB)
you can also find the patch in the library at axoloti-contrib\objects\rbrt\launchpad

attention: this update may break existing patches,sorry for that!

[rbrt]

re-structuring my objects

I had to do some re-structuring of my stuff,because it was getting to messy..

edit:
seems like it does work to change the object's location in the library structure.
so,I created a folder named 'old' for objects I consider crap or out of data.
your patches should still be working...I did a backup of my folder before syncing,
so I can undo.

[valmir]

THANKS @rbrt! I just finished a live looping patch that makes use of so many of your objects... they work great! I have a question regarding the lrec object: if the recording exceed the length of the table it will output a range bigger than 64. I don't know if that's a bug or is intended, but to me is somehow useful... the loop will stay in sync even if i made it too long, just with a silenced part... but, there is a but: if the number grows too much it will crash the patch. Is there a way to limit this? I can saturate the range but I will lose the "even too long loops stay in sync" feature.

[rbrt]

hi there!thanks for the positive feedback!
but ...whoops...sounds like a serious BUG...I'll check it out..
actually,I dont't remember if 'lrec' has any protection implemented regarding 'running out of range'..
for sure,I'll have to implement something to avoid exceeding the dreaded 32-bit-number...

[toneburst]

Don't 32-bit ints just wrap around?

a|x

[rbrt]

...yep, but SIGNED ints will wraparound to negative numbers...
aaand writing to a buffer at a negative index will CRASH axo
(see the attached patch)
this seems to be what's wrong with 'lrec'..

crashtest.axp (2.2 KB)

(this will crash and disconnect axo)

[valmir]

Thanks for taking the the time to look into it... I'm thinking about limiting to the 'legal' range in my patch with an external counter that stops the recording before reaching the hell's gates, ehm, the wrap to negative, but I'm struggling to understand where this occurs(NOOBNESS...). 1<<27 is 1, so the length of the table, right?
Does it wrap to negatives at 1<<31? That if I'm not mistaking badly ( which is pretty common) is 16x the table length, but by experiment it seems to crash much earlier...help...

[valmir]

After some more testing I realized another problem. In some conditions lrec, after finishing a table starts to write to another one.
lrecbug.axp (4.8 KB)
In the attached patch you can check it out: the lrec referencing to alloc_2 will start writing to alloc_1 when alloc_2 is over, while the lrec referencing to alloc_1 will not write on alloc_2...