When I use the launchpad mini I convert the weird note numbers into 0.1.2.3.4.5.6.etc. anyway. I do that by using one of rbrts objects called rbrt/launchpad/launchpad in. It reorganises the pads into 0.1.2.3.4.5.6.etc., instead of the weird way they are originally organised. Much easier to work with.
@chaocrator I think since the Pro's pad are all ready pretty well organised, its should be fairly easy to get the Pro working properly.
Heya! Can you help me with the loadbang object? I'm not sure how to use it...I Have a diy midi controller hooked up to my 5pin midi input and when I start up my axoloti it doesn't realize the midi controller is there until i fiddle with each of the controller's knobs...someone mentioned that your loadbang object might be able to help me resolve this issue but Im not sure what to do with it when I add it to my patch...
hi @Androoclops, ...midi initalization can be pretty esoteric, 'loadbang' might help,maybe in combination with my 'pulse delay' or 'kdelay' - objects...
I put the loadbang object into my patch. Although it didn't resolve the issue with the midi controller, it seems to have fixed a different problem with the switches I have connected directly to my axoloti which is hilariously awesome! I'll try the other things this week (maybe today) and see if they work. It's a diy Arduino midi controller but I'm having no lucky finding Arduino code to force it to send it's values automatically on startup up
in arduino code there is a setup routine, it is used exactly for this purpose: running code once on power up. so you just have to put all your midi sending commands along with the corresponding analog or digital readings into the setup function (i would suggest you put it at the end of it)
Thank you for your contributions. I have an axoloti project that utilizes your looper blocks. Everything is working great. Have you considered implementing some sort of undo/redo function? The only thing I can think of at the moment is bouncing between two .wav files when overdubbing into the table.
(Sorry Robert don't want to clutter up your thread, but)
SSS has a loop module: sss/delay/loop4 that allows for the recording of loops and also the ability to bounce down into one of it's four slots, perhaps you could use that alongside RBRT's existing looper blocks in your patch
dadada- da - da,dadada - da - da, da da da daaaa...
it's quite a lot of objects,all in rbrt/push, and I have not referenced the help-patchers in all the objects... so here they are: push led.axh (11.9 KB) this patch demonstrates how to access the Push's LED-display
push buttons.axh (23.1 KB) ..while this one is about getting the buttons, and setting the matrix to the most psychedelic colors
PLEASE NOTE : this is all for Push I ,Push II is NOT supported (and afaik won't work with Axo).
the code is based on hacking the great work of @thetechnobear
..there are good resources here as well
regarding the led-feedback for the matrix and the display, the matrix is driven by objects referencing tables for led-feedback, and the LED is driven by an object called 'led master' that other objects like 'led row text' are referencing to.
there were quite some issues, most of all, there seems to be some kind of 'crosstalk' that would lead to stuck incoming notes when sending a lot of data to the Push (this happens when sending data to the LED and the Pads as well). this could also be an Axoloti-Firmware-Issue, I didn't find these issues described elsewhere.
I've recently played some gigs with this setup and it was driving me NUTS, finally I implemented a data-thinning-mechanism. That fixed the stuck-notes-issues, even though the LED-display is reacting somewhat sluggish.
check out rbrt/poly/polymaster latch and open the helpfile.. I've been quite unhappy with axo's standard polyphonic voice allocation sceme,so I decided to hijack the polyphonic subpatcher for my own purposes.
what I came up with is a voice allocation sceme with the following specifications:
a note that gets played again will NOT start a new voice, if that note is still in release-state, but it will be re-triggered.for me, this behaviour makes most sense.
notes that are on release can optionally be 'stolen', the notes that are on release the longest get stolen first.
you can set individual notes to loop- or latch - mode,so a note-on will toggle the notes on an off. which is GREAT for creating simple patches with lots of looper-instances. with the standard voice allocation sceme,it wasn't really possible to latch notes.
this also makes it easier to reference parameters for FX and such inside an instance of a polyphonic subpatch, for each note
besides,I designed some other objects handling polyphonic midi,mainly because I had frequent issues with hanging notes with the factory objects when trying to realize polyphonic stuff. they are also in rbrt/poly Since axo handles the midi-in at interrupt, and not at k-rate like the patcher,it's obvious that notes will get lost,so what I did is to create midi-in objects that use buffers to nicely chop down the incoming midi and spit it out at k-rate. there's also some objects to operate on the resulting midi-streams,for example rbrt/poly/midimux that can mux several midi-streams into one.
cheers, R
edit: there was a bug in my implementation which would lead to a crash when using more than 8 voices.please re-sync if you are using 'polymaster'. it was caused by using std::memmove, which, for whatever reason, is too slow.
hey @Androoclops , regarding midi initialization: seems like axoloti is starting the patch first AND THEN it's initializing Midi, this is why it doesn't find attached midi-controllers. ...I also had issues getting axoloti to realize my 'push 1' is actually 'there', but I found a reliable solution:
this makes axoloti load a compiled patch from SD-card, in this case 'yourpatchhere.bin' , on the first note-on-event.
to make this work ,you have to load up your patch to SD-card first,via patch->upload to SDcard. axoloti will create a folder with a file with a .bin -extension,which is your compiled patch.
then,rename the patch as you like and insert the name into the patch/load object.
last,upload the 'load-patch' as startup via patch->upload to SDcard as startup'
Hi, I am playing around with the looper objects, anyone managed to add a time stretch function in rbrt/looper/ldriveloop ??? That would be amazing. Any tips?
Been playing around with the s2f object for a while, which is really nice Today I was testing it with higher sample number and I think I came across a bug or a limitation if you will, so I just thought I'd rapport it back to you.
When you feed it a value of 2097152 or higher, it wraps to a negative value, like it overflows? Dunno if that is the correct word for it.
But using a value lower, like 2097151, like on the picture it works great, but anything above 2097151 wraps to negative values.
I actually also had another solution for it, but it was not as elegant as yours, so thought I'd try and make a fix to your code instead.
If you bit shift both numbers >>10 BEFORE doing the division, it works for sample input up to 1.073.741.824 samples. It will output 0.0001, if you print the value to the log.
I think that should do it. That gives a high overhead for manipulating timing even for high sample inputs.
And also need to change the 281474976710656.f number to 281474976710656: - remove the float so you can bit shift it. Shifting don't work for floats, it seems.
I could make a new object or maybe you want to change your code, so we can avoid duplicates in the already hefty library?
The fix:
Ps. There is also an unused "float tb" in Local Data that can be removed.
here's some objects for SD - card I/O. the cool thing is that they can save you a lot of SRAM when you need to save/load a lot of different tables, since the individual objects are using code that is centralized in an object called 'rbrt/SD/api'
..also, you can save/load chunks of a table via 'rbrt/SD/save load table area'. 'rbrt/SD/browse' is a rather minimalistic file-browser that can definitely be improved.
and AH! there's 'rbrt/disp/print string' to display strings in axo's console window.