Value jumps using Continuous14bit MIDI controllers

[noloops]

Hi

I'm a proud owner of Zebra 2.5.4. Today I tried to use MIDI automation with 14 bit resolution (MSB/LSB pairs) and noticed value jumps. That's what I did:

0) Starting from scratch with the "initialize" patch
1) 2.5 mode checked
2) Midi Controllers menu: normal & Continuous14bit checked
3) On XY-Tab: X1 MidiUnLearn (using context menu)
4) X1 MidiLearn with CC #40 (LSB) (using context menu)
5) X1 MidiLearn with CC #8 (MSB) (using context menu)
6) Assigning OSC1:Tune to X1

Now I can hear the pitch jump when the MSB value switches, but only in certain (reproducable) cases, e.g.:

MSB / LSB => MSB / LSB
59 / 127 => 60 / 0 PITCH JUMPS
60 / 127 => 61 / 0 perfect transition
61 / 127 => 62 / 0 PITCH JUMPS
62 / 127 => 63 / 0 PITCH JUMPS
63 / 127 => 64 / 0 perfect transition
64 / 127 => 65 / 0 PITCH JUMPS

I can also see the yellow XY1-marker jump whenever the pitch jumps.
The same thing happenes in the other direction:

MSB / LSB => MSB / LSB
64 / 0 => 63 / 127 perfect transition
63 / 0 => 62 / 127 PITCH JUMPS
62 / 0 => 61 / 127 PITCH JUMPS
61 / 0 => 60 / 127 perfect transition
60 / 0 => 59 / 127 PITCH JUMPS

Is this a bug or am I doing something wrong?
Thanks for any help.

Jan

[Urs]

First off, you should upgrade to Zebra 2.6 - it's a free upgrade!

I think we fixed some stuff in there, but maybe it isn't perfect yet. Can you send us a project or MIDI file to support at u-he dot com?

Thanks,

- Urs

[noloops]

Hi Urs,

Thanks for your quick response. I updated to Zebra 2.6 and sent you the info. The behaviour in 2.6 is different, but there still are jumps. I also made a MIDI-OX log, where I could here intonation jumps of about a quarter note:

TIMESTAMP IN PORT STATUS DATA1 DATA2 CHAN NOTE EVENT
76822 3 -- 144 60 101 1 C 4 Note On
93198 3 -- 176 8 93 1 --- CC: Balance
93198 3 -- 176 40 2 1 --- Control Change
99590 3 -- 176 8 93 1 --- CC: Balance
99590 3 -- 176 40 1 1 --- Control Change
101654 3 -- 176 8 93 1 --- CC: Balance
101654 3 -- 176 40 0 1 --- Control Change
104686 3 -- 176 8 92 1 --- CC: Balance
104686 3 -- 176 40 127 1 --- Control Change
113870 3 -- 176 8 92 1 --- CC: Balance
113870 3 -- 176 40 126 1 --- Control Change
120494 3 -- 128 60 0 1 C 4 Note Off

For me it looks ok, with identical timestamps for corresponding MSB/LSB messages.

Jan

[Ch00rD]

I complained about a similar issue a while ago with Diva, and after some very quick testing I thought it had been fixed with the 2.6 release. I'll test it a bit more extensively, with Zebra2 as well, and see if I can reproduce the issue.

[abstractcats]

In What DAW/Sequencer and OS?

[Ch00rD]

Ok, tested this a bit more with ACE, Diva and Zebra2, and there is indeed still a bit of an issue. Fortunately, there's also a relatively easy workaround.

When you use MIDI Learn to bind a 14 bit MIDI CC# pair to a plug-in parameter, one line is added to the configuration file (i.e. com.u-he.ACE.midiassign.txt, com.u-he.Diva.midiassign.txt, com.u-he.Zebra2.midiassign.txt, etc.); for example in the OP's case of binding CC# 8/40 to the X-axis of the first XY-pad in Zebra2, this line is added (showing only the MSB, CC# :

Code: Select all

1:8=PCore:X_1, normal, 0, Continuous14bit, No //Core:X1

However, after having done this, as the OP describes, the plug-in then still only responds in a low, 7 bit resolution. As a minor clarification to the OP's description: there is in fact no "perfect transition" in many cases where the value is incremented/decremented by a single step; there is no transition at all, hence the resulting 'jumping'.

To fix this issue yourself, copy the line (for each individual learned 14 bit CC# pair) to a new line immediately below it, and change the second number (which stands for the CC#) to the LSB CC#, which is (by definition) the MSB CC# plus 32. So in this example, you'd manually add this line:

Code: Select all

1:40=PCore:X_1, normal, 0, Continuous14bit, No //Core:X1

When both lines are present, the plug-in parameter should properly respond to 14 bit CC# data.

Note that you should edit these configuration files only after having (temporarily) removed the plug-ins from your host, or without having it running at all - otherwise the files may get overwritten accidentally (e.g. when closing the plug-in window, learning another parameter, etc.). On OS X, these files are stored in this folder:

Code: Select all

~/Library/Application\ Support/u-he/