Triggering slices with midi notes?

the best solution I found for triggering slices via midi was using a pure data patch to delay the note until after the cc is fired off. I also messed with the length of the cc or the note (i can’t remember now) and got it working pretty good, but there will always be a slight latency with these methods.

However, the midi note to cc conversion techniques work great in Grid Record mode. Hold a trigger on the octatrack step you want, slam a key or pad mapped to cc slice and bam, its locked.

1 Like

If you have loop set to on, the slice will loop. If loop is set to off or auto, the slice won’t loop.
[/quote]
Sorry. Miscommunication on my part. I’m refering to a long single note in a chain of multisamples, not a loop. I have many multisample chains of pianos, etc. and wanted to know how they would behave if played. :slight_smile: Thanks, though.[/quote]
It doesn’t matter if the sample is a chain of loops or a chain of single shots, if you go to the playback setup menu (function + playback) and you turn loop to on, the sample will loop.

[/quote]
I understand that. But if I only want the note to sound for the length of time that I’m holding the trig, say an eighth note, out of a note that lasts say a whole note, will it only play for the length of time I’m holding it? Or will it continue to sound for the entire whole note of the slice? Does that make sense? I only want it to be the quarter note, ie. only sounding when I’m holding the trig… like an actual piano or keyboard would behave.

If you have loop set to on, the slice will loop. If loop is set to off or auto, the slice won’t loop.
[/quote]
Sorry. Miscommunication on my part. I’m refering to a long single note in a chain of multisamples, not a loop. I have many multisample chains of pianos, etc. and wanted to know how they would behave if played. :slight_smile: Thanks, though.[/quote]
It doesn’t matter if the sample is a chain of loops or a chain of single shots, if you go to the playback setup menu (function + playback) and you turn loop to on, the sample will loop.

[/quote]
I understand that. But if I only want the note to sound for the length of time that I’m holding the trig, say an eighth note, out of a note that lasts say a whole note, will it only play for the length of time I’m holding it? Or will it continue to sound for the entire whole note of the slice? Does that make sense? I only want it to be the quarter note, ie. only sounding when I’m holding the trig… like an actual piano or keyboard would behave.[/quote]
You can adjust the length of the note with Hold and Release times.
The sound will play until you let go if you set it that way (assuming your sample is long enough) or you can shorten the hold time to get short staccato notes. Plays just fine with a midi controller
Unfortunately, the audio track sequencer doesn’t record the note lengths, so you’ve got to do some fudging with p-locks and hold/release time if you have varied length notes. Alternately, you can record overdub and scroll around with the hold/release time to tweak this setting on the fly, real time. And another thing you can do is to record your take to a flex recorder instead of the grid sequencer and this will capture exactly what you are playing.

1 Like

I see. Thanks for trying to help. :slight_smile: Not very ideal for playing your parts in live then, or so it seems. Keeping my fingers crossed for some updates… some day.

It really bothered me at first, but now I’m over it. I just record live performance to flex track and save the wav file. I’ve found I can recycle/reuse my wav files a lot easier than all my old project/patterns anyway.

1 Like

You definitely want to use slice mode, otherwise the start time being modulated as you swing the crossfader over will put you out of time (i think).
That sounds like a lot of work, and at the end you will find that the octatrack doesn’t lock your slices in record mode if you are using the crossfader to change them.
It is great fun changing slices with the crossfader, though. Setting up a couple tracks with sliced loops and setting up scenes to change to different combinations is so fun you can get stuck on one pattern for hours :slight_smile:
There are many posts on these techniques if you dig in the forum.[/quote]
For sure, definitely a hassle if you have to set it up manually. I think that’s part of the reason I’ve been putting off trying it :stuck_out_tongue: However, considering the interest in this (old) thread, it might be better than nothing.

I finally tried it and it works surprisingly well. It is kind of annoying to set up (and turn off). You can even record the slices to the trigs in real time record, though that leads to other awkwardess…

What’s annoying is you have to burn a couple of scenes just to be able to trig the slices, and then you have to remember to mute or change them. Otherwise the fader will override any values you just recorded.

Also the OT weirdly transmits the slices 0-63 as MIDI CC values 0-127. This may have been mentioned in this thread already. It surprised me because it’s inconsistent with the way parameters translate to CC values elsewhere.

1 Like

what processor do you use for note to cc translation?

what processor do you use for note to cc translation?[/quote]
I wrote one in Python with the Mido library and a MIDI interface. The library works nicely, but my processor needs a lot of work :slight_smile:

That said, the above seems to work perfectly if you can roll with those issues.

1 Like

