Public Beta3: Absoluhtely Everything

[pdxindy]

Urs,
The good news is that my support thing was updated, so I could update my Dark Zebra/ZebraHZ (Rev. 1459), and the GUI works again. The bad news: I played my song back in Cubase LE4, with Mac OSX 10.6.8, the song played fine for 2 minutes, and then the pitch went crazy like it is in a demo mode or something. This is better than 2 days ago, but still much worse than what I originally downloaded on February 25th, 2013. What do I do now? Can I go back to that older version? If so, how do I do that?

Sounds like demo mode... if so, then you need to put in your serial # again then it should be fine

[aaron aardvark]

pdxindy,
Thank you for responding! All I did is re-boot the computer a couple of times, and it has been working fine for the last half hour. If it acts up again I will try your advice.

[Ch00rD]

I've just tried the latest Zebra Beta. It's all good, but I have a question.
In the XY assignments panel midilearn doesn't respond to cc1 (modulation) as it did in previous Zebra versions. Is this by design?

Yes, it's the most common source of accidental MIDI Learns.

So for as long as we still don't have a spreadsheet-view to let everyone edit their assignments, I thought it would be good to leave that out. Usually one can use ModWheel as a modulation source anyway...

Oh... so that is another part of the explanation, why MIDI control does not yet work as expected. Earlier, I was trying to use e.g. MIDI CC# 1 and 33 as a 14 bit pair (with ACE and Diva). But indeed, CC# 1 seems to be categorically ignored (and it does not work either when manually adding it). However, the complementary LSB CC# for the modulation wheel *is* recognised. So, arguably, that is another little bug: if you ignore CC# 1, then in 14 bit mode, CC # 33 should *also* be ignored.

Moreover, in 14 bit mode, CC# 33 should of course be interpreted as fine tune for the mod wheel (which it currently does not seem to do).

Fwiw, I did manage to get 14 bit mode to work, but I had to edit the MIDI configuration file manually, and add the same lines for both MSB and LSB CC#s (i.e. only the CC# should differ by 32). The order in which MSB and LSB CC#s are sent does not seem to matter here, nor does the order in which they are listed in the configuration file.

Still, 14 bit MIDI CC# control does not work as expected. The parameter value range seems to be slightly misaligned at the top end. For example, when controlling the volume of oscillator 1 in Diva, the parameter has a 'normalised' value range of 0.00 to 100.00. However, the maximum value is already reached when sending MSB = 126, LSB = 0; while this would be expected only when sending MSB = 127, LSB = 127. Similarly, when sending MSB = 125, LSB = 127 the volume is already 99.99, which would be expected when sending MSB = 127, LSB = 126. In other words, something seems to be wrong with the maths for converting 14 bit MIDI CC to parameter values in all u-he plug-ins.

[sylvainmoreau]

i finally have the 1459 for both zebra and diva but i don't see my presets in "patches" menu.
during update a window said "automatic" for preset folder but i selected manually because this autmoatic location was wrong. but i unchecked the "install presets" in case it would erase my previous presets.
so anyway i don't know what's wrong now i guess i have to install it all again because i dont' see how to change folder preset once installation is done.

i tried to use the "open in explorer" function to understand where is diva/zebra pointing to but this function doesn't work (anymore (?))

zebra cretes a Zebra.data
ZebraHz creates a ZebraHz.data
but both contains folders named : zebra2 / zebraHZ / Zebralette etc ..
i don't understand the point. do we have to duplicate presets in each folders + subs can't they point to something commun ?

i wish this update was easier. you must realise we have tons of other tools to update and good thing we don't have to go though all this for each. searching for links betas and register again restart all over is a real pain when you have work to finish.

[Urs]

i wish this update was easier. you must realise we have tons of other tools to update and good thing we don't have to go though all this for each. searching for links betas and register again restart all over is a real pain when you have work to finish.

The changes we made are based on complaints about previous installers. What you're experienceing isn't a problem with the current installer, it's a problem inherited from the previous version.

The main issue with the old installer was having ZebraHZ and Zebra in the same installer. Everytime someone updates just Zebra, he'd lose ZebraHZ. This has confused a lot of people and created a lot of grief.

Now we treat ZebraHZ as a separate product and this problem is gone. The only drawback is, one needs to re-register ZebraHZ with Zebra2 serials and maybe move a few presets. This is much less painful than what it was before.

Future updates won't cause these troubles.

[Urs]

