Could not read XML data 19:85

[Skibbidip]

Hi, I've been using the sampler for a day now and I like the possibilities so far. However there's a problem because when I re-opened the project i've been working on I get this error and everything in the sampler is gone (see attachment for screenshots).

I found out the problem occurs when I select a unison parameter as a destination in the modulation section.

I could live with this as long as I know which parameters cause problems. Also, is there any way to get my sound and settings back? It's quite an important of the project.

I hope someone could help me with this. Thanks in advance.

[elcallio]

The problem is literally that a merge with the updated XSD definitions for unison modulation is missing -> validation of program data fails. I'll put up a fix later today.

[Skibbidip]

That is great to hear! Should i just re-install from the site in a few hours/tomorrow or does it not work that way?

[elcallio]

Updated now. Just download the new version and install.

[Skibbidip]

Thanks, this does seem to solve the error but there's something else going on now.

When I re-open the project all regionmodes are set to RAM and there's is no sound. When I change it back to DFD it works again.
Maybe this is just a setting somewhere but I can't seem to find it.

Do you know why that happens and what I can do to fix it?

[elcallio]

Send the project + samples.

[elcallio]

To clarify a bit: a mapping might reset to RAM mode if the sample mapped is shorter or equal to 2*DFD buffer size, because streaming such short samples is pointless. Of course, this should not really have been mapped as DFD initially either, but depending on if you did a copy content or similar, the actual source might have changed. But even if mode resets, it should definitely still sound. So source material, project + repro steps please.

[Skibbidip]

Sure I can send it over. I do however think I found out what the problem is but I don't know how to fix it.

I remade the sound and found out the sound started to disappear when messing with the start and unison start parameters.
In DFD mode the sound starts in the middle (where I want it) but in RAM mode the start is already beyond the end of the sound. Almost as if there's a delay in sound that isn't compensated in different modes.
I also checked with different samples and the same thing happens so you could probably try it yourself aswell with any (short) sample.

For some reason the start doesn't seem to go beyond the sample in DFD mode. No matter how far I push it it keeps playing a small part of the sample. video for example: https://youtu.be/puZRso3Q9A4

If it's some kind of delay issue I think there should be an option to keep the mode you made the sound in for that instance of tx16wx so you don't have to change that back everytime when opening a project.
Anyway, I'm curious to know whatsup.

[elcallio]

No, it is just that for DFD, delay is limited to ~80% of the DFD initial buffer. So your delay setting is actually much larger than you think. In general, that parameter does _not_ work properly other than in RAM mode.

[Skibbidip]

Alright, that is good to know. The downside for me is that it's a bit tricky. I'm definitely going to forget setting the mode to ram before making something. Is there a way to load samples in ram mode by default?

As for the sound I'm working on. If I put the start to 80 percent of the length of my sample in RAM mode it should sound the same as all the way up in DFD mode, right?

And is it the same percentage for the unison start parameter? Up until now I haven't found the same result in ram mode which is a bit unfortunate as it's the main bass sound of the project.

[elcallio]

Sample start is always the same. DFD buffer will be based on this.
It is the sound->delay and sound->unison delay that will work different in DFD (because you might hit the buffer limit).
No way to force-load RAM, need to change it in region list (but you can select-all and change).

Rule of thumb: If you want to play back huge samples without particular tweaks - use DFD. If you want to do sample/loop experiments or do synth emulation, use RAM.

[Skibbidip]

Thanks for the tip. I'll keep that in mind when importing samples.

As far as I know there's no sound->unison delay parameter. Only a unison start parameter. I didn't touch the sound->delay parameter. It's specifically the start and start unison parameters that are inconsistent for me.

I understand that the start of the sample is the same. The start parameter in the sounds tab is not the same in ram and dfd. You can hear/see this in the video.

The problem is, my bass sound was made in dfd mode because I didn't know it would automatically change after saving the file. Now I want to make my bass work in ram mode, but I want it to sound same of course. So what would be the position of the start parameter in ram mode when I want it to sound the same as it does now in dfd mode? Same goes for the start unison parameter.

[elcallio]

I meant unison->start.
The "start" and "delay" in the sound section are in real-time, across all samples. They are for doing subtle sound alterations, typically modulated by note-on velocity or simliar, and should be in the order of milliseconds or so.
To actually tweak a samples real _start_, use the wave editor and adjust the start marker. This is precise, and per-sample. Also works regardless of playback mode.

[Skibbidip]

Ahh okay I guess I'm just out of luck with this one. I'll try to get a similar result using the start setting in the wave editor or keep working in dfd mode for this project.

I gotta say apart from this specific thing I like the plugin a lot. The unison and filter function with modulation possibilities are very interesting to me for resampling stuff. I'm going to have to work with it some more to be able to use all funtions properly.

Thanks for the support, I appreciate it!

[elcallio]

To clarify: Sound start/delay/uni-start can be larger values, but because they are cross-sample, wall-clock time parameters they are less useful for static sample start position etc. And also not DFD-friendly (because they are not fixed values, as they are modulation targets).