Zebra's biggest flaw

[bagginz]

it got a bit tedious flipping through the presets while in arp view (to see how interesting / different each arp looked) then having to keep flipping back to the "global" tab to actually turn on the arpeggiator.

I've always found it strange (and inconvenient) that I have to have to temporarily exit the arp. page to turn it on or off.

At least from my perspective, mirroring the arp on/off button in the arp module makes perfect sense.

cheers,
bagginz

[kvrian1000]

For me the biggest flaw is the inability to save the large size as the default when opening up a new instance of Zebra.

You should be able to do that already. Set Large mode the "Look" button at the top right of the interface, then select the "Make Default" option from the same menu. Same goes for the skin.

Unfortunately it doesn't.

Different gui sizes in plugins is still a really tricky thing. Some hosts, even popular ones, are just not yet there. I have thought about making this optional (like latency settings and gui editor etc.). But that's also rather a matter of general improvements than of Zebra-specific flaws in algorithms.

Urs

Why not allow us to save the size...

Then, if a size other than default is queried to be set from the config file in a host that causes problems, don't set the that size and just use default.

Simple stuff.

[Urs]

Simple stuff.

It's not that simple, really... I'd have to check if this is correct, but I think that certain plugin formats save a pointer to the size structure, not the actualy size. Thus the plugin might be oblivious of any host query.

[SayersWeb]

I've always found it strange (and inconvenient) that I have to have to temporarily exit the arp. page to turn it on or off.

At least from my perspective, mirroring the arp on/off button in the arp module makes perfect sense.

Yes... same here.

[zvenx]

Simple stuff.

It's not that simple, really... I'd have to check if this is correct, but I think that certain plugin formats save a pointer to the size structure, not the actualy size. Thus the plugin might be oblivious of any host query.

how Does NI overcome this?
Kontakt, Guitar Rig 3 for instance allow you to set up your own size.
rsp

[Urs]

Simple stuff.

It's not that simple, really... I'd have to check if this is correct, but I think that certain plugin formats save a pointer to the size structure, not the actualy size. Thus the plugin might be oblivious of any host query.

how Does NI overcome this?
Kontakt, Guitar Rig 3 for instance allow you to set up your own size.
rsp

I don't know. I havn't said it's impossible, I'm just afraid of the time I'd loose by trying out workarounds for so and so many hosts. I'll do it at one point, but now is not the time

[zvenx]

ok

[blurk]

Wishlist: I'd like the directory structure of presets and support files (MSEGs, Oscs, misc files) to be the same in the Windows and OS X versions.

Yes, I know this may be more difficult than I imagine, because you don't want to use registries (Windows) and do want to use standard locations (OS X).

Why do I want this? I want to be able to rsync to my Windows and OS X boxes from a master copy of the U-he data on my NAS box. All this prolific preset design (for which I am suitably grateful) is quite a chore to keep all machines up-to-date with.

Edit: and having the master on the NAS box is useful as a backup, and I take my off-site backups from the NAS box.

[kvrian1000]

Simple stuff.

It's not that simple, really... I'd have to check if this is correct, but I think that certain plugin formats save a pointer to the size structure, not the actualy size. Thus the plugin might be oblivious of any host query.

Then don't do it by writing in exceptions manually.

Instead, attempt to resize the window in host X at init time when reading whatever size is saved. Query Zebras window size after a timeout, and, if the sizes don't match (IE, reszing failed), write an exception specifying the host in to com.u-he.Zebra2.UIprefs.txt... Upon next launch of Zebra in that host, the options to resize via right clicking on the GUI will be removed, leaving only the skins and Make Default menu entries.

[Urs]

kvrian,

I'm almost certain that resize works on pretty much all hosts now. It's about saving a default size and saving size with project settings. The problem is, some hosts want to know the actual size of the window before asking the plugin to open it. Which is a slightly odd behaviour because one plugin can have different sizes based on various factors. In AU land for instance a plugin can have multiple types of editors (and each editor could be used by multiple plugins) and consequently the size is determined by the editor itself upon opening a view for a specific plugin, it's not determined by the plugin itself. This is the most straight forward approach to be fail safe, and it doesn't involve extra work that is not necessary unless the editor is actually opened e.g. when scanning plugins.

