TX16Wx 3.2.2 beta available

[elcallio]

I had an afternoon to kill, so I cooked up some wacky new features for you all to try out:

First off, since there was an animated discussion on CPU usage, massive polyphony and multi-core processing (I still think it is somewhat irresponsible, but), the latest build adds both multi-core processing and variable max polyphony to TX16Wx Pro.

You can now assign 1-<num cores> render threads and this will divide voice processing across available processors, possibly confusing both your DAW and cat.
You can also set max num voices to 128, 256 etc up to 4096.

One note though: The voice distribution is (currently) rather simple in that it just divides max voices in to X spans, and any voices used in that span renders on respective thread. Thus setting max poly to high might actually be counter productive (fewer threads will process the rendering).

One neat, weird goody for users of the free version as well: Built-in oscillators. There are now a number of built-in oscillators in addition to samples and matrices. You can assign these to a region as you'd normally set a wave, and combine and shape as you see fit. There is even a new modulatable PWM setting in sound parameters. You can build wholly synthesized sounds or combine samples and oscillators for that extra fat pad or whatnot. And you didn't think I had more kitchen sinks to throw into this code, huh?

Note that these are all beta features. Thay are tested, but not extensively. Use at your own peril.

So to summarize:
TX16Wx 3.2.2 beta

• Added built-in oscillator support
• Added multi-core processing (TX Pro)
• Added variable (128-4096) max voice setting (TX Pro)

Update 2019-11-28:

• Improved oscillators
• More even spread of voice distribution across CPU:s when using multi processing
• Increased slot polyphony max to match global voice count
• Added MacOS Catalina notarization

Update 2019-12-02:

• Fixed voices dropped with multi core processing
• Improved streaming throughput somewhat
• Improved SFZ import

Update 2019-12-03:

• Fixed nag screen bug
• Fixed oneshot sample with loop issue in streamer

Update 2019-12-05:

• Improved restore of zoomed editors when closing and re-opening UI.
• Improved single-key import modified to ignore root and loops
• Fixed restoring file browser when last used dir was in sound font

Downloads in the beta section of the web site (www.tx16wx.com).
Happy sampling.

[EvilDragon]

Will try to take it for a spin next week.

By the way, Calle. How complicated would it be to add a wider variant of the theme, so that the Sound panel wouldn't have to be scrolled horizontally at all? There's 1920x1080 variant, but that's a bit much. Some middle ground would work, 1440 px seems like it would take the whole width of the Sound panel nicely.

[EvilDragon]

Hmmm, choosing OSC: Sine sounds like two sines are being played (one normal and one an octave up), and OSC: Triangle sounds like sawtooth. Half and full rectified sine sound the same, and stairs sounds the same as square...


PW parameter should be realtime tweakable, not just via modulation. Also (atomic nitpick alert!) since PWM is an acronym, the mod matrix destination menu should also state PWM, not Pwm


Wait... filter parameters are still not realtime tweakable, they require a new note to be pressed to hear the changes? EDIT: seems they refresh on mouse up... this is unlike any other virtual sampler I used (or synth plugin for that matter)


Slightly sadpanda that PW doesn't do anything to non-pulse waveforms. It could make some interesting things for others, for example for triangle it could wrap it around (see JP-8000), for sawtooth it could go from single to double saw, for triangle it could modulate the slope so that it goes from ramp to triangle to saw, for sines it could skew the sine lobes...


BTW regarding max polyphony, I didn't think of this as a global parameter in settings... it should just be increased per instrument, if possible? We're still limited to 128 voices per instrument. That's the limit I suggested should be increased. Unless, of course, there are reasons not to.


