I ran into the strangest behavior last night on the DT’s MIDI Tracks. I hope this is intelligible- I think it’s a fairly odd use case (and a long-winded explanation ) but if anybody else has run into this, I’d love to hear of it.
I’m using MIDI Tracks A & B to send two different sequences of CCs to a Meris Polymoon. Both tracks are set to Channel 14, with everything else OFF on the SRC page. Both tracks have CC4 set to control Dynamics (flanger depth) on the Polymoon and have CC7 set to control Bypass. All of this is working as expected- I can bypass or engage the effect and control the depth of the flanger on either track using the DT knobs.
What I found is that if I have a DEST set to CC4 on track A’s LFO, any DEPTH is ignored in favor of track B’s set CC value, even if track B is muted or if there is a p-locked sequence affecting CC4. The same is true in reverse: if I have a p-locked sequence affecting CC4 on track B, the sequence is ignored in favor of track A’s set CC value, even if track A with the LFO is muted or if the LFO is set to zero DEPTH.
This behavior is consistent, regardless of LFO MODE, Global vs Pattern Mutes or LFO/LFO T. p-locks. Additionally, any CC7 p-lock sequencing is unaffected- I didn’t try sending contradictory CC values at the same trig on both tracks, but the sequences can both Bypass the Polymoon without issue. The only way to change this behavior is by turning OFF the MIDI Channel on either track, or by changing the LFO DEST to NONE or an unused CC. And with both tracks’ LFO DEST set to NONE, both tracks’ p-lock sequences run as expected, even when they target the same parameters.
I can’t figure out why this is happening. If the DT prioritized CCs from the LFO, then the track A’s LFO should have an effect when track B’s p-lock sequence is muted. My best guess is that when a CC is selected as the LFO DEST, the DT is constantly sending a “starting” CC value to that DEST, and that “starting” CC value is the set CC value of the LFO DEST CC.
Seems like midi LFO and mute behavior combined with the same channel on both tracks and a lack of message filtering causing a priority to whichever message you can’t avoid being triggered instead of the desired behavior.
Yeah, trying to send the same midi message from two different midi tracks has never worked for me, one will be prioritized and interfere with the other. Also, Midi LFOs will usually run indefinitely unless stopped or faded out, that’s tripped me up a few times, too.
An alternate approach is to put commands on a single track and use fill, or audition lock trigs (trig + yes) with desired settings and sequencer % at 0.
Definitely related, yeah! Seems like they had the opposite issue, but got to the same conclusion- any trig going to the same MIDI channel as a MIDI LFO will ‘cancel’ the LFO in favor of the trig settings.
It’s just so odd to me that this isn’t affected by the mute state of the track(s)! Maybe the intention is to make it easier for LFOs to be ‘canceled’ when changing patterns.
I guess if the other thread is to be trusted, Elektron confirmed that the behavior is intentional. I can’t say anything with certainty regarding the logic behind it though.
Luckily, I’m not really using multiple tracks at once for the same parameters! I was writing some FX sequences for delay fills and flanger and just noticed this while troubleshooting. I ended up working around by creating slower stepped sequences in place of a ramp LFO, but it does feel like a little bit of a missed opportunity
Right, I should have said “within the same pattern,” as I usually found I have to “X” out a parameter on even a muted track to get it to stop sending data.
It sounds like you’ve had a little more success than I had, though.
) but if anybody else has run into this, I’d love to hear of it.