Friday, 20 January 2012

Small bugfix update

New update, this time fixing the trim/loop issue reported by Maker Profaze.
v 1.0.05:
  • Fixed loops not being updated on trim operation in sample editor
  • Fixed sampleeditor view not refreshing properly when playing in zoomed mode

Sunday, 1 January 2012

New Year, New Challenges...

Greetings to all, wishing you all a great musical year.
Just a small update on what I am doing, for those that might care; Since december I've been evaluating solutions for the UI of TX16Wx v2.0. As I've stated earlier, I'd like to make the UI much more intuitive and resizable amongst other things. My requirements:
  • STL compliant
  • Unicode
  • Small footprint
  • Plugin friendly
  • Acceptable license (no GPL!)
At first I looked at QT. It's a very complete toolset, somewhat STL compliant and the LGPL is acceptable. Its somewhat plugin unfriendly though. But lets try it, I said. So I built a toolchain and forked the sources to enable building a QT based plugin completely from source (I don't like using libraries because of the skew differences it implies). However, as much as I tweaked the toolchain I could not make a "Hello World" plugin smaller that 11Mb (32 bit!). OMG. At that point I felt that the trolls of tech would not troll me further. QT was out.

I also evaluated wxWidgets. Great license, unicode no problem. Plugin behaviour, meh... STL, nah...
Sorry to all the talented wxWidget devs and users, but for me at least wx came of as clunky at best for VST instruments. Moving on.

I toyed with the idea of an all-native UI. I actually like WTL pretty much, having built the software for my first media player using it in 2002. Also, as it is prettly much pure compiler time polymorphics it really appeals to me. However, WTL is also a little so-so when used from a plugin (handed a HWND from above), and Windows in general is a bit of a bitch to control some aspects of the UI look (hello scrollbars!)
In the end I felt that doing a lot of work to build custom drawing functions for everything, then eventually having to do it all again if I should ever do a Mac port, was a bad time investment.

So, as the year drew to an end I found myself full circle, at the point of the road I had originally considered, but did not really want to venture down... (cue dramatic music)

Forking VSTGUI 4. I do like this framework for its relative simplicity and small size. However, aside from that it fulfills rather few of my above requirements. Except for a nice BSD license. Thus the fork.
So, I've turned the code inside out, making the library Unicode, tearing out most of the (imho) unneccesary stuff and in general cleaned up the code to fit with my rather tight-assed code criteria. Right now I am adding support for proper layout manager based UI design.

One thing that really bugs me though is having to support both GDI+ and Direct2D. D2D, as you might know is Microsofts new, (possibly) hardware accelerated, API for 2D graphics. In Vista & W7 GDI+ is pretty much purely CPU based (except for blits), making any app that wants reasonably fast UI Gfx in modern Windows forces to go down the D2D way. But also forcing the app to have two different UI draw paths if you want to still support XP.

Oi, wey. And me who does not really like runtime polymorphism. It has really made me consider dropping XP support. How many of you, my trusty few users, are actually stuck on XP? And for how long? Oh, if I could only have one late christmas present this year, it would be knowing that everyone has dropped XP... :-P

So, after all these ramblings, what's the conclusion though? Well, I'm spending as much time as I can working infrastructure and future enhancements to TX16Wx, and I'm reading all your suggestions and wishes. We'll see how much I manage to finish before I have to do actual paid (boring) work again, and everything will happen much slower. 

As before, keep any suggestions coming, especially thoughts on how to make the UI more intuitive.