There's something weird goiung on with "Number of processing threads" UI widget. It only goes through two values over here: 1 and 8. Shouldn't this be a dropdown menu? (It doesn't appear as a dropdown menu over here.)

[elcallio]

Hmmm, choosing OSC: Sine sounds like two sines are being played (one normal and one an octave up), and OSC: Triangle sounds like sawtooth. Half and full rectified sine sound the same, and stairs sounds the same as square...

SIN: Oops. Bug in lookup function. Should be correct now. And this also fixes the rectified versions.
Triangle is actually PW:ed, so PW == 0 is a "backwards leaning" saw, .5 == triangle and PW=1 -> forwards leaning saw.
Stairs is also PW dependent. Adjust it up down (and look in your oscilloscope).

PW parameter should be realtime tweakable, not just via modulation. Also (atomic nitpick alert!) since PWM is an acronym, the mod matrix destination menu should also state PWM, not Pwm

Wait... filter parameters are still not realtime tweakable, they require a new note to be pressed to hear the changes? EDIT: seems they refresh on mouse up... this is unlike any other virtual sampler I used (or synth plugin for that matter)

Big oops. A regression in the code to quicken the CPU load (minimize the amount of params read+set each processing block). Should be fixed in new build.

Slightly sadpanda that PW doesn't do anything to non-pulse waveforms. It could make some interesting things for others, for example for triangle it could wrap it around (see JP-8000), for sawtooth it could go from single to double saw, for triangle it could modulate the slope so that it goes from ramp to triangle to saw, for sines it could skew the sine lobes...

It mostly does. You are not PW:ing correctly.

BTW regarding max polyphony, I didn't think of this as a global parameter in settings... it should just be increased per instrument, if possible? We're still limited to 128 voices per instrument. That's the limit I suggested should be increased. Unless, of course, there are reasons not to.

Do you mean slot polyphony? It is not limited to 128. When set to 0 it is unlimited. It is indeed limited to 128 iff you actually use it, but I think it is a reasonable limit, no? Can maybe increase it, but it gets a little messy...

There's something weird goiung on with "Number of processing threads" UI widget. It only goes through two values over here: 1 and 8. Shouldn't this be a dropdown menu? (It doesn't appear as a dropdown menu over here.)

No, it is a text field. But you are right, a dropdown is better. Changed.

I can't put up a new built tonight, because my build server is being difficult. But I'll try to get it done by tomorrow morning.

[elcallio]

Builds updated.

[EvilDragon]

Do you mean slot polyphony? It is not limited to 128. When set to 0 it is unlimited. It is indeed limited to 128 iff you actually use it, but I think it is a reasonable limit, no? Can maybe increase it, but it gets a little messy...

Yeah I meant slot polyphony. I really don't think there's any need for a global max polyphony parameter, rather slot polyphony maximum should be increased (using the "unlimited" option might not be what is always wanted). I'd say 1024 is a reasonable maximum

[sinkmusic]

Builds updated.

... The 322 (from 24th nov) or the 321c (from 25th nov) ?

[elcallio]

Both.

[sinkmusic]

thanks

[SDG]

Thnaks for the new features, Calle!

Two things to motice :

- Taking your beloved Salamander piano as a test instrument again (just because of its demands on tx16´s CPU usage, and given the fact that it plays with much less strain on Sforzando), I have to say that setting the cores to 4 - the maximum in my case -, I don´t see any significant improvement in its performance within Reaper, even after restarting TX16wx with the same setting.

- If I click on the "Max voices" box, nothing happens.

Being the first iteration of these features, I think it is expected that they´ll need some polish. Whatever I can contribute, just ask.

Greets!

[EvilDragon]

It's because the way Calle did it doesn't rotate every consecutive voice across the max cores you set up, it divides max poly number (apparently NOT the slot polyphony number) with number of threads and then every thread takes care of its block of voices.

I also can't say I'm really noticing large strides in efficiency here due to this implementation. I'd have expected every consecutive voice rotating across available cores (set by the preference). This means if you have max poly set to, say, 256, and your instrument's slot polyphony is 64, and you have max threads set to 4, that one instrument will still occupy just a single thread, instead of spreading its voices across cores.

[elcallio]

There is a reason to divide voices into blocks. Using extra threads adds a quite significant overhead (signal, sync and down mixing of end results). The main render thread is quite capable of handling up to, say, 64 or more voices without breaking a sweat. And remember, your DAW will also do multi-processing, so taxing other cores should be done sparingly. Likewise, if you have a second track with a different synth, chances are it will process on a different render thread. etc. etc.
In any case, if "every other voice" was placed in different threads, you would need all the overhead + mixing etc for each process call. Not to mention, you would need to run all threads once you reach active poly >= <num threads> (or some multiple thereof).

This would significantly worsen sane, reasonable poly, usage.

As for measurable performance, I took both the dreaded (and awful) salamander, as well as simple samples + long release and did stress tests on it using a 256/512 max voice settings, and I got very good throughput (as in low double digit cpu load per core), basically maxing out num playing voices. DFD.

Also, slot poly should have zero to do with core distribution or anything. TX is a multi timbral instrument (with all the problem that brings), and voices are a global resource. Slot poly is otoh a great tool to force sane poly counts for an instrument (a good instrument, not one made by "modern" means with 90% long silence samples). Load a good pad, set poly to 4*<num layers>*2 and play some nice chords, and enjoy the feeling of 80:s voice stealing, the way synths were meant to be played.
(Extra rant at no extra charge).

[EvilDragon]

Load a good pad, set poly to 4*<num layers>*2 and play some nice chords, and enjoy the feeling of 80:s voice stealing, the way synths were meant to be played.
(Extra rant at no extra charge).

This is exactly why we have modern samplers with larger voice counts, to NOT re-live the 80s over and over again. (Says the man born right smack in the middle of 80s.)

[elcallio]

Then you didn't really live it.

But seriously, less is more. It really is.
Regarding voice distribution, I am thinking of making multiple ranges per thread so distribution starts earlier for large voice counts, i.e. thread 1 processes voice 1-16, then 128-144 etc.

[EvilDragon]

Then you didn't really live it.

True, but I love a helluva lot of music from the 80s. Just don't wanna live with the same limitations