Because nobody really believes in an OT update?
4 Likes
Bingo
Because nobody was killed by Jack Beauregard.
Haha, yeah, at this point this thread exists as a word dumpster.
So, is OT abandonware now?
Only Elektron knows.
I would not be surprised to see some minor updates being implemented like the new trig condition from DT2. But that might take some timeā¦
1 Like
take the ā(active)ā with a grain of salt I think.
2 Likes
with trig+yes you kinda donāt need step input. what else is step input for. holding a finger down on a trig to input notes is already step input lol 
2 Likes
I cannot tell you, itās my creative secret on the Digitakt 
Perhaps if we put our request in Swedish they will hear us:
3 Likes
New Trig Conditions from Digitakt II & Digitone II
It would make me very happy if the new trig conditions (e.g. LAST, NOT-LAST) available on the Digi* II boxes (and possibly others like Syntakt - I donāt know tbh) were implemented on my beloved Octatrack (ideally not through an MkIII, 
ā I have already churned my Elektron MkIs for MkIIs many times). The LAST condition is so useful for pattern changes, it would be great to have on the OT (MkI + MkII).
4 Likes
Iād love more parts. 16 parts per bank (possibly 1 per pattern) would be just awesome.
6 Likes
i 'd rather love to see Part-Lock so when you switch patterns the engaged part number would be taken over for the next pattern to play. And if they are at it they could implement a dedicated CC to set the part with MIDI, either direct or also on the next pattern like bank/pattern switch also acts on Program change - which hints it would be even possible to implement it via Sub-Bank message. Such behaviour for simplicity could explicit exclude the 4 hidden saved parts and only apply to ONE, TWO, THREE, FOUR. Also would make sense to allow the Arranger to chose the Part as well. Furthermore if the Arranger would offer a āPart-Lockā you could simply lock engage a part run thru all patterns and lock engage another and run thru the patterns again and so onā¦
It would simply finalise the superior capabilities of patterns in the OT.
2 Likes
So, basically the opposite of my request ? 
1 Like
not really. Knowing increasing the files of banks to have more patterns would also need much more memory (almost twice the bank file size) and double the led-indicator validation (maybe possible) .
well in theory you have 8 parts per bank already, just that the upper 4 are those that are stored and the lower those that are loaded. In the files it makes no difference, those 8 are in each bank and pattern (file) stored anyway. Why it was chosen that way i never really graspāed, well it is a UI solution to be able to reach parts with the 4 arrow btns
ā¦ but we would have a huge benefit by just being able to actually use the parts we already have in a more flexible or letās say more controllable way.
1 Like
Thatās really interesting and I didnāt think about itā¦
I was suggesting this because I was thinking about using the OT as a one-shot drum sample player only, so relying on the ā1 pattern = 1 kitā paradigm, and I kind of gave up with this idea because 16 Banks x 4 Parts would mean 64 ākitsā. But with 128 kits, it could be more realistic.
Quite a fan of the āreload partā combo, thoughā¦ that can be dangerous in live with ābuffered partsāā¦
3 Likes
Wow youāre right, if we just had an UNDO PART RELOAD we would double the amount of parts to 8ā¦ 
We do technically have access to 8 parts already, we just have to reload and lose it forever. With undo it would make it feel more like 8.
Realistic feature requests:
UNDO PART RELOAD
PAGE LOOP
PAGE TRANSPOSE
shortcut to SAVE and SELECT a new PART
1 Like
well the whole culprit of 4 part chunkāery is that you have no way to define chosen parts in realtime via midi (realtime meaning for the next pattern to play when engaged, just like pattern switch works). And because that is not implemented the whole firmware dev assumed (most likely) that any of 4 parts can be recalled from data in the bank file (memory) at any time (next step), therefor they MUST exist otherwise risk crash - logically. So the 4 part load UI is about ensuring you have 4 parts at any time easy (fast cause already loaded) to access via arrow keys/btns, even if 3 of them are empty. But surprise (kidding here) you can only play 1 of 8 or 1 of 4 no matter whatā¦ so software wise its all the same, some pointer swap is happening and thats it. 4 parts exist in memory loaded so you can freely switch to another pattern and the given part number for that pattern is the one you work onā¦
It would be just the same same workload when you switch from 1 to 7 or 7 to 8, which comes down to UI/UX of the machine as the actual limit and yes, maybe it was also done that way because 4 parts keeping in memory is certainly smaller than 8.
Apart from the fact that flipping to another part likely internally triggers evaluation and if that evaluation is coded to run for 4 parts, well you safe the work for āhiddenā 4 parts which in turn than are just hanging out at the file/memoryās end doing nothing.
ps: how do we address limits in UI? yep yep yep, with midi in example.
1 Like