Thursday, 27 June 2013

Version 2.2.2 - features and fixes galore

Hello all.
New week, new version, that is the way we do thing, no?
This build contains a number of fixes as well as some neat features suggested by people at the forum.
One pretty neat feature is the waveform overlay in the sample editor. Basically, when active, it will overlay the loop start with wave data from the loop end and vice versa. This can help quite a bit when trying to find that perfect loop point. 

As you might have read in a previous blog entry however, I found what I think is a quite serious bug when trying to use the XCode 4.6 C++11 toolset with the OSX 10.7 SDK, so version support for Mac has been set to 10.8 only. Sorry about that.

Version 2.2.2 (2013-06-27)
  • Added loop point overlay in sample editor for easier loop edit
  • Added selectable MIDI velocity curves
  • Added scrollbar arrows for easier scrolling
  • Mono/legato mode now gives trigger priority to held notes when sustenuto is on
  • Mono/legato mode now always re-triggers the last held note on note-off
  • Mono/legato mode re-trigger now respects keyboard switching properly
  • Mono/legato mode can now be forced to always re-trigger waveform/modulators by using choke groups.
  • OSX support now reduced to 10.8 due to exception linkage bug in apple sdk
  • OSX version now handles finder aliases in browser
  • Fixed poly limit not working properly
  • Fixed loading of SF2 files with illegal names inside
  • Fixed dB display in sample editor not drawn correctly
Downloads as usual from

Happy sampling

Monday, 24 June 2013

Clap & Clang

Note: Much of this post uses terms and concepts from C++ programming and ABI implementation. If you don't know about things like that, just nod, smile and try to take in the conclusion at the end. 

So I had a bug report from a Mac user. He tried to load a slightly broken AIFF file in Logic Audio 9, something that should normally have led to a little message box saying "Could not load file", and nothing more. Instead however, the whole application crashed, without so much as an apology.
He sent me the file, and I fired up AU lab and loaded it into the TX. As I expected, I got the error message I knew should be there. So what is going on?
Firing up Logic Audio, I could indeed reproduce the behaviour he described; As a matter of fact, even the trusty Reaper exhibited the same pattern. Some debugging showed that while the appropriate exception was indeed thrown, the catch clause did not take at all. In these two hosts. But they did in AU Lab. Oy wei...
So, some more debugging, and stepping through the disassembly of the exception handling framework for C++ compiled against libc++ in OSX, which is libcxxabi. Now, the exception is thrown properly, and the stack unwinding happens as it should, using libunwind. But the type matching breaks and fails to recognize that std::runtime_error is a subtype of std::exception. For this unfamiliar with how this is done in exception handling, basically an application or library exports a type table which identifies exported types, in this case the table comes from libc++. The exception handling will use soft type analysis to determine if types are related and compatible, which in turn means that to be able to handle exceptions across DLL boundaries for example, you must make sure that you both agree on the types you are exchanging (i.e. link to the same C++ runtime). But here is the funny thing; In my case, the exception handling is not across DLL boundaries, but inside a single plug-in library. And still, the type handling breaks when the plug-in is loaded in certain hosts?
I ran a number of different compiles to ensure that symbol visibility was not broken at my end, all symbols required for exception handling properly pointed out etc. No difference. I also made sure to test the behaviour on a much smaller example, the Apple "FilterDemo" sample AU plug-in.

This is where I found the culprit: OSX toolset 10.7.

I seems that a plug-in compiled with the XCode 4.6 Clang compiler, C++11 and libc++ while linking against the OSX 10.7 system headers will have broken exception handling when loaded in some applications. My guess is that something in these headers contain declarations that are not fully llvm compatible and causes a conflict in the somewhat fragile system that is the dynamic type handling in C++ exceptions when certain other compatibility libraries are loaded. And this is pretty much where I will stop my debugging of this, because it is exhausting.

And now for the conclusion:
The bottom line is; There is what I would categorise as a bug in the c++11 toolchain when targeting OSX 10.7 (unless this is explicitly unsupported, though I did not find any docs to that fact), so from the next build TX16Wx will only support OSX 10.8 and above. It might still work on a 10.7 machine, since I am not making use of any particular 10.8 features, but given that this is Apple, I would not hold my hopes up. I'm sorry for those on 10.7 eager to use TX16Wx, but since I cannot find any other way to provide a stable functioning plug-in this is how it will be.

New service release will be out in a few days.
Happy sampling

Edit: So, it seems that while the above is correct, there is a relatively simple solution, namely usign the 10.8 SDK but set targeted version 10.7. This is documented, though with a slightly pouty face I'd still like to point out that the documentation in question is not very close to the settings themselfes. So, at least partially this seems to have been a little bit of SBS on my part. Though, seriously, its still quite a weird thing to happen. Anyhow, the good news here is that there will be a 10.7 version of TX16Wx after all.

Thursday, 20 June 2013

2.2.1 - New version, some bugfixes

Hello all.

Perhaps no one was truly surprised that version 2.2.0 had a few issues that the beta testing group did not stumble upon, but you, my lovely general audience would quickly find. Alas, red-faced by embarrassment, I have to bite the sour apple (as we say in Sweden) and provide you with a quick bug-fix update

Version 2.2.1
  • Fixed linkage problem on XP
  • Fixed hanging issue on some Windows systems
  • Fixed drawing issue on some Windows systems
  • Fixed AU naming issue on OSX
  • Fixed AEG/Time modulation affecting attack
  • Fixed crash saving settings
Download from
I suggest you update as soon as possible.
Happy sampling

Monday, 17 June 2013

TX16Wx 2.2.0 for Windows and MacOSX is now available

Greetings all.
Finally, after many months of work, TX16Wx 2.2.0 is now released, adding long-awaited support for MacOSX. This release took longer than anticipated, mainly because I upped my ambitions somewhat, thus this is not simply a port, but a full rewrite of the underlying framework supporting the plug-in. TX16Wx is now running on a new cross-platform and plug-in format toolkit, with much of its insides now in shared libraries. This of course in anticipation of the new plug-ins that CWITEC will build and release during the rest of the year.

The MacOSX plug-in is available as a 32/64 bit AUi universal binary and a 64-bit VSTi. The user interface requires a Cocoa capable host.

Version 2.2.0:
  • Added Apple OSX support
  • Added Audio unit version
  • Added polyphony limit
  • Added matrix row/column distribute command
  • Added skinning support
  • Fixed issue with effects being shared between copied performances
  • Fixed automation load/save issue
  • Improved matrix editor snapping
 Enjoy, and happy sampling.

Friday, 7 June 2013

Its almost time...

Hello all. Just a few updates;
TX16Wx 2.2 will be released next week, the biggest news being MacOSX support as well as user-definable skinning. The final beta round is out now, and it looks pretty good.
However, due to all the work that has gone into the TX and the tool sets, the TX16Wx Pro license price will be increased to €29.99 (non-commercial) / €89.99 (commercial license) on release. Still an unbeatable value for the money.

To wet the appetite, here is a sample of the new demo skin, "akai":

This release is a huge refactoring and redesign of much of the innards of the plug-in, both making the sampler itself a little more clean and stable, but also to make way for some new, upcoming products.

CWITEC will be releasing a Rompler/Workstation plug-in this fall, based on the same toolset that makes TX16Wx so great. No details yet, but it will feature a more advanced synth engine than you are probably used to, as well as some neat performance tools. Stay tuned for more info as the work progresses.

Happy sampling.