I'm using a Duo Core 64bit Win7 system with the Hosts Temper and Energy-XT on it and everytime I open the TX16Wx Edit window, there are no GUI graphics visible. When using the sampler on a Win XP 32 bit system, it's the same! What is the problem?

When you say "no gui", do you mean that you get a host default parameter window, in which case you might have simply switched off the UI feature in the host, or do you mean you get an empty grey window? The latter would indicate that something causes an exception when opening the UI. Which should of course not happen. Are there any error messages or logs from the application?

And there are no error/exception logs from the application? Without more information there is only so much I can do... I can perhaps send you a doctored version with some trace code to try to figure out whats wrong. Not sure how much that helps though.

no, there are no other things at all - gray window only. sometimes it's transparent...but yeah, nothing else. if you have that doctored version done, you can send it to henrydalcke@gmx.de. Don't hesitate

Lately I've been creating a bunch of programs with TX16wx, and I've also encountered some bugginess with the GUI, albeit in a minor way. It appears there could be a problem with how its window is refreshed after changing certain settings. Maybe this has to do with how graphic memory is handled.

To be a little more precise, what happens is that when editing a program with lots of groups, when working for a while moving around groups (such as changing their order), adding groups and/or deleting groups or their samples, the window stops refreshing to the new settings. This happens after doing continuous editing for a while (say 5 minutes or so). The problem can't be related to the memory capacity of my system, as it's a generous 8 GB, working with Studio One 32-bit on Windows 7 (64-bit), in a song file that has nothing else going on besides a track for editing the TX16wx.

When this problem occurs, I can resolve it a couple of times by simply closing the TX16wz window, then reopening it. But after a while this doesn't help either, and I have to close and reopen the song, or even relaunch Studio One.

Can't say to what extent Studio One plays a role in this minor bug (the 2.5 update made a number of VSTs unusable). But it might be related to the problems signaled in this thread.

By the way, I've come to really like editing programs in TX16wx! It definitely gives me that feel of working on old-skool samplers, such as Akai's S1000 which I used to work on for many years, but with the added benefit of editing that is way, way easier, especially thanks to the easy graphical keyboard interface. Great work elcallio!

Sounddigger wrote:Lately I've been creating a bunch of programs with TX16wx, and I've also encountered some bugginess with the GUI, albeit in a minor way. It appears there could be a problem with how its window is refreshed after changing certain settings. Maybe this has to do with how graphic memory is handled.

To be a little more precise, what happens is that when editing a program with lots of groups, when working for a while moving around groups (such as changing their order), adding groups and/or deleting groups or their samples, the window stops refreshing to the new settings. This happens after doing continuous editing for a while (say 5 minutes or so). The problem can't be related to the memory capacity of my system, as it's a generous 8 GB, working with Studio One 32-bit on Windows 7 (64-bit), in a song file that has nothing else going on besides a track for editing the TX16wx.

First off, if you are running a 32-bit DAW, those 8GB aren't gonna do you much good really. You have 2GB (or 3, somewhat depending on the app/WOW64 mode) available. Should still be enough though.

Sounddigger wrote:When this problem occurs, I can resolve it a couple of times by simply closing the TX16wz window, then reopening it. But after a while this doesn't help either, and I have to close and reopen the song, or even relaunch Studio One.

Spontaneously, I'd say you are either running into something screwing up the internal state machine in the undo system, _or_ something related to windows messages etc that makes the state machine for the group/wave lists (which are rather special in terms of rendering, to conserve memory/cpu) break down in a similar fashion. If actually opening and closing the UI makes a difference, I'd say the latter. But its weird it could happen. Just as a suggestion, what is your undo queue setting? If its fairly high, you might in fact be building up quite a footprint in editing operations. You could try lowering it.

Since I cannot reproduce the behavior you're describing (albeit only testing a 64-bit S1), I'd really need a more concise description of how to provoke the issue. Some combination of operations that makes it occur. Or if you're tech savvy, a minidump of the running process when its manifested itself.

Sounddigger wrote:Can't say to what extent Studio One plays a role in this minor bug (the 2.5 update made a number of VSTs unusable). But it might be related to the problems signaled in this thread.

By the way, I've come to really like editing programs in TX16wx! It definitely gives me that feel of working on old-skool samplers, such as Akai's S1000 which I used to work on for many years, but with the added benefit of editing that is way, way easier, especially thanks to the easy graphical keyboard interface. Great work elcallio!

elcallio wrote:First off, if you are running a 32-bit DAW, those 8GB aren't gonna do you much good really. You have 2GB (or 3, somewhat depending on the app/WOW64 mode) available. Should still be enough though.

Sure, I'm aware of that, though I thought it goes up to 4 GB, no? This is at least what the manual of Fruity Loops specifies. Anyway, figured I'd mention it. Something I believe that also seems to apply: isn't it so that the Windows system can use that extra 4 GB RAM, as far as non-DAW functionality is concerned? I've understood it does. For example, say you're running other software on the side, such as a text-editor, an internet browser, video-player, etc... the extra RAM available can be used for those, leaving the DAW free to use its designated 4(?)Gig. Isn't that how it works out?

elcallio wrote:

Sounddigger wrote:When this problem occurs, I can resolve it a couple of times by simply closing the TX16wz window, then reopening it. But after a while this doesn't help either, and I have to close and reopen the song, or even relaunch Studio One.

Spontaneously, I'd say you are either running into something screwing up the internal state machine in the undo system, _or_ something related to windows messages etc that makes the state machine for the group/wave lists (which are rather special in terms of rendering, to conserve memory/cpu) break down in a similar fashion. If actually opening and closing the UI makes a difference, I'd say the latter. But its weird it could happen. Just as a suggestion, what is your undo queue setting? If its fairly high, you might in fact be building up quite a footprint in editing operations. You could try lowering it.

Until now I've just used SO's default settings for that. Actually, in SO's manual it says:

There is no limit to how far back actions can be undone and to how far forward actions can be redone once they have been undone. (par 3.1 / p 16)

And there's no way to change this even...

Would you suggest that saving the TX16 file more often during editing could help out? (Will try this the next few sessions, anyway)

elcallio wrote:Since I cannot reproduce the behavior you're describing (albeit only testing a 64-bit S1), I'd really need a more concise description of how to provoke the issue. Some combination of operations that makes it occur. Or if you're tech savvy, a minidump of the running process when its manifested itself.

I'm not THAT technical LOL. But if you can point me to a file that gives instructions on how to do this, I might be able to get something done... who knows...

One thing I've been doing a lot that might be irregular is dragging wav files from SO's file browser window (on the right) directly into TX16, either onto the keyboard or into a sample group. This is a bit easier to do for me than using TX16's own browser window. Could that be the problem? Can that be fixed?

Take care

Last edited by Sounddigger on Sat Feb 16, 2013 8:26 pm, edited 1 time in total.