what processor do you use for note to cc translation?[/quote]
I wrote one in Python with the Mido library and a MIDI interface. The library works nicely, but my processor needs a lot of work :slight_smile:

That said, the above seems to work perfectly if you can roll with those issues.[/quote]
bummer, thought you had a hardware solution…

Nope but it will run on a Raspberry Pi no problem. I was using a Launchpad as a controller and display so the whole thing is probably cheaper (and more configurable) than the hardware alternatives.

1 Like

do you get any delays or misshits with your method?

i got the original pi and got about using it as a ‘smart’ midi host, looked at using pd, but stuck to just connecting things up on the command line - i’m just wondering (and the age of my unit may have some bearing) if you’ve ever read any commentary on the latency through the pi - i.e. on the simplest basis how much earlier would a note on sent direct to a midi monitor be when it was merely configured to pass through pd
.
if it was low or negligible in practical terms i’d be inclined to port some max patching into pd to do bespoke midi filtering or ‘issue fixing’, as discussed here
.
torn between following this up and trying to do something more dedicated with a teensy or similar
.
ps - presuming that’s the class compliant launchpad and not the original ?

1 Like

I didn’t have any issues with timing in my testing. I need to revisit to be sure though. I was using the Launchpad Mini, which is class compliant, along with an Edirol UM-2 for the hardware outs.

I’m getting more curious about this now as it occurred to me recently that I could replace my Ensoniq Mirage (don’t really use the sampler part much), Remote Zero SL (which I never use because it’s an awkward size), and the UM-2 with a Remote 37 SL which seems like the perfect size keyboard to me.

1 Like

Crank the tempo on the OT up to 140 and see if you can live record a drum beat by triggering the slices.

1 Like

I don’t think I’ll have time this weekend to try it as it looks like I’ll be working this weekend. But I will give it another shot when I can, probably after next Wednesday.

For anyone who doesn’t want to wait that long, here’s the basic setup:
A1) Make a scene (I use #8) that only locks slice #1
A2) Make a scene (#16) that only locks slice #64
A3) (Optional) get the current scenes, crossfader position, and slice # via the CC dump command. Update this whenever receiving a scene change from the OT MIDI out.

Now, when a note is received:
B1) Convert the note number from a range of 64 values (whatever key range you want, e.g. 0-63, 32-85, 64-127, etc) to 0-127.
B2) Set scene 1 to the scene created in step A1
B3) Set scene 2 to the scene created in step A2
B4) Send a crossfader CC with the value from step B1
B5) Send a slice# CC with the value from step B1
B6) Send a note on for that track.
B7) (Optional) set scenes, crossfader, and slice to those received in step A3 to reset the scenes and crossfader to where you were. This makes things less awkward.
B8) Be sure to send a note off. This part I haven’t fully worked out yet. There’s some issues with it that are kind of hard to explain but if you play with it you’ll know what I mean.

Bonus points (not tried yet): Use the note number and velocity from step B1 to create values for other CCs (filter, volume, etc.)

1 Like

OK, I found some time to play with this. I must not have tried this on the Pi before because it’s significantly slower than I remember on my old MacBook. I’m running the minimal Minibian distro on it, and it seems like 900mHz should be enough to handle some MIDI flinging around but maybe not. Not sure what the bottleneck is, could be the pi’s processors, its USB ports (are they USB 1.0?), the MIDI drivers, whatever else Python is doing, etc.

Most likely my code is just sloppy and needs some cleaning up. I did have copious debug statements before and I commented all those out and it’s was a noticeable improvement, but the magical seamless slicing effect definitely is not happening. Anyway, I’ll update if I make any progress.

1 Like

Played with this some more and I’ve got it to where I’m pretty happy with the performance now. A couple of notes:

  • Don’t send or reset the scenes on each slice trigger. This will make the OT behave just like when the slice CC is used by itself, i.e. the slice selection will be off-target. Unfortunately this significantly reduces the usefulness of this trick, because you still need to turn off the slice-only scenes to hear the locks you recorded (or they’ll be overridden by the xfader).

  • With Mido, at least on the Pi, don’t use input port callbacks. I don’t know if it’s because they run in a separate thread (or even really what the implications of that are w/r/t MIDI timing, USB, etc.), but for me they make the timing noticeably sloppier and laggier, even though they were fine on my laptop. Just put port.iter_pending() in the main loop and handle any incoming MIDI messages manually. It’s not much more complicated.

I’ve tried to pare my code to the minimum but I’ll see if I can remove any more and throw it up somewhere, if anyone is interested.

1 Like

tbh i think you lost everybody including me :sob:

I was afraid of that. Sorry. I’ll just make a video at some point.