great work baddcr
I don’t have time to write proper report and verify recreation steps but I’ll throw this out there since it was asked if there are any more known issues and then try to verify, write report soon…
While switching from a pattern linked with a part with a pickup machine on at track, then switching to another pattern linked to a different part with something other than pickup machine on the same track, if the pickup machine isn’t running before switching, the new part/pattern will trigger the pickup machine loop from the old part instead of the assigned sample of the new part, even if sample locked and starts silent is selected. Also scene behavior of new part might still respond to the old pattern/parts scene. Workaround has been to make sure pickup loop is running before switching, muted if necessary.
Also noticed while switching from a pattern linked to a part to another pattern linked to a different part with recorder trigs, sometimes the recorder source and length from the first part get used, even if I lock the sources.
Workaround has been to set all recorder buffers of same track number across parts to the same settings.
Sorry for the not proper write up but wanted to let y’all know about this and I’ll look into it more and post back
Bug
If you P-Lock some CCs in the MIDI Sequencer, they will be sent right after the note-on message. This leads at least to glitches (eg if you p-lock the cutoff-frequency of a filter, you can hear the change coming a bit too late) or even to unpredictable things (eg if you p-lock the attack-time of an envelope generator, then it sometimes happens, that the attack time is changed after the attack phase is over, so you get the modified attack time on the next note).
Solution
Just fix it.
Workarounds
If the bug practically affects only one parameter (eg the attack time), your external synthesizer hopefully has a modulation matrix, that allows you to modulate a parameter via velocity. Because velocity is always send within the note-on event and not later as a separate CC.
If you have trouble with multiple parameters there’s another approach to get around that bug. For every step the octatrack starts sending a note-on event for track 1 (if there is a trig set), then it sends CCs for track 1 (if there were P-Locked CCs). Then for the same step the procedure is repeated with note-on-events and CCs for track 2. Then the same for track 3 and so on.
The workaround then could be to have your note-on events for a particular synth on let’s say track 2 and your CCs for the same synth on track 1. You definitely WILL lose the overwiew, but sometimes a working P-Lock is more important.
1 Like
Bug
The MIDI sequencer locks velocity and note length when you insert notes with an external keyboard in grid mode. While this is a very usefull feature in live recording mode, it can be extremely annoying in grid mode. Practically velocity and note lenght are rather random values if you work in grid mode. So after placing a trig in grid mode via external keyboard, for every trig you have to remove the p-locks on velocity and note length.
Workarounds
The only workaround that i found is to go back to OS Version 1.21B. Sadly in this version velocity and note lenght are also not recorded in live-recording mode. Albeit I guess this is a good choice, because the step-sequencing-approach (i.e. grid mode) fits much better to the elektron workflow as the live-recording-approach. The latter is more the strength of MPCs.
Sorry for my bad english. I try to explain it on another way.
The CC is always sent after the note on event. Depending on what the CC corresponds to, the effects can be everything between “noticable qirk” and “random errors”. The first occurs if the CC controls eg filter frequency. You then just hear a short glitch at the beginning of the note. The latter occurs if the CC controls e.g. attack time. Just imagine the enveloge generator starts the attack time because of the note-on-event. Then, when the attack time is almost over, it receives a change of the attack time. The resulting envelope is always “wrong”, but HOW it exactly looks of course depends very much on the previous attack time setting and whether the cc should increase or decrease the time.
Of course I reported this bug (i guess two years ago), but please don’t ask further as long as we want to keep the bad vibrations out of this thread.
Again I think I have to explain it another way. Imagine you have an external keyboard connected to the octatrack. You want to place a “c”-note on a trig. So you hold down the respective trig key on the octatrack and then press a key on the keyboard. I think it is obvious that the velocity with which you press the key in this procedure is completely random. The same holds for the note length. So i see no reason why one should want to record velocity and note length in this procedure. Therefore i can’t see, how this could not be interpreted as a bug.
Remember that i’m not talking about realtime record mode.
And remember also that the workaround (going back to an older version) works perfectly!
2 is not a bug, just disable velocity from your keyboard or get into practicing your velocity strikes
1 reminds me of the issue with playing slices via midi, it is possible, but it requires a hefty delay between sending the slice selection cc and the note for it to work, there seems to be an issue whereby the cc is dragging its heels to be updated and the 20-50ms note delay allowed the two commands to work at one trig (albeit at the expense of note latency) - so perhaps the above is also related to a delayed cc response, rather than a matter of message ordering
there is a thread somewhere
http://www.elektronauts.com/t/midi-notes-triggering-slices/8516/69172
http://www.elektronauts.com/t/triggering-slices-with-midi-notes/433page:4
The MIDI Standard requires that every note-on-event comes with a velocity.
Therefore you can not disable velocity. You could just set it to a default value, but that will be then stored with every trig. This would make it impossible to change the velocity globally without removing the p-lock of every trig.
BTW: I’m a classically trained pianist and without doubt i would say that my velocity striking skills are excellent. But of course not perfect, as long as i’m a human.
The changelog states that “The MIDI sequencer now locks velocity and note length via external MIDI keyboard in grid record mode”. This suggests this is a intended behaviour. If anybody has a (realistic) situation where this could be an improvement, please let me know!
The MIDI Standard requires that every note-on-event comes with a velocity.
Therefore you can not disable velocity. You could just set it to a default value[/quote]
BTW. I write midi software. I know the format of all the messages, i assumed you’d understand I meant velocity sensitivity or variation, plenty of external gear allows you to do this, it’d be simpler to encoder plock the note and leave default velocity or erase the vel plocks (very easy in one pass) or record it impeccably in realtime with your chops - either way, it seems like a good current configuration to my mind, and clearly not a bug as stated, fair enough as a feature request, there’s no doubt a thread for that
I think I understood your intention. But i wasn’t shure if you really got the problem (2). So i hopefully made clear, that in my feeling the behaviour makes absolutely no sense. Therefore i would call it a bug (where a workaround exists, fortunately). And of course mentioning something in the changelog or in the manual should not affect whether you call it a bug or a feature.
So I still think that you err if you call it an intended behaviour and not a bug. But as long as this is not obvious to everyone, you are doing a good job in kicking out problem (2) for the benefit of the other issues’ relevance.
I posted two possible bugs on page 1, it was asked what OS I’m running, which is the latest 1.25D.
Unfortunately I caught a cold and can’t test further but both of those issues happened to me repeatedly until I applied the workarounds I mentioned… Perhaps someone else can confirm if these are actually bugs and if no one knows I’ll test further when I’m feeling better and have some time…
Groove On…
Hey guys new to the forum had the octatrack for a couple months now just getting the swing of it. So a couple of things ive noticed. When get a flex sample that I have recorded and save it to a static slot it will not always slice it when I am in the static slot sometimes it will sometimes it won’t. I have had some other freezing up when I am switching tracks and it will get frozen on a track. Thinking this may be a hardware problem as I haven’t seen any other this in reported bugs. Thanks
Petition: Please squash the rest of OT’s bugs and don’t worry about new features!
3 Likes
Where can i find the bug list?
There are loads of non pickup bugs too 
Here was an attempt, still needs some love…
https://www.elektronauts.com/t/ot-known-bugs-workarounds-document/8475
1 Like
Thanks!
It’s been mentioned recently that the OT is still supported, sort of inferring we could get another fix. Also, I just filled a bug report that was confirmed, and was told that they’d pass the info to devs who have been busy with new products, that the OT still needs some love. No guarantees but it’s not over yet…
Edit: This is why I feel if lots of us file bug reports soon maybe it’ll tip the scale and get some attention…
About the pre-sliced sample bug ticket you sent, it has to be fixed, among others. Working things can’t be bugged after an update.
Maybe an ‘acknowledged bugs only’ thread? Just to pull together the stuff we can reasonably expect
Simon mentioned in the recent massive IRC meetup late January that an OT bug release is pending. No indication of which bugs. He also mentioned no new features will be added from hereon in, only bug fixes.
2 Likes