We did some tests today but couldn't find a problem.Totolitoto wrote:URS, any news about this one?
I'll upload another Zebra for sanity check tomorrow and add whatever scipts/icons might be missing.
- Urs
Zebra 2.6 Sanity Check
-
- u-he
- Topic Starter
- 30247 posts since 8 Aug, 2002 from Berlin
I'll upload another Zebra for sanity check tomorrow and add whatever scipts/icons might be missing.
- Urs
-
- KVRAF
- 1908 posts since 7 Jan, 2004 from Earth
You tried with Flstudio?Urs wrote:We did some tests today but couldn't find a problem.Totolitoto wrote:URS, any news about this one?
I'll upload another Zebra for sanity check tomorrow and add whatever scipts/icons might be missing.
- Urs
I can't work on my skin anymore
I'll check with the next RC
-
- u-he
- Topic Starter
- 30247 posts since 8 Aug, 2002 from Berlin
Ok, we figured the problem with FL out.
It wasn't a bug per se, it's rather one of those things where Fruity has its own special ways.
Our code is specialised in being very polite and nice. Which means that we don't necessarily do heavy lifting right on a mouse click, we do it based on a timer that's guaranteed to give us enough time to do whatever heavy task we do. Resizing GUI or switching Themes is such a heavy duty, and we politely do it on the next available slot of time that the host gives us, shortly after the mouse click, right from our timer() procedure.
The problem therein is, when Fruity realises that the gui has changed after telling it so, it calls the timer again - even though the previous call to the timer hadn't ever returned. And now, because we hadn't finished our task, and the task was still in the list of things to do during the next timer call, the timer switches the Theme again and resizes again and then Fruity realises... and so on. Deadlock.
Fixed in next beta!
- Urs
It wasn't a bug per se, it's rather one of those things where Fruity has its own special ways.
Our code is specialised in being very polite and nice. Which means that we don't necessarily do heavy lifting right on a mouse click, we do it based on a timer that's guaranteed to give us enough time to do whatever heavy task we do. Resizing GUI or switching Themes is such a heavy duty, and we politely do it on the next available slot of time that the host gives us, shortly after the mouse click, right from our timer() procedure.
The problem therein is, when Fruity realises that the gui has changed after telling it so, it calls the timer again - even though the previous call to the timer hadn't ever returned. And now, because we hadn't finished our task, and the task was still in the list of things to do during the next timer call, the timer switches the Theme again and resizes again and then Fruity realises... and so on. Deadlock.
Fixed in next beta!
- Urs
-
- KVRAF
- 1908 posts since 7 Jan, 2004 from Earth
-
- u-he
- Topic Starter
- 30247 posts since 8 Aug, 2002 from Berlin
Fruity Fix required more fixes, and now we've updated everything yet again:
http://www.kvraudio.com/forum/viewtopic ... 28#5336628
http://www.kvraudio.com/forum/viewtopic ... 28#5336628
-
- KVRist
- 128 posts since 3 Apr, 2012 from Finland
These 3 new filters in Zebra 2.6 ---- all the old patches will automatically use these new filters, the new filters are just "there" in place of old ones, or some editing has to be done?hollo wrote: The regular Zebra users got this 3 plus filters (TN and 2xMS)what you already have in ZebraHZ.
-
- KVRAF
- 24455 posts since 7 Jan, 2009 from Croatia
All the old patches continue to use what they've been using. They are just there to be used for any new patches you might want to do, or edit old ones to use the new 3 filters.