Sampler issues latest build

[Dan Korneff]

@Christoph-Hart That's probably why my Mac doesn't crash when making monoliths... It should be noted that the intel Mac does get the same "file is corrupt" error in Console.

When I do a test with a bunch of hits, such as a drum roll, it can use up to 100 voices. I've haven't seen it get above 200 with a full multi mic drum kit going.

[Christoph Hart]

Hmm, but the example screenshots you showed are just playing a few voices and still drop out, so it can't be a performance issue actually.

How many mic channels are you using? Ah, and does changing the preload size to -1 fix the overlap not being retriggered?

[Dan Korneff]

@Christoph-Hart said in Sampler issues latest build:

How many mic channels are you using?

This example has 4 mic positions.

does changing the preload size to -1 fix the overlap not being retriggered?

HOLY CRAP! It does!

[Christoph Hart]

Alright, then we just know that something is funky with your streaming thread. Getting close...

[Dan Korneff]

@Christoph-Hart Maybe I spoke too soon. It worked on one quick test, but now it seems to be random if it triggers with overlap

[Dan Korneff]

@Christoph-Hart After looking into this further, I think it comes down to basic NoteOn / NoteOff commands.

In this first pic, I have 4 overlapping notes. Only 3 of them are triggered.

If I arrange the midi to display where the overlaps occur, I can see that the sampler wont trigger a 2nd midi note (of the same note) without first receiving a NoteOff command.

[Dan Korneff]

It's actually more apparent when done with the Sine Generator using the same midi.

[Dan Korneff]

Looks like this is just normal behavior of midi in general. I guess it's up to the designer on how to deal with this?

[Cyberdyne387]

@Christoph-Hart said in Sampler issues latest build:

FYI, that's the code that handles samplerates:

if (isOldMonolith)
{
    return 44100.0; // doesn't matter anyway (the sample rate is stored externally)
}
else
{
    const static double sampleRates[4] = { 44100.0, 48000.0, 88200.0, 96000.0 };
    const uint8 srIndex = (sampleDataByte & 0xC0) >> 6;
    return sampleRates[srIndex];
}

Now it also makes sense why @staiff is struggling with his 27,4kHz sounds :)

Thanks for this notice. I too have needed to repitch my own samples after compression due to unusual sample rates (frequent ones for me being 32 and 50 kHz).

[d.healey]

Have you converted your samples to HLAC monoliths?