This thread is a nice idea.
Anyway, I do believe all bugs should (in addition) please be reported directly to elektron via their website (http://www.elektron.se/support-and-downloads). We all know it. Thus I do not have to mention it. I did it just as a reminder (for myself).
OT is a great instrument. Cheers.
Would be great if there was a Sticky Bug Thread for all the Elektron machines. It first acts as a point of reference to any users who have issues, which in turn would alleviate the Elektron support team.
Bumping this thread with a recent thread on tips and tricks
Started compiling notes solely on the things I’d like to explore on the nuances of pickup machines and it’ll take some time, so I think there will need to be a bit of patience and a great deal of community support to get this thread cooking
Good luck. I applaud your effort and initiative.
Not sure this is the format you’re after, but here are some doodles:
BUG : Scene locks lost on track copy.
SOLUTION : Scene locks should be copied along with all other parameters.
WORKAROUND : None (manual re-assignment).
STATUS: Reported
BUG : Master track is not sent to CUE.
SOLUTION : All tracks should be CUEable.
WORKAROUND : None.
STATUS : Reported
BUG : Echo Freeze Delay tail cuts out unnaturally 0.5-1 second after sequencer stop (single tap), when track is connected to neighbor track.
SOLUTION : Delay should trail naturally regardless of having neighbor track connected to it.
WORKAROUND : Put delay on the neighbor track instead.
STATUS: Reported
BUG : Pickup machine sampling done in REV mode writes reverse fade (fade OUT) at end of recording, resulting in a non-zero sample byte written to the end of the actual recording wave file, producing a persistent loud click at playback.
SOLUTION : Fade should be reversed for sampling in REV mode.
WORKAROUND : Sampling only in FWD or PIPO mode - or manually cropping out click.
STATUS : Reported
BUG : P-locked pitch parameter on current track glitches to 0 when saving parts during playback.
SOLUTION : Pitch parameter should not be affected by part save operation.
WORKAROUND : Select a track without pitch p-locks before saving part.
I had an issue whilst testing the latest beta which will have made it to the latest OS.
Changing parameters for the Master Track, (filter & delay), whilst holding Scene B (active), had no affect until reboot.
Elektron are aware & have recreated the issue & will be looking to sort it in a future update.
I fixed it by disengaging then re-engaging external Clock/Transport receive. Physical midi connection made no difference.
Elektron seem to think Clock has no baring & that it’s to do with switching Track 8 to Master whilst the seq is running.
I found this not to be the case as Track 8 is always Master on all my Banks/Projects.
Be good to hear from anyone else that has experienced this.
Cheers
I think I just had this happen to me, might’ve just been the Comb Filter settings I was messing with weren’t doing anything though. I’ll see if I cant recreate this tomorrow.
I wasn’t midi sync’d but I had just switched my track 8 to master.
It went away by turning sync on then off, but it took about 15 seconds.
I didn’t reboot.
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