Things I find most dissappointing about DT sequencer

[Prints]

I asked this.

It sounds like the pattern bug is that the DT plays through a pattern twice before reacting to a program change command. Is this a clearer way of understanding it? If I’m understanding this correctly, than this sounds like something that will definitely get fixed as long as Elektron is aware of it.

And was told this

The problem is that MIDI sequencers (and I believe other Elektron gear) generally send Program Changes when a pattern first starts playing, but the DT doesn’t change the pattern until it has reached the end of its current pattern. So it doesn’t play twice, but it changes to the next pattern one pattern behind the rest of your gear.

I think it stems from the way the DT handles pattern changes on the unit itself. When you change the pattern it plays through the current pattern before changing, which makes sense in this scenario if you are using the DT on its own with no other gear. But when receiving Program Changes is mirroring this behaviour this is really not desirable and stops you being able to correctly sync patterns to other machines. It’s not a bug IMO, just poor implementation of receiving Program Changes but it is VERY annoying. Elektron basically need to change the current behaviour or add an option for instantly responding to Program Change messages.

[Prints]

I’m just super confused as well as aggravated now for being treated condescendingly. I don’t care anymore.

[Airyck]

If I have a DN and a DT, can I effectively have them send one another program change commands on the first pattern so they both change patterns immediately after the first pattern plays. That’s my question, and it’s totally relevant to my needs.

No, The first box that you initiated the change on will change pattern first, then after the other box plays the same pattern it was already playing “again” on more time it will finally change to the next pattern and both boxes will then be on the same pattern at that time. This is if you use the built in “Send Program Change” and “Receive Program Change” functionality built into the boxes.

If you manually send a program change some other way “before” the end of the pattern, it changes when it’s supposed to. Otherwise, using the method I described here (the built in method) the patterns will not change at the same time but will come into “sync” after another loop of the previous pattern.

This behavior does not happen when using “Send Program Change” / “Receive Program Change” when the Octatrack is the receiver. Octatrack pattern will always be on the same Bank and Pattern number that the DT/DN is on whenever you initiate a pattern/bank change starting with the DT/DN keeping the patterns/banks in lock sync with each other at all times.

[Prints]

If you manually send a program change some other way “before” the end of the pattern, it changes when it’s supposed to.

Wouldn’t you be able to send a program change command before the end of the patterns with both the DN and DT using parameter locks?

[Airyck]

I suppose you may be able to do this. The reason I see it as a bug is that you may not always know what pattern you are planning to switch to next. So rather than programming a lock on the fly it would be better if the patterns would alway stay in sync with each other at all times (like the Octatrack does).

This is also why I “personally” see this as a bug. The sequencers don’t behave the same going DN/DT to Octatrack vs. the Other way around. It also means that a DN/DT combo is always out of sync for one “loop” with each other before finally switch to the same pattern/bank as each other. Unless you manually send a program change which makes improvisational performances much more difficult.

The other option is to manually press the pattern change on all of the boxes at the same time, but this is less than ideal.

[Prints]

At this point, I don’t care what it’s called. I’m just trying to figure out creative solutions with the features/design it does currently have. I just need to clearly understand what those features/design are. Thanks for the help.

[Airyck]

At this point, I don’t care what it’s called. I’m just trying to figure out creative solutions with the features/design it does currently have.

I haven’t been able to think of any good reasons/uses for it as is (the pattern change functionality) but I’d love to be enlightened if I’ve overlooked it

[Prints]

A DN and a DT telling one another to change patterns at the same time is the important usage I’m concerned about here.

[Airyck]

I wonder how this works technically on the other boxes. Since program changes are MIDI, then the program change would have to be forced to be the first possible command that could be executed on all the boxes, otherwise after the switch they could have missed something. Or it would have to come slightly earlier than its set to, behind the scenes (like one of the last ticks before beat 1)

