Zebra 3 Public Beta (final beta)

[Yorrrrrr]

I'm finding the GUI really heavy/slow when opening things. Is this something I could expect to get better as beta progresses?

[Fannon]

I'm finding the GUI really heavy/slow when opening things. Is this something I could expect to get better as beta progresses?

I also hope this can be improved. The other u-he synths load very fast for me and I already appreciated that. Zebra 3 also loads very fast if you don't open the UI (audio-ready), so it seems to be just the UI that takes up so much loading time.

For me it takes about ~1 sec until Zebra 3 is audio-ready and then another ~12 seconds until the UI opens. This is on a Windows 11, Bitwig, CLAP and Ryzen 5950X Desktop. Right now Zebra 3 is the slowest UI loading plugin for me, even slower than Arturia synths (which takes much longer to be audio-ready, but then UI loads quite fast). Hive loads almost instantly to audio-ready and maybe 3-4 seconds until UI ready.

Since u-he puts a lot of care into optimization and performance, I'm pretty sure this will get better

[bite_me]

Win11, Bitwig6, ~30Gb Ram, mostly offline PC. Z3 Clap opens superfast but closing the GUI is minimal laggy (1sec).

[sQeetz]

Doesn't happen on my old M1 MacBook.

[bite_me]

I would like to have the possibility to engage/ disengage modules directly on itself. Think "mousearm" Urs. Don´t want to be forced to hover over the matrix for that.

And while I´m at it: Have a look at Drag N Drop King Hyakken.

[Fannon]

Win11, Bitwig6, ~30Gb Ram, mostly offline PC. Z3 Clap opens superfast but closing the GUI is minimal laggy (1sec).

Interesting, then maybe it's a problem that only affects some machines. I also have 32GB RAM. My SSD is very fast (as fast as M2 PCIe4 SSDs go), so I don't think it's that. What is superfast for you?

Closing the UI is also laggy for me, about 1sec of Zebra 3 only with grey background.

When Zebra 3 is already loaded and I only have to enable the UI in Bitwig 6 - e.g. when switching tracks, it takes around 8 seconds for me to load.

[Urs]

So the UI...

Slow startup is very likely one thing, while laggy drawing is another.

UI startup is related to accessing image files, loading and parsing the script file and performing some tasks. One of the tasks is new and sets Zebra apart from our other plug-ins. I also think it is the bottleneck, but I can't say for sure. It's strange that it uses that much on some systems, but then a fraction of a second on others. We'll need to do more testing here. On a positive note, we have slimmed down our script file which slashes loading time in half, which will also come to our other plug-ins.

Laggy drawing is the result of switching to vector graphics in conjunction with high DPI monitors, while we are still rendering on the CPU on Windows (probably also on Linux). I'm determined to address this in 2026, but can't say how long this takes and how well this is going to work.

I have not at all checked out what's happening on closing the UI and why that would be slow.

[jtsterays]

Yea both opening and closing take 1-2 sec for me too. W11, FL, 5800x.

[Urs]

I would like to have the possibility to engage/ disengage modules directly on itself. Think "mousearm" Urs. Don´t want to be forced to hover over the matrix for that.

This is on our ToDo-List, but can't yet say if and when it comes to Zebra 3.

And while I´m at it: Have a look at Drag N Drop King Hyakken.

What in particular should I look out for?

[Fannon]

Laggy drawing is the result of switching to vector graphics in conjunction with high DPI monitors, while we are still rendering on the CPU on Windows (probably also on Linux). I'm determined to address this in 2026, but can't say how long this takes and how well this is going to work.

I have not at all checked out what's happening on closing the UI and why that would be slow.

Ok, I should have pointed out that I have a 4k monitor and usually use 140% UI size. But besides the long time to load and unload the UI, the UI doesn't feel laggy to me.

Does rendering performance only depend on the scale percentage or also on the overall resolution?

Thanks for looking into it!

[Urs]

Does rendering performance only depend on the scale percentage or also on the overall resolution?

As far as I know, it's just the scale percentage - which is typically set to a higher value on a higher resolution display. But we also have an automatic detection of high DPI settings on Windows, where the 100% UI might be rendered at 300% or so. I do not know exactly how it works, I'm not using Windows much.

[Chris-S]

But we also have an automatic detection of high DPI settings on Windows, where the 100% UI might be rendered at 300% or so. I do not know exactly how it works, I'm not using Windows much.

Yes, in Windows-Setting you set a scaling factor (on my Laptop it's set to 125%).

And in the compatibility settings for a program you can set either "scaling by OS" or "scaling by App".
"scaling by OS" may make the graphics blurry.

Programs are able to report "DPI-awareness" to the OS, so that Windows knows this app should not be scaled by the OS.

[Urs]

Programs are able to report "DPI-awareness" to the OS, so that Windows knows this app should not be scaled by the OS.

Yes, applications do, but plug-ins have to live with whatever window type the host gives to them. I know there are some mechanisms in place for VST3 and CLAP, but supporting these works well in some hosts, then may have adverse effects in others.

[bite_me]

I would like to have the possibility to engage/ disengage modules directly on itself. Think "mousearm" Urs. Don´t want to be forced to hover over the matrix for that.

This is on our ToDo-List, but can't yet say if and when it comes to Zebra 3.

And while I´m at it: Have a look at Drag N Drop King Hyakken.

What in particular should I look out for?

The way modsources are getting placed plus easy adjusting its values. No offense!

[Urs]

The way modsources are getting placed plus easy adjusting its values. No offense!

I tried Filter-4. It works exactly like our direct modulation sources. Nice way to save space, but the abbreviations may be a bit cryptic (they rely on colour coding, e.g. X1 in one colour can be something else than X1 in another).

You can literally work the same way in Zebra 2/3 by dragging modulation sources onto the direct modulation slots.

Only, in Zebra 3 we have reduced the number of direct modulation slots in order to streamline and clarify the user interface. Remember that in Zebra you need to see and edit multiple modules at once, so we don't have as much space for direct modulation slots as Filter-4 in this example.

With the experience in Hive, we put more emphasis in a true Modulation Matrix. Any knob can have several modulations, not just a fixed number.

Nice touch in Filter-4: When having a mod source crosshairs, all targets with the same source flash. That's something we might somehow consider as well.