Aha, so that's why I'm very lost there

I want it..........!!

It's 'Mine'..........

Not 'Urs'...........

For scaling the UI, will we there be an option to see more on the screen rather than just a larger version? The main reason I would like the larger UI is so I can see more modules at the same time instead of needing to scroll down if there are too many. And maybe in the larger resolution versions having an option to see 2 lower panes, and possibly scale individual modules, so the mod mapper or custom LFO is easier to use, but the rest of the modules remain small.

We're toying with the idea of making any panel "detachable" from the main gui. It could sit in its own window and by scalable to taste.

Not sure if we can burden a plugin (or our support team) with such feature.

From another thread:



I wonder if these things might be related in some ways. Pushing something into it's own window sort of implies it should be persistent and everything else mutable, or vice versa. Currently I'll often use the dumb but DIY method of transcribing from one instance of Zebra or whatever into another as a way to isolate something that I want to keep or rework, and that's a bit of both of these things

Meanwhile, I'm working on a time machine so I can go into the future to when Zebra 3 is released, because I can't wait!

Time travel in the future is nearly possible. Get shock frozen and hope that someone has a big enough microwave and a way to reanimate you at your destination.

Time travel the other way round is difficult.

It's easy - just walk into the guitar area at NAMM.

I really hope this will not bring to much pressure on the cpu .
Some vst's can bring up the cpu load when you drag some knobs/sliders ( especially all fx pansion stuff ), this could be platform dependant ...dunno ...I do know zebra never had this problem and hope it will stay that way , but hearing that vector based drawings will be used ...means ..more cpu cycles ...
damn

It sounded to me like Urs is talking about stuff that doesn't need to be animated frequently, just on configuration changes? I did have similar problems with Etch's GUI. I don't think that was necessarily about flaws in a platform or vector techniques - I figure it's a step further in how rendering routines may have been implemented in that particular case, especially developing across multiple platforms it's easy to take a few steps out of order or something and get stuck in the wrong gear.

Well, my stuff has been a mix of bitmap and vector graphics all along - but I always kept an eye on performance.

The idea is, instead of, say, 5MB for uncompressed bitmaps, load only 2.5MB compressed & high res graphics. Then dynamically cache uncompressed/scaled derivates in a 7.5MB render buffer. A few years ago 5MB was a lot. Nowadays 10MB or even 20MB is *tiny*.

The gain is faster gui opening times, better looks on resized editors and smaller downloads, at the expense of a bit more RAM, maybe not even that much. Drawing should be the same but it may be sped up on scaled guis as well.

As an example, I've developed a compression algorithm for knob graphics. 101 frames are compressed down to about 15% of the original size, lossless. Thus we can store them at quadrouple resolution for half the memory. We can also then double the number of frames for just a little bit more. Unpacking is quick and would only be done for knobs that actually move. All other knobs draw their cached images, but same images would not be cached twice.

This s however in an experimental state, as is the 3D render engine.

What date do you plan to release Zebra 3?

When it's done.

I have been meaning to ask this for ages - there was an offer mentioned about buying Zebra now and getting cheap upgrades and free if if you bought Dark Zebra.

So, does this still apply and can I use the dinosaur discount too?

What date do you plan to release Zebra 3?