I think this is how it works. The box on which you’ve initiated the change knows it’s going to change, so it can send the message “before” it changes it’s own pattern. The DT/DN doesn’t seem capable of changing quick enough when receiving this “pre-pattern” change message from another box. I’m speculating but the bug probably has to do with it’s ability to process this message in time before it starts another pattern loop.

[Airyck]

A DN and a DT telling one another to change patterns at the same time is the important usage I’m concerned about here

Using the built in Send/Receive program change with DT/DN they will not stay locked together on the same pattern/bank at all times. There will be times where they are on different patterns right after a change for one full loop of the pattern.

[man909]

Prints, it’s pretty simple - you can have your DT or DN change patterns by sending it a MIDI Program Change message, which is a number between 0-127.

If your DT or DN is running, upon receiving this message, it will change patterns once the current playing pattern ends.

Unfortunately, this is not how most people program MIDI devices, sending PC changes in the middle of a pattern. Rather, we send them on the downbeat, and expect the program/pattern to change immediately. AKAI MPCs behave this way, well they have options to behave either way. And it’s quite useful - imagine now, your DT can be “crossfaded” between two patterns, mid-pattern. This is not possible w/ current implementation.

Is it a bug? Maybe not in traditional sense. But it causes inconsistencies with other MIDI gear, and as it would be, with other Elektron boxes. So in that sense, I’d call it a “bug” because those who have more than one Elektron box expect them to sync predictably.

[AdamJay]

Wouldn’t you be able to send a program change command before the end of the patterns with both the DN and DT using parameter locks?

You could, certainly. And dedicating a MIDI track to that means all you would need to do to stop the program change from happening is mute that MIDI track.
It could also be a conditional trig. So instead of MUTE, it could be part of a FILL command. Or it could only happen on the 8th iteration, etc.

It is a workable solution, especially if your end is more important than your means.

[man909]

It is a workable solution

It’s not particularly workable when using an external sequencer and wanting to audition different patterns quickly. It’s quite backwards.

Would be such an easy fix.

[Prints]

It would’ve been great if it had been simple instead of multiple voices telling me it could do what I wanted, and it couldn’t what I wanted at the same time with regards to my intended use (DT paired with DN). I think I’ve managed to clear the confusion now though. I’m pretty certain it will work the way I hope/intend. Therefore, it isn’t a “bug” for me.

[AdamJay]

Not ideal but a workable work around indeed!

I don’t know if any workarounds are ever ideal.
At best, sometimes they take you down a path you might not otherwise journey on to.
There are tracks I made with A4 that sound exactly the way they do thanks to sequencer and voice count limitations.
So with regards to things I am disappointed about, I sometimes have to seek what kind of creative opportunities they herd my energies into, and try (but usually fail) to ignore my disappointment.

For DT, I have been focusing more on modulus conditional trigs in place of track tempo multipliers. In order to make longer sequences.
Again, not ideal.

[man909]

it’s not a bug, just inconsistent design and implementation. Why it is the case, nobody seems to know. It certainly would not make any user’s life harder to have the option:

UPON PC RECEIVE:

1. CHANGE IMMEDIATELY
2. AFTER LAST PATTERN FINISHES

Having to program a pattern change in an external sequencer, before - is severely limiting, and leads us down no path except a more burdensome one. I urge all those critical of my ahem, criticism, to imagine a situation where they could use instant pattern change, and how it essentially gives you a crossfader on your devices. Buy an OT right? right.

[Prints]

It certainly would not make any user’s life harder to have the option:

UPON PC RECEIVE:

CHANGE IMMEDIATELY
AFTER LAST PATTERN FINISHES

I don’t think anyone is trying to argue with this. I’m not. Honestly, just want to figure out interesting things I can do with the feature set available as soon as my units arrive. Just needed the facts that I wasn’t able to suss out from reading the manual.

[man909]

Yes, I understand. What you can’t do, is change patterns immediately when sending PC change messages.