Still, 14 bit MIDI CC# control does not work as expected. The parameter value range seems to be slightly misaligned at the top end. For example, when controlling the volume of oscillator 1 in Diva, the parameter has a 'normalised' value range of 0.00 to 100.00. However, the maximum value is already reached when sending MSB = 126, LSB = 0; while this would be expected only when sending MSB = 127, LSB = 127. Similarly, when sending MSB = 125, LSB = 127 the volume is already 99.99, which would be expected when sending MSB = 127, LSB = 126. In other words, something seems to be wrong with the maths for converting 14 bit MIDI CC to parameter values in all u-he plug-ins.

The problem is arithmetics.

A parameter with values 0-100 has 101 integer states. A parameter with values -100 to +100 has 201 integer states. Any form of control must have a resolution that allows it to hit the middle, i.e. 50 or 0.

Now, with controller values ranging from 0 to 127, the middle would be 63,5. This is impossible to achieve even with 14 bit controllers.

Hence we always used controller values 0 to 126, and treated 127 same as 126.

Otherwise it's impossible to e.g. zero a tune knob at no detune at all.

[Ch00rD]

Still, 14 bit MIDI CC# control does not work as expected. The parameter value range seems to be slightly misaligned at the top end. For example, when controlling the volume of oscillator 1 in Diva, the parameter has a 'normalised' value range of 0.00 to 100.00. However, the maximum value is already reached when sending MSB = 126, LSB = 0; while this would be expected only when sending MSB = 127, LSB = 127. Similarly, when sending MSB = 125, LSB = 127 the volume is already 99.99, which would be expected when sending MSB = 127, LSB = 126. In other words, something seems to be wrong with the maths for converting 14 bit MIDI CC to parameter values in all u-he plug-ins.

The problem is arithmetics.

A parameter with values 0-100 has 101 integer states. A parameter with values -100 to +100 has 201 integer states. Any form of control must have a resolution that allows it to hit the middle, i.e. 50 or 0.

Now, with controller values ranging from 0 to 127, the middle would be 63,5. This is impossible to achieve even with 14 bit controllers.

Hence we always used controller values 0 to 126, and treated 127 same as 126.

Otherwise it's impossible to e.g. zero a tune knob at no detune at all.

Ah, gotcha. That makes a lot of sense. Thanks for clearing that up.

I've used various approaches to such issues myself, and indeed, using an odd number of discrete steps is a very decent general solution. I'll guess I'll just have to modify a few simple custom tools I use for conversion between 0.0-1.0 float and 0-126 / 0-16128 integer ranges of parameter values whenever I want to switch automation / modulation between plug-in parameters and MIDI control (which I usually need whenever the lack of portability of plug-in parameter automation envelopes between applications gets in my way).

But let me then rephrase my earlier criticism: MIDI CC# control does not work as expected, because it is not clear to the user what exactly to expect, since this behaviour is not (yet) properly documented (unless one would count your post as such, of course). May I suggest adding this important bit of information to the user guides distributed with the plug-ins themselves? Even a simple one-liner such as the last one in your reply could help to prevent another user from similar confusion, as the presumption that the full CC# value range is used is obviously incorrect, but still plausible enough to start working from in the general case. It should not hurt anybody to emphasise that u-he plug-ins are *different* from the general case, in a positive way, even for something as 'general' as MIDI control.

[EDIT:] I'm not having much joy yet trying to account for this parameter range. It seems to shift the problem to a different place, instead of solving it. Depending on the specific parameter, there may be other important targets to hit exactly. For example, when automating the oscillator waveform parameters in Diva, apart from being able to get it to the exact centre, minimum and maximum positions, one would also want to be able to get it to sit at exactly one quarter and three quarters of its range, respectively, to achieve 'pure' triangle and square waveforms.

When dividing 126 by four, the result is 31,5. Of course, that is impossible to do in a 7 bit range of 0-126 (accordingly, this simply can not be done when using 7 bit MIDI control), but it is quite feasible in the 14 bit range of 0-16128.

Now, when sending CC# values at the exact centre, minimum and maximum of the 0 - 16128 range (i.e., the 14 bit equivalent of a range of 0 to 126): 0, 8064 and 16128, respectively, I do get values 0.00, 50.00, and 100.00 (on a parameter with a scale between 0.00 and 100.00), as expected.

