TX16Wx occasionally not playing samples

Official support for: tx16wx.com
Post Reply New Topic
RELATED
PRODUCTS

Post

I've got an external sequencer sending midi to the pc through a usb midi interface. Cantabile is my VST host. In Cantabile, I watch the midi events come in using midi monitor. Everything looks perfect and works great most of the time. But sometimes, even though the events come in as usual, the samples assigned to those notes do not play. Any ideas? The notes happen once every 4 to 8 bars, they trigger segments of the song for a given track. I noticed that my physical keyboard (arturia keylab61) doubles up the events (2 note-on and 4 note-off). So I mimiced that behavior with the sequencer, which worked, and seemed to get a bit better, but still sometimes TX does not play the sample. Any ideas appreciated.

Post

I would suggest looking at whether you have overlapping MIDI noteon/off:s in an event list in the sequencer. What you are describing sounds like you are getting events that kill/cancel each other.
TX16Wx Software Sampler:
http://www.tx16wx.com/

Post

I reproduced the problem and captured a screen video. Any help appreciated bigtime!

https://www.youtube.com/watch?v=2YstKWVKT2M

this is also in the description of the video....

Setup: Cantabile is the VST host.

Could not find a midi log/monitor in TXW16x so used Cantabiles.

Custom Java program generates midi events to trigger samples. About every 12 seconds, a note-on event is sent, then one second later the note off event.

Note that in addition to the cantabile midi monitor screen showing the events, you can also visually see the keys depressing in the TX16Wx window.

Midi event number 4 fails to play, as you can here. This takes place at about 28 seconds in.

The key is F2. Later in event number 12, you can hear that F2 does have a valid sample loaded.

Post

Send the program + samples + cantible project. I'll try to repro it.
TX16Wx Software Sampler:
http://www.tx16wx.com/

Post

The zip file was too large to upload to the forum, so here's a link...

http://jayhurley.com/JHTX16WxTest.zip

zip contains a netbeans project with one class that sends the events.

I used LoopMIDI to set up a virtual cable to route the java midi to cantabile, using the default name "loopMIDI Port". If you have that, you won't have to build the java source.

run.bat simply runs the java program.

folder cantabile has the samples, cantabile project, txperf, txprog files.

In minimal form, without all the other plugins, the problem was more difficult to reproduce. On one machine's built in Realtek audio device, which was the one that did reproduce the problem yesterday (used in the video), I did not see it happen today. However, I switched to a usb audio device (Polycom Communicator), and it repro'd just fine.

The problem happens regularly on my live rig which uses a Steinberg MR816 firewire interface which has always seemed to be high quality. (so, I don't think it's just a crappy usb audio issue).

There is significant cpu load on the live rig.

Also sometimes I mess with process priorities, usually making cantabile higher priority, in order to improve latency and crackle.

OK mega thanks as usual, let me know if there is any other test I can run, gather log files, etc.

Post

maybe this will help...

within a setup where the problem happens regularly (full song with many plugins, Polycomm Communicator usb interface), I changed the delay (in the java test program) between note off and the subsequent note on, and I am not seeing the problem.

Could it be relevant that it seems to only happen when I trigger a sample exactly as the previous sample is finishing? If I hit the new sample a second before the previous ends, or a second after it ends, all the events play. just food for thought.

Post

The wav files and txprog file for this are generated automatically, and probably need to be brought up to the 3.0 standard. But I extended each sample wav file by one second (44100 samples) of zeros, and changed tx:end to the new, longer length. This made it so that every sample that is triggered cuts off the previously running sample, and now the problem has vanished even in the full live setup.

Let me know if there is any other information that would be helpful, but for now I have a workaround and am happy!

Post

Ok, problem found. Seems your little setup managed something rather unlikely; causing samples to end while their playing voice was being stolen (faded out), right at the end of a processing block. This caused the re-trigger mechanism to fail -> next note not triggered.

Fixed in next build.
TX16Wx Software Sampler:
http://www.tx16wx.com/

Post

Indeed it's probably unique, a java program slices up a larger wave file according to a json song/sections configuration and then builds the txprog file. Thanks for digging in to it, I've invested time integrating TX16Wx into the rest of the system and didn't want to have to start fresh with something else, so bigtime thanks!

Post

Mega appreciate the quick fix last year. Now I've rebuilt my system, same old txprog files etc., and now it's playing every other sample. The sequencer, as before, is triggering the midi noteOn events, on coming just after the previous finishes. Any chance the latest version has introduced a similar problem to what we had before? I tried going back to the legacy builds but that's even older than what worked previously. Any help/questions appreciated, thanks! Jay

Post

No, it is not a regression as such, it is more of a different corner case, perhaps being exposed due to a different fix, for musical mono instruments.

Fwiw, I could only repro the behaviour by changing buffer sizes in the DAW while playing.

But:
Your program uses mono mode to get voice stealing to kill the previous (oneshot) voice in the pattern. However, mono mode tries to match wave phase when triggering a new sample, to make mono instruments to more behave like a normal oscillator, i.e. essentially bypass an attack phase.
In this case however, since you are triggering loops, this is _not_ what you want. So in truth, mono is not the mechanism you really want. Choke group would be more suitable.
Otoh, your samples are in oneshot mode, which should really be a clear indicator that we are _not_ trying to be a melodic instrument, so I think a fair compromise would be to always reset phase and do full triggering in this case (as well as trigger on release).
It might be an idea to also always force a full trigger and phase reset if we don't have a loop in the triggered sample, since trying to start mid-sample in the case of a non-looped sample also might be silly. Need to think on that a bit.
TX16Wx Software Sampler:
http://www.tx16wx.com/

Post

I've updated builds with a version that always fully triggers oneshots/release samples, even in mono.
TX16Wx Software Sampler:
http://www.tx16wx.com/

Post

I tried adding a couple seconds worth of samples to all my wav files thinking that might make it easier to cut to the next sample cleanly, but no dice. On the website, in beta versions, I see the latest date is November 2019. Where is the latest that has the full triggering of oneshots/releases even in mono? I got 3.2.2 beta x64 from the website...

https://www.tx16wx.com/beta-builds/

and my machine says a newer version is already installed. checking my install, about, I have 3.3.0h 5511.1072

I think I have an older version that used to work with my funky setup, I'll give that a try, before I bug you...

OK I uninstalled tx16wx (using revouninstaller) and then re-installed using an old copy and now I'm back in action. Let me know if I can do any tests to help, but at the moment everything is great and the about says...

TX16Wx 3.2.2beta 5452.990

Post

The betas are old. Newest is 3.3.0i, non-beta.
TX16Wx Software Sampler:
http://www.tx16wx.com/

Post

ok I downloaded the latest 3.3.0i and it is working perfectly with zero workarounds. I absolutely appreciate your help... TX16Wx is playing a big role in our production.

Post Reply

Return to “CWITEC”