A global preference file won't help much because each ui skin can have a different size, and each skin can vary in size even without the resize feature. In effect, each instance may have a different size based on various factors (skin, ui resize feature, or a control within the gui that resizes things, or complex stuff like "the editor extends vertically by X pixels for each open instance of plugin A, and Y pixels for each instance of plugin B").

Hence in many scenarios the editor size can not be foreseen without serious processing, possibly adding a few seconds of opening time for some hosts. The behaviour of some hosts is just a lack of imagination of what a plugin could do. A simple trick (query editor size after opening it, as 98% of hosts do) would solve the problem.

Cheers,

Urs

[kvrian1000]

kvrian,

I'm almost certain that resize works on pretty much all hosts now. It's about saving a default size and saving size with project settings. The problem is, some hosts want to know the actual size of the window before asking the plugin to open it. Which is a slightly odd behaviour because one plugin can have different sizes based on various factors. In AU land for instance a plugin can have multiple types of editors (and each editor could be used by multiple plugins) and consequently the size is determined by the editor itself upon opening a view for a specific plugin, it's not determined by the plugin itself. This is the most straight forward approach to be fail safe, and it doesn't involve extra work that is not necessary unless the editor is actually opened e.g. when scanning plugins.

A global preference file won't help much because each ui skin can have a different size, and each skin can vary in size even without the resize feature. In effect, each instance may have a different size based on various factors (skin, ui resize feature, or a control within the gui that resizes things, or complex stuff like "the editor extends vertically by X pixels for each open instance of plugin A, and Y pixels for each instance of plugin B").

Hence in many scenarios the editor size can not be foreseen without serious processing, possibly adding a few seconds of opening time for some hosts. The behaviour of some hosts is just a lack of imagination of what a plugin could do. A simple trick (query editor size after opening it, as 98% of hosts do) would solve the problem.

Cheers,

Urs

I understand what you're saying. You don't want to put in a brute force list of offsets based on each hosts windowing style/borders.

Would it be possible to write a function that reads the size of the background bitmap used by Zebra, excluding the contingent factors such as buttons, titlebar, and what-else-have-yous?

Or more generally - isn't it possible for you to find out if the resizing operation operation completed successfully without relying on the host at all?

[Urs]

Would it be possible to write a function that reads the size of the background bitmap used by Zebra, excluding the contingent factors such as buttons, titlebar, and what-else-have-yous?

Or more generally - isn't it possible for you to find out if the resizing operation operation completed successfully without relying on the host at all?

I don't want the first approach because it would constrain my future possibilities, e.g. if I write a host that is also a plugin or something. In such a case I would have to rewrite the method again.

The second approach is probably way to go. We're mostly talking Live here. But really huge surrounding windows like in Reaper and what not make this difficult again.

I guess the easiest way is to add preferences where users can unleash the feature or not, and possibly on a per-host basis. But this is really something more along the lines of a general improvement than a thing that specifically sucks in Zebra.

#---

On a side note, I've been checking out the old filter code. I think there are good possibilities for speed gains, making a bit of oversampling here or there a no brainer.

Urs

[kvrian1000]

I guess the easiest way is to add preferences where users can unleash the feature or not, and possibly on a per-host basis. But this is really something more along the lines of a general improvement than a thing that specifically sucks in Zebra.

Urs

Yes, please do add that preference. I have a hard time reading the font in the Zebra demo and its super annoying (dare I say, sucky), to have to resize Zebra manually.

[zvenx]

I guess the easiest way is to add preferences where users can unleash the feature or not, and possibly on a per-host basis. But this is really something more along the lines of a general improvement than a thing that specifically sucks in Zebra.

Urs

Yes, please do add that preference. I have a hard time reading the font in the Zebra demo and its super annoying (dare I say, sucky), to have to resize Zebra manually.

+1....
old age is a b____

rsp

[billstei]

+1....
old age is a b____

rsp

+1....
old age is a b____