Running in REAPER 64 bit on Windows 11.
So when I set the Dest to be Start and amount to anything and try to modulate it, it does absolutely nothing. Not sure what's going wrong here as I'm sure I did it correctly. (Example is set Source to modwheel, set Dest to Start, and set amount to 1minute)
Second issue is that when you set anything to Dest pitch then do it too hard it causes TX16Wx to just stop making sound. I've done this with Random set to 4800ct and also with the modwheel set to... idk what since for some reason the range was still displaying in time (I guess that's another bug) because of what was previously set as Dest. The volume indicator at the top is just frozen but you can still interact with the plugin. It doesn't always break like this as sometimes it just causes my entire DAW to freeze all at once.
Please let me know if you need any more info and how I can provide it. I checked the logs tab when it stops playing sound and nothing appears...
[Bug] [3.6.0h 6957.1072] Broken Start modulation and sound engine crash on extreme pitch modulation
-
- KVRAF
- 2400 posts since 27 May, 2005 from Stockholm
Actually, neither are bugs. You are mishandling DFD playback.
If you RTM, you will see that "start" is very limited in effect on a DFD wave. This because it is bound by DFD initial buffer. Anything else would cause unacceptable latencies. If you want to use excessive start values, turn the sample(s) to RAM mode.
The second case is not actually hanging, you have just provoked a very CPU intensive loop, that will eventually finish. The problem is that if you transpose something too much (4800 is not a problem, but I am guessing you have shift/transpose + extreme root diffs here as well - I need to provoke this), you end up with a sample stride that is larger than the DFD buffers. I.e. you need several round trips between disk IO thread and sound processing thread (which your DAW owns, and why it apparently stopped) just to produce a sample. This will eventually finish, but it will not be quick. Especially not if you have a sample with a short loop.
And no, it is not easy to properly detect, and even then, what is the correct course of action? Maybe just kill the notes...
And yes, it would be technically possible to optimize more for this case and make it a few orders of magnitude faster, but that would mess with rather nice code and only cover _one_ special case, quickly outdone by the general one. So not (imho) worth it.
Just as with the previous issue, turn the sample to RAM mode, and you can do any excess with transposition/pitch.
If you RTM, you will see that "start" is very limited in effect on a DFD wave. This because it is bound by DFD initial buffer. Anything else would cause unacceptable latencies. If you want to use excessive start values, turn the sample(s) to RAM mode.
The second case is not actually hanging, you have just provoked a very CPU intensive loop, that will eventually finish. The problem is that if you transpose something too much (4800 is not a problem, but I am guessing you have shift/transpose + extreme root diffs here as well - I need to provoke this), you end up with a sample stride that is larger than the DFD buffers. I.e. you need several round trips between disk IO thread and sound processing thread (which your DAW owns, and why it apparently stopped) just to produce a sample. This will eventually finish, but it will not be quick. Especially not if you have a sample with a short loop.
And no, it is not easy to properly detect, and even then, what is the correct course of action? Maybe just kill the notes...
And yes, it would be technically possible to optimize more for this case and make it a few orders of magnitude faster, but that would mess with rather nice code and only cover _one_ special case, quickly outdone by the general one. So not (imho) worth it.
Just as with the previous issue, turn the sample to RAM mode, and you can do any excess with transposition/pitch.
TX16Wx Software Sampler:
http://www.tx16wx.com/
http://www.tx16wx.com/
-
- KVRAF
- 2400 posts since 27 May, 2005 from Stockholm
I might add a detector that simply kills pathological voices like this. Will at least prevent CPU hogging/perceived locks.
TX16Wx Software Sampler:
http://www.tx16wx.com/
http://www.tx16wx.com/
-
- KVRAF
- 2400 posts since 27 May, 2005 from Stockholm
See new build for automatic kill of pathological voice playback.
TX16Wx Software Sampler:
http://www.tx16wx.com/
http://www.tx16wx.com/
