Rbrt Contributions

[chaocrator]

so, i found the difference between Pro and non-Pro. here it is.
even lines are non-Pro MIDI layout, odd lines are Pro MIDI layout (in the Programmer & Live modes).

        104 CC     105 CC    106 CC    107 CC    108 CC    109 CC    110 CC    111 CC
         91 CC      92 CC     93 CC     94 CC     95 CC     96 CC     97 CC     98 CC

80 CC    81 note   82 note   83 note   84 note   85 note   86 note   87 note   88 note   89 CC
N/A       0 note    1 note    2 note    3 note    4 note    5 note    6 note    7 note    8 note

70 CC    71 note   72 note   73 note   74 note   75 note   76 note   77 note   78 note   79 CC
N/A      16 note   17 note   18 note   19 note   20 note   21 note   22 note   23 note   24 note

60 CC    61 note   62 note   63 note   64 note   65 note   66 note   67 note   68 note   69 CC
N/A      32 note   33 note   34 note   35 note   36 note   37 note   38 note   39 note   40 note

50 CC    51 note   52 note   53 note   54 note   55 note   56 note   57 note   58 note   59 CC
N/A      48 note   49 note   50 note   51 note   52 note   53 note   54 note   55 note   56 note

40 CC    41 note   42 note   43 note   44 note   45 note   46 note   47 note   48 note   49 CC
N/A      64 note   65 note   66 note   67 note   68 note   69 note   70 note   71 note   72 note

30 CC    31 note   32 note   33 note   34 note   35 note   36 note   37 note   38 note   39 CC
N/A      80 note   81 note   82 note   83 note   84 note   85 note   86 note   87 note   88 note

20 CC    21 note   22 note   23 note   24 note   25 note   26 note   27 note   28 note   29 CC
N/A      96 note   97 note   98 note   99 note  100 note  101 note  102 note  103 note  104 note

10 CC    11 note   12 note   13 note   14 note   15 note   16 note   17 note   18 note   19 CC
N/A     112 note  113 note  114 note  115 note  116 note  117 note  118 note  119 note  120 note

          1 CC      2 CC      3 CC      4 CC      5 CC      6 CC      7 CC      8 CC
          N/A       N/A       N/A       N/A       N/A       N/A       N/A       N/A

this describes why the help patch for launchpad behaves so strange on Pro, and why its elements appear exactly where they appear.

actually, it should not be difficult at all to modify the code and get the Pro input handling. unfortunately, i can't do it myself due to the lack of C/C++ skills.

[jaffasplaffa]

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.

[Androoclops]

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...

[rbrt]

hi @Androoclops,
...midi initalization can be pretty esoteric,
'loadbang' might help,maybe in combination with my 'pulse delay' or 'kdelay' - objects...

cheers

rbrt

[Androoclops]

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

[lokki]

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)

[Dankopus]

Hey rbrt,

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.

Again, I appreciate your work.

[reubenfinger]

Hey Dankopus

(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

[rbrt]

new objects #1
Ableton Push I blocks

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

Ableton Push controlling Axoloti

This is the start of a project Im working on, to allow an Ableton Push to fully control Axoloti patches. I love both Axoloti and the Push, both are really powerful and flexible, and using the Push to control Axoloti I think opens up some interesting possibilities. e.g. imagine using the Push to drive a probability sequencer, its got plenty of buttons/pads and encoders, and great feedback via the LCD.. There are not many dedicated hardware sequencers that can offer the possibilities Axoloti…

..there are good resources here as well

How to control the Push LCD with sysex messages - Max For Live Forum | Cycling...

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.

soooo...have fun!

[thetechnobear]

Cool stuff - I think the push 1 is a great combo with Axoloti.

Alas the push 2 is not compatible with axo due to it being usb 2.0 only - besides the display is too dim anyway without power.

[rbrt]

new objects #2
a major hack at polyphonic voice assignment

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.

[rbrt]

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'

cheers,R