Live 6.0.5 & 6.0.7 Sampler Zone Editor Crash

[raychicago]

Hi all !

I did a quick search on "Sampler Zone Editor" in here, but it seems like this has not been reported before.

When there is more than one sample in the sampler (in my case these were pcm wavs, not tested with (aiff, etc...) ) and the sampler plays, then muting unmuting one sample is crashing Live. On version 6.0.5 I was shown a minidump, when testing on 6.0.7 it just crashes. I tried this in a minimal example with a liveset containg one midi-track and a short clip playing in arrangement view.

Sometimes it needs frantic clicking, sometimes the first mute/unmute cycle causes this crash =) .

I hope this is not solely related to my machine... I would hate that =)

Should I provide more details, and if so, what kind of details would be helpful ?

Cheers, ray

[Amaury]

Hi,

I can't reproduce the bug. Can you send me the most possible step by step instruction to reproduce it?

Regards,
Amaury

[raychicago]

ok. I did some more testing, and yes, with any other liveset, i was unable to reproduce it. odd, i thought, so i wanted to attach the liveset which crashed, which involved a "collect and save" ... before uploading it anywhere, i tried it again et voila, works as any good oiled machine.

the waveforms which are loaded into the sampler were generated and put into the live-library. from there there were pulled into the sampler-zone editor. when i tried to mute/unmute them, while playing, live crashed, as stated above. live still displays this "not-monkey-proof" behaviour with this specific liveset.

however, when saving the liveset as a copy and doing a "collect and save" the sampler is once more "monkey proof".

i'm doing real live testing here, my live instance just hung up with the error message "Runtime error, ... R6025 - pure virtual function call", while it keeps playing.
the wavefiles are exactly a second long in 44.1kHz indexed from 0 to 44099... and are all set to continous looping, "snap" is on. the loop points are set arbitrarily.

hopefully this helps a bit more. also, with short samples the reproducing seems to be harder. or maybe it's because they are exactly 1 second long, who knows...

cheers, ray

[Amaury]

ok. I did some more testing, and yes, with any other liveset, i was unable to reproduce it. odd, i thought, so i wanted to attach the liveset which crashed, which involved a "collect and save" ... before uploading it anywhere, i tried it again et voila, works as any good oiled machine.

the waveforms which are loaded into the sampler were generated and put into the live-library. from there there were pulled into the sampler-zone editor. when i tried to mute/unmute them, while playing, live crashed, as stated above. live still displays this "not-monkey-proof" behaviour with this specific liveset.

however, when saving the liveset as a copy and doing a "collect and save" the sampler is once more "monkey proof".

i'm doing real live testing here, my live instance just hung up with the error message "Runtime error, ... R6025 - pure virtual function call", while it keeps playing.
the wavefiles are exactly a second long in 44.1kHz indexed from 0 to 44099... and are all set to continous looping, "snap" is on. the loop points are set arbitrarily.

hopefully this helps a bit more. also, with short samples the reproducing seems to be harder. or maybe it's because they are exactly 1 second long, who knows...

cheers, ray

Hi,

Somehow, even though it's good for your work, it's too bad the bug is gone. It means we don't know how to reproduce it so it is nearly impossible to fix it, if any (user error happens to all of us, including myself).

Thanks anyway, I'll keep an eye open on such an issue.

Regards,
Amaury

[raychicago]

Hi,
Somehow, even though it's good for your work, it's too bad the bug is gone. It means we don't know how to reproduce it so it is nearly impossible to fix it, if any (user error happens to all of us, including myself).

Welllll. It's not exactly gone, you know =) It's reproducible at least on my machine, using these generated waves, which are not 'directly' part of a live-project, meaning they are, for example, referenced from the library.

maybe it is a reading from the disk issue or a "timing related problem" (lists getting populated too late and such things...)
i know from experience, that these are hard to find and solve.

I'll keep an eye open on such an issue.

I'm glad you had a look on it. I will keep you posted, if I find anything that could be related. Thanks, and keep up the good work !

I will just "collect and save" more often now...

-cheers, ray

[Amaury]

Hi,
Somehow, even though it's good for your work, it's too bad the bug is gone. It means we don't know how to reproduce it so it is nearly impossible to fix it, if any (user error happens to all of us, including myself).

Welllll. It's not exactly gone, you know =) It's reproducible at least on my machine, using these generated waves, which are not 'directly' part of a live-project, meaning they are, for example, referenced from the library.

maybe it is a reading from the disk issue or a "timing related problem" (lists getting populated too late and such things...)
i know from experience, that these are hard to find and solve.

I'll keep an eye open on such an issue.

I'm glad you had a look on it. I will keep you posted, if I find anything that could be related. Thanks, and keep up the good work !

I will just "collect and save" more often now...

-cheers, ray

Hi,

Maybe you could create a simple set with 1 or 2 of these small samples, pack it and send it to me, with steps on how to get the bug? Use [email protected] in that case.

Regards,
Amaury