Tx16wx unusable in Bitwig

[Eleventh]

Bitwig autosaves every couple of minutes. When it does, tx16wx also saves it's state, and this causes Bitwig to freeze until it's done. Can anything be done about this?

[Eleventh]

This is something that causes problems in other hosts too, but in Reaper for example you can set the plugin to "Save minimal undo states", which bypasses the issue. Makes me wonder though, what does Tx16wx do differently to other samplers regarding the saving of the state, and is it absolutely necessary?

[elcallio]

It saves the state. Which may or may not include waves being written into either the state, or the project. And in general, yes, you probably want it to store your wave data when you save project (which is what the state saving is for by design - not fancy psuedo-undo by hosts), because otherwise I am sure you would suddenly write a "TX16Wx unusable because it does not save my wave data!!!" if it did not. (Hint, you could cut back on the use of "unusable").
If you turn off "save all waves in FXB", TX will only save modified wave files though, so it should not be less noticeable. But serializing X amount of data will always take _some_ time...

Edit: Though, thinking of it, there are probably at least a few things I could do to make it a little less intrusive... So at least it was good that you reminded me of annoying host behaviour again!

[Eleventh]

Well, the fact is that it IS unusable (even with "save all waves in FXB" off). Every time Bitwig autosaves, it freezes for ~20 seconds as the instrument is saved (Salamander Piano Ogg .sfz). It does this even if I don't touch Tx16wx at all? Nothing is modified, yet it saves the files all over again at the next autosave...

[Eleventh]

Ok sorry about the "unusable", I guess multisamples with a couple hundred different samples is a special use case...

[DarkStar]

Slightly confused here ...

Since TX16Wx is a sampler instrument, its internal state is dependent on waves loaded from disk, typically many megabytes in size. Storing this whole state into the project can cause problems, as some hosts cannot handle very large state data chunks. TX16Wx will by default not store wave data that has not been modified in this memory, but instead just keep a reference to the file on disk.

Exactly when does TX16Wx modify the .wav file? The only mod that I can see that may be written back into the .wav file is the root key (or, of course, a new .wav file recorded by TX16Wx). Is there anything-else?

[elcallio]

No, that is pretty much it. Though of course modifying start/end, loops etc etc will mark the wave as modified as well. Note though that for most such modifications, the wave itself is not stored, but instead a data chunk with the modifications in it (way smaller). But it all adds up I guess...
And again, without seeing the bank eleventh has running I cannot say 100% what takes most time serializing.
I can probably make the saving less intrusive (not interrupting sound), but the time it takes will not change. So the UI will still be frozen.
Again, the concept of "let the host do undo by storing the 'content'" is nice and dandy for a synth with ~30 params or so, _OR_ for those plugins that basically just gives back a fixed-size raw memory chunk. But once you have a large number of data structures and serialize them into a versionable format, it does take some time...
I really suggest pestering Bitwig to add a switch to turn off the behaviour per plug-in, since there is only so much I can do to deal with it.
And to repeat what has been stated a gazillion times in similar threads about reaper; There is _no_ way for the plug-in to know if the state saving is "real" (saving project) or "undo" (this spurious saving).