One button many messages (Analog Rytm)

[mpanalog]

Hello all, I’ve mapped a Novation LaunchControl XL to my Analog Rytm MKII and I’m sending CC to each individual performance so I can do some fancy stuff.

Now when I change pattern, I want a way to instantly clear all performance mix values and this is where Midihub comes into play. I’ve made a patch that listens for a button press in a specific channel and when it sees that it sets all performance mix to 0.

It kinda works, but its not a good patch, the Novation values now arrive slow on the device and also there are problems with the midi clock I want to merge in the MIDI input of AR coming from the octa. I think it floods the channel and the clock messages arrive in different times, its weird.

So I think there’s surely a better way to implement this patch, any ideas are very much appreciated. I’m gonna attach the patch in this post.

Thanks

AR_Novation_and_Clock.mhp (791 Bytes)

[resonotter]

Hey @mpanalog,

a few notes & questions:

1. Is the Clock coming in MIDI A or MIDI B?
   (IN-A will cause Clock multiplication)
   The 9 lines from MIDI A also means that any message (other than the Ch1 CCs) gets multiplied

2. Do the MIDI A lines need to respond to every Ch1 CC, every value?
   (does this mean you only use In-A on Ch1 at pattern change?)

3. Have you tried mirroring the output of the patch to (say) USB-D to record the output into a DAW so you can see what might be causing the log-jam?

4. PS. Is the mapped Transform correct?
   At present, depending on the value of MIDI A Ch9 CC9 the CC# will be set to any of these:

---

Depending on the answer to Q’s 2 & 3, I think it might be worth looking at doing some filtering… (and a Transform CC → some other message (say Active Sense))
…before Virtual A-OUT so that the pipelines can be replaced by one:

(here, all the 9 Transforms in line2 become Insert Before Active Sense → CC )


PPS. There are ways around triggering 9 simultaneous CCs out for every 1 CC in, but let’s solve that problem only if necessary!

[mpanalog]

Hey @resonotter thanks so much for the great answer and your time!

@resonotter

Is the Clock coming in MIDI A or MIDI B?
(IN-A will cause Clock multiplication)
The 9 lines from MIDI A also means that any message (other than the Ch1 CCs) gets multiplied

Clock and transport comes in at B.

@resonotter

Do the MIDI A lines need to respond to every Ch1 CC, every value?
(does this mean you only use In-A on Ch1 at pattern change?)

No, just one.

@resonotter

Have you tried mirroring the output of the patch to (say) USB-D to record the output into a DAW so you can see what might be causing the log-jam?

Nope, that’s a good idea but no, I will have to see how this is done.

@resonotter

PS. Is the mapped Transform correct?
At present, depending on the value of MIDI A Ch9 CC9 the CC# will be set to any of these:

Hmm no, that shouldn’t be happening, it’s wrong.

It should be something stupid on my side because you can just see how bad the performance is and multiplication would explain a lot. The clock problem happens only when values are given from Novation to CCs 36-47 and I think that they flood the channel so much what clock messages arrive later (because everytime it happens you can see a bpm drop and then a bpm rise - more than the initial) so its like:

Clock
Flood
Flood (next clock should be here)
Flood
Clock (delayed clock, machine believes that we are playing at lower bpm than the initial BPM)
Flood (last knob message)
Clock (came faster than it should cause flood stopped, now machine thinks we play a lot faster than the initial BPM)

I will try this patch and come back to you!

Thanks again

[resonotter]

@mpanalog

@resonotter

Have you tried mirroring the output of the patch to (say) USB-D to record the output into a DAW so you can see what might be causing the log-jam?

Nope, that’s a good idea but no, I will have to see how this is done.

Virtual Outs&Ins allow us to do this quite easily @mpanalog
Here’s the transforms-in-one-line version of yours:

AR_Novation_and_Clock_OneLine.mhp

and here’s the DAW copy version
AR_Novation_and_Clock_OneLineDAWcopy.mhp

The difference is that whereas the first version just sends everything out directly:

the DAW copy version uses Virtual B & C as intermediaries so that everything that goes out MIDI A&B also is also sent out USB D

(the use of Virtual D is a bit superfluous but it does allow us to MIDI Monitor Virtual D-IN to see just how many messages (or “Overflow”!) come through

---

Warning!
I’ve tried to update your Transforms to work in one line, but not tested them. Expect mistakes!

[resonotter]

@mpanalog

The clock problem happens only when values are given from Novation to CCs 36-47 and I think that they flood the channel so much what clock messages arrive later (because everytime it happens you can see a bpm drop and then a bpm rise - more than the initial) so its like

I’d say check out my version. Given your Clock is in B, this will not solve your problem and we need to look at ways to spread the flurry of CC’s over some milliseconds.

Two ways come to mind
Have a button trigger

1. A Note which goes through a x9 Repetitions Delay
2. or a One shot LFO with depth 6

…with the various velocities/CC values then being Transformed into your desired settings
The output of both being spread over (a short) time to avoid “Floods”

Here’s LFO

giving 8msec gaps.
Delay can be quicker

Lemme know if you want any help with this bit

[mpanalog]

So I managed to fix the patch, I took inspiration from your patch and guidelines and this is the final product:

AR_Novation_and_Clock_final.mhp (893 Bytes)

I couldn’t very well describe the problem but your overall suggestions helped make this thing work.

Now everything is snappy and working perfectly, thank you