interesting… that seems a lot more responsive… 20 vs 60 ms, i should try it out in lemur to compare - i’m also wondering whether other cc control is this delayed, as it may not be so evident
I’ve been experimenting with other CCs lately and this problem doesn’t seem to affect any I’ve worked with so far. There’s something different about slices. My guess is that this relates to the caveat mentioned in the manual that LFOs don’t work with start time when using static samples. There may be something in the slice handling code that throttles start point modulation (for both flex & static) in an attempt to prevent the CF reader from changing addresses too fast for static tracks.
Thanks avantronica, good to know that someone else has run into the same issue.
And license, interesting idea, but it doesn’t seem to be that the OT is throttling start point modulation. You can modulate start point as fast as you want even with static tracks, and you’ll just get glitchy playback. On a flex track, you can trigger all slices immediately if you play them with the OT’s keys. The problem seems to only occur with incoming MIDI messages.
1 Like
Yes, this is all true. I didn’t explain that well. I mean that it seems to throttle the start point control from CC 17, like there’s a slew limiting on just that particular controller. Static tracks not being able to read from the card fast enough for proper start point modulation is the only purpose I could think of for this behavior.
Could you pls post a link to the template you’re referring to? Thx![/quote]
https://liine.net/en/community/user-library/view/291/
2 Likes
interesting because i was sure i had managed to trigger slices with that template…but when i tried again, all i could do was select them. i strapped a midi monitor across the output and there was no trigger note going out, only the cc17 for selection.
are you absolutely sure you were able to trigger them rather than just have the OT sequencer triggering the slice you were selecting ?
I just got a response to my support request about the slicing problem. Here’s what Elektron said:
The CC messages and the Midi Note messages are processed by different parts of the system where the MIDI Note has a priority. The best solution would
be to be able to trigger the Slices directly from MIDI Notes since there
can be a difference in delay of the system handling CC depending on the
load of the machine. I have forwarded this request to the developers but I
can not promise anything.
So they’re aware of the issue, but no promises about a solution. It’s a pretty significant issue for a slicing sampler, and it seems to be feasible to fix it, so I have some hope…maybe if some of you chime in to support they’ll recognize the desire for this.
What no one seems to have talked about is that slices require a single value: only one slice can be played at a time per track. So why would you transfer the current , well-adapted “monophonic” slice CC system to midi notes, which are set up for polyphonic applications? 
Also, imagine you have your slices laid out on pads, what happens if you hit 2 pads simultaneously? If 4 or 12? Which slice gets played? Will the octatrack crash, or just play the last value?
Go on and convince me that this would not be a problem…
1 Like
Not sure what you’re getting at here. The problem is that you can’t trigger slices consistently from an external controller because of the way the OT processes CC messages.
No one is suggesting that the Octatrack can/should play polyphonically. Using MIDI notes doesn’t imply polyphony; you can trigger a monosynth with a polyphonic keyboard just fine.
And finally, there’s is no way to play 2 pads simultaneously via MIDI, as it transmits messages serially. There’s always a last note to play, and that’s what the Octatrack will play when triggered. No worries about crashing.
1 Like
I set up lemur to play rather than just select slices. However, that workaround is not suitable for drums, just pads or atmo type sounds, due to latency to be set up to make it work.
For me, that’s the one and only feature that is really missing in the OT rather than being a nice extension for the future. I can’t believe that it’s still not implemented! Even the A4 can be set up to trigger drum kits from externally.
@MichaelHo: many synths are monophonic and ir still ‘makes sense’ to play them via a keyboard. It just needs a priotization rule inside the OT as is already applied when using slot/slices modes.
2 Likes
It’s nice to see that they are open to looking into it.
jamrod
Not sure what you’re getting at here. The problem is that you can’t trigger slices consistently from an external controller because of the way the OT processes CC messages.
Looking at the OT MIDI reference chart, there still is some free space for more midi note commands in the lowest two octaves, giving you a total of 24 possible states. Good luck with controlling the current OT 64 slice system with only two octaves. Ok, something using an octal system might work…
I hope i’m wrong but, i fear that there would be a trade-off for other OT functionality.
jamrod
No one is suggesting that the Octatrack can/should play polyphonically. Using MIDI notes doesn’t imply polyphony; you can trigger a monosynth with a polyphonic keyboard just fine.
And finally, there’s is no way to play 2 pads simultaneously via MIDI, as it transmits messages serially. There’s always a last note to play, and that’s what the Octatrack will play when triggered. No worries about crashing.
Analog monophonic synths are constrained to play the note you pressed last by their physical construction. Digital ones by their processing architecture. OT’s processing might not behave exactly like a monosynth, because it would first have to be programmed to behave that way – for example, to exclusively respond to the last played note, etc. If you look at OT’s sample trig implementation, you will see that a new note-on does not necessarily imply a note-off for the previous note, as you can have two samples play simultaneously.
About MIDI and seriality, you are simplifying too much. remember, you might be holding the pads down. How can you be sure you won’t be pressing two pads simultaneously in a live situation at some point? What will your Note Offs be doing then? Strictly speaking, multiple note values will be active simultaneously, the question is, what happens when OT is supposed play a new slice but the previous one can’t switch off yet, because its pad is still being pressed? A monosynth responds only to the last note on, because it is designed to. Have you verified how multiple simultaneous message values affect the OT? OT won’t necessarily crash, but it might not behave exactly the way we assume it should, just because we know a midi keyboard works with a midified analog monosynth… Again, i might simply be wrong, and elektron find a way to make it work. Or somebody here writes a low-latency external hack.
Actually, come back later, i will have a look at it.
I very much like richiegusto’s solution.
Here is a lighter one, with less latency, and not tied to a laptop (although you can run it on OSX/Win/Linux and more). It’s in Pd, not maxforlive. I haven’t bothered with a GUI yet, so you will have to make adjustments within the Pd patch itself, for now.
http://www.elektronauts.com/files/download/65
You can load it straight into your phone (MobMuPlat or similar), and with a fast MIDI interface, use it almost latency free (<10ms). You could script this in lemur, as undoubtedly someone already has (but with latency?). In any case, i don’t feel like making a free patch for a paid platform if you can have it on a free one.
It’s currently set up on MIDI channel 1, you can change that in the Pd patch: [ctlout 17 x], [noteout x], and clone the sub-patch to multiple instances, to control multliple OT audio tracks.
It only responds to notes with a single preset velocity, (currently: 80), because of a variation of the Note Off problem i mentioned above. (Specifically: incoming midi notes to Pd cause double bangs, which would result in the OT responding to the last Note Off instead of the last Note On if left unfiltered, so no note would be triggered in the OT) You can change the velocity value to something different inside the Pd patch – just change the [sel] argument (MPD/MPC pads at full velocity are 127?).
I currently use a delay of 1ms for the note bang, and it works, but if you run into problems, increase the argument in the [delay] object. This is equivalent to richiegusto’s “Delay” parameter.
(Note: this is very dependent on your OS and MIDI interface)
You still have to set up your pads: i.e. {C-2, D-2, E-2, F#-2, G#-2, …} to as to trigger the appropriate CC values: {0, 2, 4, 6, 8, …} Sorry, i’m not giving you any basenote option here, because configurable MIDI controllers wont need them, and you might want to assign your pads to slices in a specific order.
2 Likes
[i]license
The OT will not properly trigger the slice without sufficient lag between the CC command and the note.[/i]
Ok, i can verify this now, for ascending CC17 values. There is no lag for descending values.
Of course it still defeats the purpose of having a low latency external solution. You will always have the internal CC lag in OT to contend with.
1 Like
@MichalHo
You’re right, there isn’t enough space left for all 64 slices in the current MIDI implementation. I don’t really use the rest of the MIDI on the OT, so personally I’d love it if they’d at least give an alternate mode that allows triggering of slices via MIDI note at the expense of some other functionality.
Regarding the whole monophony issue, I just don’t see why triggering these slices via MIDI changes anything. You can already rapidly switch between all 64 slices, as long as you’re using the buttons on the OT itself. There are no issues with note offs or two notes playing at once; as far as I can tell, a new note on on an OT sample channel automatically ends the previous note.
Basically, everything already works, I just wish I had 64 buttons at once instead of groups of 16 to cycle through.
Don’t wish to sound patronising or beyond error myself, but are y’all sure you are getting the right slices triggered with such small time delays between messages
The best way to test is possibly sliceA sliceA sliceB sliceB then repeat
What I found was that the note delay was necessary to allow the correct slice cc to be implemented, I had it at around 60ms when I did it in max map months ago, I also found it was not necessary to submit the note off messages (from memory)
I have a plethora of other platforms and devices to try it on but I thought it seemed fairly conclusive it was an OT bottleneck
I’d be delighted if I got something wrong, but it was very basic stuff, so I’d be surprised
Fwiw
When the delay was too short the previous slice would sound, so the A A B B A A B B pattern should highlight that clearly
Edit: ignore comment about note off, that was related to another matter !
1 Like
Just retried this, the plot slightly thickens and worries me about my end a little
I tried with a delay of 60ms between cc and noteon/off
Pretty much it played A B C as expected
However triggering A B C repeatedly
Sometimes I’d get A A C sounding
When going from C to A repeatedly it’d usually be okay
But on two occasions when I 'played ’ C B A C B A (these are slices)
I got C B A B B A which makes no sense whatsoever-
Makes me suspicious that other issues are at hand or the OT sw is just plain buggy
Need to look into this on iOS for comparison
1 Like
@avantronica, jamrod
About the 60ms note offset: Yes, confirmed, slices really do get played more consistently when playing A B C D orders. But how to explain that trigger-behaviour for D C B A orders (or decrements in slice number) is also consistent (in my setup), when using a note delay of only 1ms?
What i also find noteworthy: the second hit on a pad always plays the intended slice, no matter if the pad increments or decrements slice number.
Unfortunately, 60ms latency (even 20ms) becomes impractical for pad bashing, which i believe some people here were wishing for, and which i was trying to enable with my slim Pd patch (which has a specific latency of about 3-4ms, when running on iOs, with an iRig - manageable, when battering pads), but i’ve given up for the moment…
The only way i see right now would be to send the OT a zero-velocity note 1ms before the actual note. This might prime the OT to play the actual sounding note with the correct slice value, but i doubt it will work just like that…
1 Like
update:
-
using a 70ms delay in my Pd patch, i get fully consistent results for ABCD as well as DCBA. Directly jumping A to D or D to A will sometimes result in “glides” as mentioned above by someone, but this effect fully disappears at a delay of 80ms.
-
a delay of 70ms in my Pd patch (running on: iphone 4 / iRig midi interface / / iOS 7.1 / MobMuPlat version 1.55) still results in slightly faster pad response than using the so-called “20ms” delay in richiegusto’s patch. Im guessing maxforlive/ableton has a lot more inherent latency than we suspect (i use a RME fireface400 for MIDI). Unfortunately, even the slightly faster response in my patch is still rather hard to use for real-time midi pad performance.
-
the upwards/downwards problem might be due to the OT working with lowest value priority (this is confirmed by the manual for track number and midi channels, see p. 123).
-
“ghost-midi-notes” did not manage to do the trick. at least not in the simple way i envisioned in my post above, as the note needs to be at more than 0 velocity. could maybe work with an Amp Level CC set to zero, but i doubt this CC will react any quicker than CC17.
2 Likes