However, when dividing 16128 by four, the result is 4032. When sending this to Diva (MSB value = 31, LSB = 64), the targeted parameter is *not* set to exactly a quarter of the range. Similarly, when sending a value at exactly three quarters of the range (12096, MSB = 94, LSB = 64), the targeted parameter is *not* set to exactly three quarters of its range either. Strangely enough, the results I see also *vary* (depending on what happened before): I get 24.50 / 24.60 and 74.50 / 74.60 (i.e. a 0.10 difference, while sending the exact same MIDI values to the exact same parameter). In fact, I *only* get the expected results at the exact centre, minimum and maximum positions, *all* other values seem to be incorrect. Either I'm going about this all wrong, or there is still something wrong with 14 bit CC# support… or both, of course. I'm going to have some really strong coffee now before I continue writing, because I *really* suck at maths, including arithmetics.

PS: May I ask, what does the "Yes" / "No" stand for in the MIDI configuration files? E.g.:

Code: Select all

1:2=ENV1:Dec, normal, 0, Continuous14bit, Yes //Env1:Decay
1:34=ENV1:Dec, normal, 0, Continuous14bit, Yes //Env1:Decay

vs.

Code: Select all

1:2=ENV1:Dec, normal, 0, Continuous14bit, No //Env1:Decay
1:34=ENV1:Dec, normal, 0, Continuous14bit, No //Env1:Decay

[JeeTee]

I've just tried the latest Zebra Beta. It's all good, but I have a question.
In the XY assignments panel midilearn doesn't respond to cc1 (modulation) as it did in previous Zebra versions. Is this by design?

Yes, it's the most common source of accidental MIDI Learns.

So for as long as we still don't have a spreadsheet-view to let everyone edit their assignments, I thought it would be good to leave that out. Usually one can use ModWheel as a modulation source anyway...

Ah! OK - that makes a lot of sense. I have 8 preassigned controllers that I use for orchestral samples, which perfectly map to Zebra's XY controllers. Unfortunately one of them is cc1...

You should be able to do it by setting up the X/Y that would be CC#1 to some other CC# and then editing the midi assignments file to CC#1

Just FYI, this doesn't work. All X/Ys completely ignore CC#1. However, I can use a midi input transformer in my host program to turn CC#1 into something Zebra can read.

[Ch00rD]

[…] Just FYI, this doesn't work. All X/Ys completely ignore CC#1. However, I can use a midi input transformer in my host program to turn CC#1 into something Zebra can read.

Right - CC#1 does not seem to work for 'MIDI Learn' of *any* parameter in *any* u-he plug-in, even if you manually add it in their MIDI configuration files.

[pdxindy]

I've just tried the latest Zebra Beta. It's all good, but I have a question.
In the XY assignments panel midilearn doesn't respond to cc1 (modulation) as it did in previous Zebra versions. Is this by design?

Yes, it's the most common source of accidental MIDI Learns.

So for as long as we still don't have a spreadsheet-view to let everyone edit their assignments, I thought it would be good to leave that out. Usually one can use ModWheel as a modulation source anyway...

Ah! OK - that makes a lot of sense. I have 8 preassigned controllers that I use for orchestral samples, which perfectly map to Zebra's XY controllers. Unfortunately one of them is cc1...

You should be able to do it by setting up the X/Y that would be CC#1 to some other CC# and then editing the midi assignments file to CC#1

Just FYI, this doesn't work. All X/Ys completely ignore CC#1. However, I can use a midi input transformer in my host program to turn CC#1 into something Zebra can read.

Ooops.... Thx for the correction...

[David Else]

I think i may have a nasty Diva bug in the latest 1459 beta. I am using the PC 64bit version VSTi in Reaper.

Please check this:

http://www.learndigitalaudio.com/blog/w ... bitVST.zip

It contains a .wav mixdown and the patch file that created it.

Notice the crackling/distortion in the left hand channel only during the fade. It happens if you flip to other oscillator emulations using this patch too, and other sample rates and multicore on/off.

I made the patch in the previous stable version of diva and never listened carefully to it, I don't have any other versions installed than the latest beta to compare it to now.

[PAK]

Posted in the Beta forum already.. there seems to be a problem with all vst3 in 64 bit, didn't check 32 bit yet. when i open them in cubase 6.5.3 64bit on win. First when i load the vst on an instrument track and open it, only a small window appears. After closing and reopening it, it opens up in normal size with no problem, when i try to resize it then, it keeps the window size but doubles the GUI. Don't know how to explain better.

You aren't alone. Feel better now?
The following screenshots were made using 64 bit Diva VST3 (build 1459), Win 7, Cubase 7.0.2.

You mean this when first launched?..

And this sort of thing when you resize?..

Right?

It's been there since the first VST3. I didn't report it purely because I was wondering how long it'd take someone to notice

