vocoder glitch on radias and Ms2000: incoming midi message?

[ozy]

Hello.

I have a problem with a ms2000Br and a radias module in my setup (they are controller by several keyboards through a midi patch bay)

I keep the "vocoder direct level" always down to zero (i.e.: no unprocessed voice filters through the synth). This paramenter is saved in all patches, and the "direct level" knob is always turned down to zero.

In spite of this, in live situations I found myself with unprocessed voice leaking through the vocoder.

The knob is in the correct (7 o'clock = 0) position, the patches haven't been edited.

Is it possibile that the "direct level" parameter responds to some midi CC?

Could be that when using i.e. a prophet08 as a master, I send unwanted midi CC to the radias or ms2000b, which increases the zero value of the "direct level" parameter?

Since it happens live, I can't put my finger exactly on WHICH master I used before the glitch happened. Using 4 masters with plenty of knobs and controls, tracing the problem by trial and error would take forever.

And I can't filter all midi CCs out because I need 01, 07, ecc.

So I'd better start from the receiving side:

is the ms2000Br's "direct level" parameter driven by any midi CC?

is the radias's "direct level" parameter driven by any midi CC?
I didn't find any mention of a midi CC associated to the "direct level" parameter on either manual.

In the radias manual, it explicitly says that the midi cc associated to "direct level" is OFF (and rightfully so),

while there's not even mention of the "direct level" paramenter in the midi implementation table of the ms2000Br.

A glitch?

A forgotten parameter?

Thx for any suggestion.

[xmlguy]

There can be a CC for the control on the panel itself, besides direct parameter CC values. There can also be CC for Global Values that have nothing to do with the direct level on the vocoder, but with the same effect, such as the AudInThru parameter.

[ozy]

There can be a CC for the control on the panel itself, besides direct parameter CC values. There can also be CC for Global Values that have nothing to do with the direct level on the vocoder, but with the same effect, such as the AudInThru parameter.

I didn't understand either case.

Can you make yourself more clear please?


"CC for the control on the panel itself" = ?

This doesn't make any sense to me (I mean: I can't get the literal meaning of it. What could send a CC to what?)


"CC for Global Values that have nothing to do with the direct level on the vocoder, but with the same effect, such as the AudInThru parameter."

= e.g.: incoming CC7 changes "direct level" as well as general volume? Is it that?

[xmlguy]

I wasn't referring to any midi message being sent from one device to another. I was referring to which midi CC numbers are defined on the Radias for certain functions. The Radias will generate those midi CC, and it will respond to them. Something is obviously generating a midi CC that the Radias is responding to. In order to trace which one, you need to know what CC you're looking for, and that's what I was trying to help you identify. If you look in the Midi implementation table, you'll see an entry for "Panel controls" with values in the ranges "0 – 95, 102 – 119."

So, an easy way of determining the specific CC, is to generate that event on the Radias while recording the midi on a sequencer to examine.

So connect the Radias midi out to a sequencer, and only to a sequencer directly, with no midi input to the Radias. Then put the Radias in vocoder mode, start recording midi, then change the direct level, then stop recording and see the result. Do the same thing for the AudInThru parameter, start recording midi, change the global parameter, stop recording, then examine the result.

Once you know exactly which CC messages cause the problem you describe, then you can go about finding which other devices are generating them. By the way, I would expect lots of strange behavior when you send midi from one keyboard to another of a different manufacturer. Most keyboards are not designed to be good midi controllers. I would only send midi from a midi keyboard that lets you control exactly what is sent, how the controls are mapped, and then only send the minimum midi needed to get the behavior you want.

[ozy]

I would only send midi from a midi keyboard that lets you control exactly what is sent, how the controls are mapped, and then only send the minimum midi needed to get the behavior you want.

I use 4 keyboards on stage, and that's already a lot. I can't add any.

Two of them are good master keyboards (mc2000 and a70), albeit they send the odd CC now and then (mc2000 has a way of sending a random cc20 now and then when switching zones on and off... I had to balance that with counter-messages from a virtual unused pedal in),

and two are solo keyboards I use as masters as well, and can't replace them (prophet08 and vl-1) because I need the sounds and their key action is very good for those sounds.

A module as recent as the Radias should behave better than a 10-yars old master or a 15 years old synth, or at least it should DOCUMENT what it's doing in terms of Midi out and in.

Of course I'll have to map the midi out from the Radias, and HOPE that the midi IN implementation matches the midi out,

but I posted here because I hoped such a trivial datum was documented somewhere. It's usually called "Midi implementation table" in synth manual parlance.

E.g.: when the mc2000 sent my prophet OSCs out of tune, I learnt from the P08 user manual (a skinny one) that the OSC frequency pots used CC20. It was easy to confirm that mc2000 sent a cc20 message.

It's like I need to write a Radias manual appendix, which is a bit odd... You are usually compelled to READ a manual to get an instrument going.

Well, I suppose they did it to improve the "vintage analog" feeling of the radias: chasing for service manuals on the web is probably exciting for some people...

Thx anyway.