After upgrading to H, I found I had to redo my memory settings and then power cycle… Worked well after that… I’m finding H not really worse than E but YMMV…
I didn’t have any issue upgrading from C to H but I hesitate to downgrade to E for pre-sliced samples I planned to use. Same results with Start parameter with slice off ? Just 128 divisions diiference and same behaviour ?
I’m pretty sure that pre-sliced “samples” work, it’s the pre-sliced empty recorder buffers that don’t hold. On H after a reboot you need to reslice your empty buffers.
Start points are very similar to using evenly sliced samples, yes, 128 even divisions. So compared to a 64 slice auto sliced sample, 0 will trigger the equivalent of slice one, 2 slice 2, 4 slice 3, etc… In flex setup slic must be off, and then you can set len to time which then relates to a length of start points, so setting this to 2, it will play the equivalent of a 64 slice(len 4 for 32 slice,etc…)
The great advantage of this is that start points remain relative when tempo shifting, when using slices they remain attached to the original tempo and things get all off and out of time when you change tempo. Not with start points! They dynamically change with tempo. 
At this point I only use slices when they need surgical start and end points from the audio editor, which usually just applies to flex samples for me. When recording into buffers I prefer even spaced since I have no idea beforehand what I’ll put into them, and the even spacing usually ends up rhythmic or melodically “fitting”.
1 Like
Okay. And I see where you’re coming from with this post. However, I feel I should outline some user perspective. My first 2 years of OT ownership have been somewhat marred not only by discovering bugs on a regular basis, but also persistent hardware faults requiring 3 returns to date. At such times one can feel somewhat ‘at the mercy’ of a manufacturer. I didn’t want to become a bigger pain in the ass by reporting all bugs, especially if I might be mistaken - I wanted Elektron on my side regarding getting my OT fixed (including the associated costs - which they have so far met, thank you Elektron!). I’m not saying that’s the reality of how Elektron approach support, just that my concern over the hardware made me wary of bringing up other stuff.
So when it comes to suspected bugs I’ve taken the policy of trying to eliminate user error first. I do this on my own to start with - isolating, replicating, re-reading the manual, searching the forums…
& When that doesn’t work I have often posted my issue here. In doing this I’m again trying to eliminate user error, but also I’m trying to get someone else to either confirm it’s been acknowledged or, if I’m honest, to report the bug themselves!! More than once my OT has been with Elektron while I’ve been chasing down a bug on here. Just doesn’t seem a good time to add more service tickets. Kinda hoping that users with no hardware worries can chase up OS issues, but kinda helping the process along with discussion…
I’m out of warranty now and that’s probably part of why I’m speaking up (though I hope Elektron will play nice if the same fault recurrs…)
Okay, so the hardware thing is a particular circumstance for me. But a consideration that applies more widely and has a bearing on how people react when they run into suspected bugs is how much TIME we have to spare. Too often I’ve started using the OT, working around those issues I’ve learned about the hard way (don’t copy and paste a slot, don’t touch the memory settings once you have some work down, don’t put midi tracks into plays free direct…) only to run into something else. Next hour is spent investigating, then it’s just “oh FFS” and switch the thing off & go to bed. Next chance I get to spend some time with it I have to decide whether to investigate and explain bugs or try to produce something, maybe just have fun. I have bug related projects piled up named “testing…” Compiling a bug report or a forum post, then following up takes even more time. Ideally yes we should challenge each other’s reports, discuss at length, eliminate user error, decide whether to roll back OS etc. But I bought this thing to USE it. A weariness sets in.
My last session ended with me watching the audio editor tracking over a completely different waveform to the one I could hear playing from that slot! Another WTF moment courtesy Octatrack (maybe courtesy incompetent user but experience tells me probably not). It’s clear something has probably gone wrong but picking that apart is going to be a lengthy process & communicating it to anyone else even longer. Freezes (whether the whole system or the sequencer), unexpected muting of all tracks, or of some tracks, slots - these are not uncommon for someone who tries to use the OT everyday. I’m talking about users who by now know to check if they have a scene overriding settings, know not to just jump up and ask others to direct them to a page in the manual. Every time something happens it’s a case of choosing to make music regardless or start detaching things, testing, discussing.
There’s no way round it. The machine is buggy. Yes there have been a ton of things where it’s my error, but I’ve unearthed lots of bugs, spent lots of time on them.
My suggestion: Elektron should provide a list of acknowledged bugs. That would save us all some time.
And if there’s a workaround that Elektron support suggest to a user on the support ticket, make that public too.
Yes I can see how that might not look good commercially, but with the OT you unleashed a beast. Nothing like it will likely come again (fingers burned even?). The OT is likely on its way to legendary status and that maverick experimental reputation will benefit Elektron, whatever they get into in future. Manage that reputation. And if you do bring out something as mould breaking again people will invest their cash, time, patience - knowing you’re going to be open about how things are progressing.
Okay I feel a little conflicted about posting this now. I don’t like the overly negative, demanding style but I’ve looked back over my past posts & it’s usually about tips or attempts to replicate bugs. Positive stuff on the whole, so maybe I can get away with a little venting here?!
I do take care to outline how to replicate a bug when I first go looking for help & here’s where I first brought up this particular bug: [EDIT: see my next post for a clearer explanation of what happens]
Hope that makes it clearer.
I really appreciate you chipping in Olle. I appreciate that someone from Elektron is keeping at least half an eye on what gets said here - especially when it gets noisy & cluttered with irrelevant spats of the kind that had to be split off from this thread. I especially take on what you say about starting unhelpful rumours and hope I haven’t contributed to that. In the case of this particular issue it looks like I took confirmation from just one other user and perhaps that’s not enough to justify repeating it here…
Well, I hope this lengthy post reflects more than just my own experience and is in some way helpful in getting the OT to a less snaggy place! Thanks!
6 Likes
Just had another few goes at testing the ‘track 1 assigns to wrong slot’ issue & can narrow it down a bit:
If you start a new project and double tap the Playback button, then right, you can see at the top of the screen it reads “LOAD FILE TO [WHATEVER SLOT AND MACHINE YOU LAST ASSIGNED A SAMPLE TO ON ANY TRACK IN YOUR PREVIOUS PROJECT]” rather than “TO STATIC 1”
And indeed it will assign to that other slot (even a flex machine slot) not to Static 1 as expected.
(I think the problem won’t occur if you exit the last project with track 1 as the active track, but with any other track active when you exit it will. But enough testing for tonight!)
Any takers to try that out and report back?
OS version? (I’m sure you mentioned it above)
Oh sorry - I did way back, but not here. It’s 1.25H. Thanks in advance!
The whole, “I was in the middle of an awesome jam and now I’m chasing/narrowing down unexpected behaviors/bugs” happens to me a lot, and I consider myself an advanced user, not stumped by solutions you’d find in the manual, etc… My borderline ocd about knowing exactly what’s going on with all my gear so that I’m always in control of what’s happening, usually makes me keep chasing those issues next time I power up as well…
Just saying that that experience happens to me as well, not trying to be negative at all. The OTs the heart of my setup and I love it and that’s why I care…
Edit: The way I make it work is by meticulously defining a saved project state that is taylored to specifically avoid the issues that I run into, while having lots of options for jamming and improvising already set up. As long as I stick to that I can make music for hours without snag…
1 Like
thanks Olle,
I just registered a support ticket for the pickup track non-working scene-locks,
hope this will be useful
Cheers
3 Likes
The comments from Clancy and Open_Mike register with me as well. The nature of what I do during the day (software development on complex systems) plus years spent officially beta testing things for Alesis and Akai means that when I run into an issue, I tend to try and duplicate it and document so it can be reported and fixed.
However, that takes a lot of time. Even as a beta tester where you got to keep the unit as compensation, the time spent doing that meant that was time away from making music, family activities, sleep, and anything else.
Now, with time at such a premium, any time I have to stop and document a bug (whether it was the Modal 002, 008, Octatrack, Prophet 12, Lemur, Parva, or whatever), it just makes me tired and sad. To document a single difficult bug properly could take most of my week’s worth of free time. I want gear to just work and when companies ship gear with half-completed OSes and fairly obvious bugs, it makes me wonder how much testing is really being done. Paying customers should not be the beta test team.
So what happens is real issues get either reported anecdotally on a forum or simply worked around if possible.
Sure, it would be great to have them documented, reported, and addressed, but since we’ve seen a real dearth of actual hard bugs fixed and OS updates that introduce more issues, it’s hard to believe anything will be done about whatever we report. I’m not going to waste my time documenting a real issue only to hear back that it won’t be fixed or even worse “thanks, it’ll go on the queue” and 2 years later not see it addressed.
If Elektron wants to have a real dialog about how much they can fix and whether any of the issues brought up will ever be addressed, that would help.
As of now, I feel that only the easiest, most superficial issues are ever going to be addressed and that harder things will never be looked at.
7 Likes
Brief description of issues:
Older:
-Switching from a pattern/part with a pickup to a pattern/part with a flex on the same track # as the pickup will trigger the pickup loop instead of flex sample if the pickup was not playing before switching, Confirmed…
scene locks from pickup track also may remain on new flex track…
Workaround: make sure pickup loop is running before switching, muted if necessary.
-Switching from a pattern/part to another pattern/part that has 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.
-Under certain conditions with sequencer running and making pickup loops using qrec and qpl, rlen max, slave loops using the x() parameter for length begin playback from the middle of your recorded loop instead of the beginning., confirmed but there’s many more details
Workaround has been to not use the slave loop multiple x() parameter and instead use one2 mode and manually define length for long slave loops.
-Pre sliced recorder buffers no longer remain through power cycles osH, confirmed
Workaround for me is use start points but has been suggested that saving and assigning a sample to the recorder buffer slot and then re recording into it might work…
Current things I need to look into:
-Switching from pattern/part with a pickup to pattern part with a thru on the same track# as pickup, sometimes the thru is at about half volume…
-Using pickups with rlen max, qrec enable but not qpl, in one2 mode with sequencer running, pressing a/b to define a length and go into overdub works but pressing c/d to define a loop and start playing results in the pickup recording changing length to your max mem allocation length…
-Switching from a part/pattern with recorder trigs to a part/pattern with different settings for recorder trigs, sometimes the recording len doesn’t get reset and the new recording gets cut or doesn’t work…
5 Likes
Indeed the idea of Elektron officially stating an official bug-list would be ace from them,
and if possible with definitive answers for each of them (will be fixed, won’t be fixed…)
My support ticket is registered on february 12th 2017, I didn’t receive even an automated answer. I know 2 days is nothing and one of these 2 days is a sunday… but this is the kind of feeling… shouting in the wind?
I hope not 
That’s one working day - give them a chance!
But yes I get the way you’re feeling about it & that’s down to a lack of openness about what is or is not planned. There have been some positive noises (did I recently read mention of getting some developer time for the OT?) but I just hope they aren’t going to spend a lot of time trying to build in some new features, when straight up fixing should be the priority.
But how would I know when we hear so little? Or we hear individually what we need to hear en masse.
2 Likes
I’ll give them time for sure!
I was used to ableton or other companies automated answers, like “your ticket has been submitted, blah blah blah very soon”
I did this support ticket precisely because I also read Simon mentionning work being currently done on a new OS for bugfixes, so I hope “my” bug could be taken into consideration.
Before reading this statement I had literally burried the hope for a new OS!
1 Like
Well, Olle just got back to me with the support ticket. He tried but couldn’t replicate the bug, so I have to get deeper in this process…
I don’t really have spare time but I should really try this if maybe they could fix the damn pickup machines bug-list…
Hope is new here, ah ah!!
1 Like
My apologies for lack of reporting my ‘mem full’ issues. Only had it once since downgrading to 1.25E and it was an easily-spotted recorder trig so not like the others. Haven’t forgotten though, will re-apply 1.25H and see if probs recur.
I have been saying the OT is dead in the water for a few years now. (Other than ol Mr Moonbeams and Bunny Rusty’s efforts.) Elekton wont say so, even tho it is bleedin obvious with all hands on deck for overbrdige. and that debacle means the 3 elektron pieces i have now are the last i will buy. i dont make money from music anymore, so I dont need new gear.
I’m not sure if this is the optimal thread, but here goes. I’ll do the support ticket thing too, of course:
At a gig last Thursday, I noticed that after switching banks (to a new song), the fx on my main pickup machine were not loaded. The new bank and pattern were selected, but even a part reload did not engage the current bank’s track effects for that pickup machine. I had to go into the part menu and save the part and then the PM’s fx were engaged.
2 Likes
I usually work out of just one bank but I have had that happen and it probably was when switching banks… I’ve gotten them to kick in by starting either record or play on the pickup. It might have something to do with how tracks from previous patterns play until a trig, but the logic not smoothed out for pickup use… 
2 Likes
timely bump
2 Likes