For the record, i’ve yet to fly this past hq for comment, but the midi slice playing as discussed above has a caveat to it … if you send the appropriate CC and midi note (within the two octave range) simultaneously you will indeed trig a slice … however, if you change the CC assignment value, the ‘simultaneous’ command combo as described will play the last slice ! - or to put it a better way (from my investigation), the OT needs a lag of >=60ms between sending the ‘changed’ CC message selecting the slice and the desired midi note, if they are sent at the same time (yeah i know it’ll be sequentially) the midi note will always play the current(previous) slice selection !
I’m not sure if this is catered for in the Lemur scripting example mentioned (i haven’t tried it) or if this nuance has been documented, it may well be that in a certain midi environment that internal ‘delays’ will obscure this, but i’ve tested with rock solid midi gear using Max/MSP and i’ve no reason to suspect my patching which I do at byte level.
I wonder if this is an unfortunate aspect of the OT (or a bug or an issue with my test) , or maybe it would be improved with a TM-1 ? My own testing with lemur experiments has me convinced the OT is very capable when you throw loads of midi data at it !