Hi folks, I’ve searched this forum and found some similar issues but nothing that quite fits my problem. And I am puzzled.
I’m using the Digitakt to sequence another sampler, the Beetlecrab Tempera. When I p-lock a cc message using a trigless trig it seems to also send cc messages for other parameters that I have enabled but that I haven’t p-locked on that step.
Is this normal behavious for Digitakt? Are there settings I haven’t discovered? Is the other sampler at fault?
Thank you,
M
Hi, you should include more details like what cc you’re trying to send and also if you know the additional cc’s that the other sampler is receiving you should include that information as well.
Is it digitakt 1 or 2? Have you muted all other tracks to make sure the cc’s are coming from where you think they are? If you don’t know what is being received, what evidence do you have that something is being affected? Is it an audible modulation? Have you tried it In a new, blank project? That’s the first thing I’d do if muting the other tracks doesn’t kill the behavior and you can’t find the source of the additional control locks.
If it doesn’t happen on a blank project then something is wrong with the one you’re working on now, wrong could be machine error or human error. If it does have the same impact, I would start looking at the beetlecrab settings because digitakt will send velocity and note by default on a sequenced trig but a trigless trig should only be what you lock to it.
No sure if that helps but the more info you provide, the easier it will be to figure out what’s actually happening.
Ok, thank you. “a trigless trig should be only what you lock it to” is the answer I expected. And my search for a cause continues. Here’s the full breakdown in case you or anyone else have any suggestions.
Spec - Digitakt 1, latest OS, no other tracks or cc’s involved - this is an isolated experiment to try and figure out why it’s behaving this way.
In this example cc11 is effectively ‘note on’ and cc12 is ‘note off’. The value sent to the cc (i.e. 0-127) tells Tempera which portion of the sample is to be played/stopped. This portion is looped round continuously, starting when cc11 is recieved, cc12 tells it not to start any more loops, but if a loop has already started it is allowed to complete it.
So, for example, if I want portion ‘5’ to be looped for a few steps I will send cc11/value 5, p-locked as a trigless trig. And a few steps later I will stop it by sending cc12/value 5, p-locked as a trigless trig.
When cc12 hits the Tempera, it acts as though it is also recieving cc11/value 0, and portion ‘0’ starts looping - and it doesn’t stop. The reason it’s ‘0’ is because when it’s activated on the FLTR page it defaults to ‘0’, if I changed the value it would play whatever portion that value represents. With one exception…
My first idea for how to solve this was to send cc11/value 5 as part of the same trigless trig that I’m sending cc12/value 5. This does indeed stop the portion from looping but not in the correct way, it triggers one last full rotation of the loop.
So the question is - why does Tempera get this ‘note on’ cc11 message when cc11 is just sat on ‘0’ doing nothing? It’s not hightlighted yellow like the p-locked cc12/value 5 is, next to it on the FLTR page. It’s not highlighted yellow like p-locked cc11/value 5 was a few steps earlier. Puzzles…
Hrmm, yeah pretty weird. So, what’s your signal chain? Digitakt is going straight into the tempera via DIN midi? No computer or anything else in the chain?
I assume it’s sending 0 because 0 is a value, if it shows an X in the box it will send nothing, if it shows a 0 it will send a 0. I understand that you’re saying the 0 value is not P locked though, so that’s a little mysterious to me as to why it’s sending that value along with the correct one. and I assume when we figure it out it will suddenly all make sense (this is possibly the most redundant statement of all time).
I’m assuming you have both cc11 and cc12 active in the same pattern, just as a test can you create 2 brand new patterns with nothing in them, and then activate cc 11 with a value of 5 in the first one and have that fire off on the first step, then chain that pattern with (or just pattern change to) the second pattern and lock only cc 12 with a value of 5 on that one, and tell me if that behaves correctly? I think we have to rule out that having both CC’s in the one pattern is the problem. I’m not saying that I agree it should cause this, but I’d rather figure out why it’s doing it and move forward with that knowledge.
Hi nauts maybe you can monitor the midi stream, add just the computer for this. really helpful on some cases there are some free apps like (midi monitor)
Thanks. Here are a few notes on your comments:-
“I assume it’s sending 0 because 0 is a value, if it shows an X in the box it will send nothing, if it shows a 0 it will send a 0. I understand that you’re saying the 0 value is not P locked though, so that’s a little mysterious” - Yes, this is exactly the problem I’m encountering.
Thanks for the suggestion of the 2 pattern test.
Yes, the chain is Digitakt directly into Tempera using DIN to TRS cable.
Thanks for the midi stream suggestion - I’ve never heard of this technology but I can guess what it does.
CC10 - ok so I was simplifying it slightly - Tempera also needs to know which emitter to use, the emitter governs the settings for how the sample plays back (a continuous loop in the example I gave above). So yes, cc10 is activated. Full disclosure - Tempera also needs to know what note to play and you can do this by sending a normal trigger or by using Tempera’s onboard keypad. Neither cc10, nor the note effect my problem though.
I have to go to work now so I will attempt to follow your suggestions at the next available opportunity and report back. Many thanks.
Ha! This is a crazy puzzle!
Plus one for the midi monitor idea.
I’ve realised that trying to solve a midi problem without a midi monitor is a lot like trying to fix a circuit with no voltmeter.
I have used midi ox in the past successfully which is free and I now have an expert sleepers fh2 which is always connected to my digitakt and shows midi information all the time.
Well I’ve tried some experiments and I’m now twice as confused as I was before…
I used Tempera to play the note so Digitakt was only placing and removing the emitter (effectively note on/off in this case). And I tried the idea of using 2 patterns so cc11 wouldn’t be enabled and I could test cc12 on it’s own.
These are the settings:-
Pattern 1 -
cc10 / value 0 (as mentioned before, this just tells Tempera which emitter to use)
cc11 / value 3 (both of these cc’s 10 & 11 are just enabled, not locked - value 3 was chosen at random)
Step 1 p-lock - cc11 / value 5
Pattern 2 -
cc10 / value 0 (again)
cc12 / value 0 (again just chosen at random)
Step 5 p-lock - cc12 / value 5
This is what happened:-
I pressed play, portion 5 starts looping as it should do, I go straight to pattern 2, the Step 5 p-lock does nothing and the looped portion continues, I go straight back to pattern 1 and as soon as it hits step one portion 3 starts looping, then I pressed stop.
I had the midi monitor running, the results look like absolute nonsense to me and I may have used the wrong settings but hopefully someone can get some sense out of it or tell me how to do it better! Here are the results:-
21:49:37.195 From Elektron Digitakt Control 1 Expression (coarse) 6
21:49:39.161 From Elektron Digitakt Control 1 Expression (coarse) 5
21:49:39.285 From Elektron Digitakt Control 1 Expression (coarse) 4
21:49:39.982 From Elektron Digitakt Control 1 Expression (coarse) 5
21:49:41.621 From Elektron Digitakt Control 1 Expression (coarse) 6
21:49:41.744 From Elektron Digitakt Control 1 Expression (coarse) 7
21:49:41.907 From Elektron Digitakt Control 1 Expression (coarse) 8
21:49:42.072 From Elektron Digitakt Control 1 Expression (coarse) 9
21:49:43.096 From Elektron Digitakt Control 1 Expression (coarse) 8
21:49:43.260 From Elektron Digitakt Control 1 Expression (coarse) 7
21:49:43.342 From Elektron Digitakt Control 1 Expression (coarse) 6
21:49:43.465 From Elektron Digitakt Control 1 Expression (coarse) 5
21:49:43.670 From Elektron Digitakt Control 1 Expression (coarse) 4
21:49:43.998 From Elektron Digitakt Control 1 Expression (coarse) 3
21:49:48.761 From Elektron Digitakt Start
21:49:48.772 From Elektron Digitakt Control 1 Expression (coarse) 5
21:49:54.697 From Elektron Digitakt Control 1 Pan (coarse) 0
21:49:54.697 From Elektron Digitakt Control 1 Expression (coarse) 3
21:49:54.697 From Elektron Digitakt Control 1 Effect Control 1 (coarse) 0
21:49:54.697 From Elektron Digitakt Control 1 Expression (coarse) 5
21:49:56.379 From Elektron Digitakt Stop
Further experiment - I copied the p-lock from pattern 2 and pasted it onto step 5 of pattern 1 and it went exactly the same as my previous experiments - it succesfully stopped looping portion 5 but mysteriously started looping portion 3.
Puzzles…
What happens if you only enable the CC’s you want by p locking them to the steps you want them on, you can do that right? I don’t have my digitakt in front of me. So I’m saying
don’t enable those on the track level, just see what happens when you lock one to step 1 of your pattern. I read a little of the thing about emitters and values 0-3 represent different kinds of emitters with different colors, so by sending a different value like cc 10 / value 2 it should change the color of the emitter, right? just try that by itself, alone on a midi track, and see if it will let you only enable the cc in the p lock screen.
If that works, try locking both that one and cc 11 value 5 to the same step and see if it starts correctly with the correct color. If that works then do the same for the next pattern but with the off CC and value on step 1.
Means you receved CC 10, 11, 12
21:49:54.697 From Elektron Digitakt Control 1 Pan (coarse) 0
21:49:54.697 From Elektron Digitakt Control 1 Expression (coarse) 3
21:49:54.697 From Elektron Digitakt Control 1 Effect Control 1 (coarse) 0
Digitakt Stop
And STOP.
Some midi monitors show CC number and value. On yours you have generic names only. Not practical.
Didn’t get everything but beware, Elektron machines don’t send the same midi message consecutively, except notes and clock…
Ex : plocks with these values in a sequence :
CC10 val 0
CC10 val 10
CC10 val 0
CC10 val 0
CC10 val 0
What is actually sent :
CC10 val 0
CC10 val 10
CC10 val 0
Same values aren’t sent, in order to reduce midi data.
But it isn’t practical for midi tests. A workaround is to send 2 values with a one shot lfo; that way CCs are always sent. Not simple.
If I don’t enable the cc’s on a track level it does nothing. I actually tried that before and assumed you weren’t able to p-lock enable/disable of cc channel (if channel is even the right word).
And thankyou sezare56 for decoding the results for me.
I’ve just repeated the experiment and got this simplified version:-
23:22:10.927 From Elektron Digitakt Start
23:22:10.934 From Elektron Digitakt Control 1 Expression (coarse) 5
23:22:24.862 From Elektron Digitakt Control 1 Pan (coarse) 0
23:22:24.862 From Elektron Digitakt Control 1 Expression (coarse) 3
23:22:24.862 From Elektron Digitakt Control 1 Expression (coarse) 5
23:22:28.212 From Elektron Digitakt Stop
And surely this gives us an answer, right? 24.862 is the point where pattern 1 starts again, the step is p-locked as cc11 / value 5 and Digitakt is sending cc11 / value 5 AND cc11 / value 3 - and that’s why portion 3 starts looping.
I still don’t understand why it does this and I don’t understand why it fails to send cc12 / value 5 during the second pattern. And I don’t understand why it doesn’t send cc10 the first time round but does the 2nd time round.
Incidentally, I had this problem before and after updating to the latest OS.
So, back to the basic questions - is Digitakt behaving normally here or is my box broken? It looks less likely that Tempera is misreading things because if I was Tempera that’s what I’d’ve done - the only difference being that I wouldn’t’ve correctly guessed the cc10 / value 0 at the start.
Probably. Trigs works, it sends midi, doesn’t seem broken.
There is also a notion of track priority if you set the same CC number on several tracks. Avoid that.
I’d retry from scratch, new pattern, step by step, check with a midi monitor.
You can test on only one pattern if CCs are properly sent.
TLDR: Note length appears to affect the duration of the cc number being sent.
So just run some tests on my DT using a synth which has a cc filter control.
16 step loop. Set default settings so note length is 1 and cc for filter is closed. Lock a 16 step note on step 1.
No sound. Because the filter is closed.
Using a trigless trig on step 2 to open filter by sending a cc message.
It sounds for 16 steps. Even if the default note length on the trig page is set to 1 the cc filter opens for the duration of the note on step 1.
If I then place another trigless trig on step 4 and don’t lock the filter. It defaults back to the default values and closes the filter on step 4.
That surprises me.
So you’re using a blank trigless trig?
And I’m not sure what you mean about note length affecting it because surely the note length is always 16 seps as per your step 1 p-lock?
And thanks for your work, I think we’re barking up the same tree.
It didn’t send any midi in pattern 2 of my experiment - I had cc12 p-locked on step 5 and the midi monitor recieved nothing. What have I done wrong to produce this result?
Yes, I’ve done this a few times now.
Taking your questions in order.
Yes. A blank trigless trig! Which I would expect to reset all to default values and seems to do that.
My step 1 note is locked to 16 steps but on the trig page my default note length is set to .125
What’s interesting is the cc number doesn’t take the default note length on the trig page it stays high for the duration of the note on step 1.
By default I just mean the unlocked settings on the various trig and cc pages. So on the screen below you see default note length set to .125 but what I’ve noticed is opening the filter with a trigless trig on step 2 opens the filter for the duration of the note I placed on step 1…not for the default length.
As I wrote above, you probably already sent that value once. It is not sent anymore and it is normal for an Elektron device.
This is fundamental to understand.
Ok, I think we might be barking up different trees but they’re in the same forest.
And yes, I understand you now.
But you mentioned something…
…which would seem to disagree with what the original responder said…
So would you say that a trigless trig on a midi channel sends all enabled parameters regardless of whether they’re p-locked or not?
And if so, does your experiment uncover the fact that it will use previously p-locked values rather than defaults? This does all have some kind of logic to it I must admit…
Ok, I understand now, thanks for restating. And you mean I might’ve sent this value before the ‘start’ instruction on the midi monitor? And that’s why you suggest building the experiment again.
I suppose this is possible and I will build it again, being very careful not to send the value in question.