The cause in my case, and I'm assuming yours too, is from wrapping the VST3. In the screenshots Automap version 4.6 is used. Unwrap the plugin from Automap and it should "fix" things.

BTW No other Automap wrapped 64 bit VST3 plugins I use causes these problems under Cubase.

Hope this helps

[llze]

Posted in the Beta forum already.. there seems to be a problem with all vst3 in 64 bit, didn't check 32 bit yet. when i open them in cubase 6.5.3 64bit on win. First when i load the vst on an instrument track and open it, only a small window appears. After closing and reopening it, it opens up in normal size with no problem, when i try to resize it then, it keeps the window size but doubles the GUI. Don't know how to explain better.

You aren't alone. Feel better now?
The following screenshots were made using 64 bit Diva VST3 (build 1459), Win 7, Cubase 7.0.2.

You mean this when first launched?..

And this sort of thing when you resize?..

Right?

It's been there since the first VST3. I didn't report it purely because I was wondering how long it'd take someone to notice

The cause in my case, and I'm assuming yours too, is from wrapping the VST3. In the screenshots Automap version 4.6 is used. Unwrap the plugin from Automap and it should "fix" things.

BTW No other Automap wrapped 64 bit VST3 plugins I use causes these problems under Cubase.

Hope this helps

exactly this..

[Ch00rD]

[…] Either I'm going about this all wrong, or there is still something wrong with 14 bit CC# support… or both, of course. I'm going to have some really strong coffee now before I continue writing, because I *really* suck at maths, including arithmetics.

Ok, after *way* too much pints of industrial strength extra dark espresso, I've come to the conclusion that 14 bit MIDI CC# support indeed is broken (and still not documented properly).

There are a lot of 'zones' where the exact same parameter values are replicated, for no apparent reason. This (1) unnecessarily limits the value resolution, and (2) severely frustrates using 14 bit MIDI control.

For example, when targeting a parameter with a value displayed on the GUI in a range between 0.00 and 100.00, such as Diva's envelope parameters, this goes for the values between 0.00 and 0.99 (0-127 AND 128-255), between 3.00 and 3.99 (512-639 AND 640-768), between 6.00 and 6.99 (1024-1151 AND 1152-1279), between 11.00 and 11.99 (1792-1919 AND 1921-2048), between 15.00 and 15.99 (2432-2559 AND 2560-2687), and so on. In other words, MSB value 0=1, 5=6, 8=9, 14=15, 19=20, etc.

In effect, a substantial part of the available 14 bit value range seems to be used in a completely redundant manner. More importantly, perhaps, it is very confusing, and really gets in the way of using a more or less sane conversion using 14 bit MIDI CC#.

For example, if one would sweep a parameter value across the entire range using 14 bit MIDI CC# by sending values incrementing in steps of exactly one each from 0 upwards, the result is not a smooth slope, but is similar to an upward sloping *sawtooth*.

Since 14 bit MIDI CC# values go from 0 to 16383, and most (or at least many) parameters are displayed on the GUIs on a range such as 0.00-100.00 (i.e. 10000 discrete steps on the display), or 30.00 to 150.00 for the all-important filter cut-off (i.e. 12000 discrete steps on the display), would it perhaps make more sense to (optionally, perhaps) use a scale for 14 bit MIDI where the step size matches the resolution of the GUI value display, in a continuous manner? Such an approach would not use the full available resolution (either), but trade it off against being a system that is arguably easier to work with.

E.g. to set an envelope decay parameter to 25.00, one would send a value of 2500 (MSB = 19; LSB = 68 ); to set it to 100.00, one would send a value of 10000 (MSB = 78; LSB = 16). Similarly, even some non-zero based value ranges would easily fit in the available value range. E.g. to set the filter cut-off to 30.00, one would send a value of 3000 (MSB = 23; LSB = 56), to set it to 120.00 one would send 12000 (MSB = 93; LSB = 96), or to set it to 150.00 one would send 15000 (MSB = 117; LSB = 24). As you can see, this would easily fit in the 14 bit range, as there is plenty of headroom left.

[Urs]

We'll look into these things. I think Clemens fixed a bug in the 14-bit MIDI support (due to the lack of suitable controllers, my focus was merely on a coarse/fine approach with 2 separate knobs when I implemented it).

I do believe that the majority of fixes outweighs the problems left - especially if remaining niggles are related to VST3 which hasn't been available before. Hence we might release these anyway and take it from there.

Regarding the resize issue. Well. What revision number is shown on the bottom right? Because quite frankly, if it really is the current revision then I'm happy to postpone VST3 support for another year or two. We're wasting way too much time over this.