Monlith reference sample start/end screwed up

[d.healey]

Nope can't figure it out. Every time I redirect the monolith it screws up.

[Frankbeat]

IIRC, this was the reason I decided to work with plain pcm waves. It has the nice side effect of allowing you to edit the samples later (except that loop points would still be hardcoded).

[d.healey]

@Frankbeat There is no disadvantage to using the monolith compression, you should absolutely be using it to reduce disk and RAM usage.

As long as you don't delete the original wav files you can always revert the sample map to use them and make whatever changes you need in the future.

The problem I'm having is specifically related to using referenced monoliths. This is where a sample map refers to samples in the monolith of another sample map. The purpose of this is so you can reuse the same samples in different sample maps without having to create monoliths that duplicate the samples, in order to save disk space.

In other projects I haven't had a problem with this but in my current project I'm hitting this glitch.

[Christoph Hart]

@d-healey compare the monolith offset property of the original map with the referenced one, there should be a mismatch.

[d.healey]

@Christoph-Hart Just so I'm understanding correctly.

I have sample map b referencing sample map a.

Should I be comparing sample map b and a.

Or should I be comparing sample map b referenced, and sample map b unreferenced?

[Christoph Hart]

@d-healey just check the monolithoffset property for differences between the two.

The .ch1 file is just one big chunk of audio and the sample map reads into the file using this property as offset so there must went something wrong here according to your screenshots.

[d.healey]

@Christoph-Hart I need a fresh t-shirt.

During my search for the monolith offset mismatch I discovered that the sample map I was referencing didn't contain all of the samples that the other sample map uses. Maybe an error message for this scenario could be implemented?

[Christoph Hart]

Not sure how to detect an error here except for a illegal offset beyond the sample end but then it would crash.

The point of referencing another map is to use other start indexes for release trails etc. so I can‘t check for equality.

[d.healey]

@Christoph-Hart Ah ok, I'll just avoid being dumb in future :)

[d.healey]

@Christoph-Hart said in Monlith reference sample start/end screwed up:

just check the monolithoffset property for differences between the two.

Running into issues with this again. One thing I noticed is I have a sample map, which was previously saved as its own monolith, contains monolith offset values, but when I redirect the sample map to another monolith, these offsets don't change. Should they?

Is it a case that both sample maps need to have the same mapping but the properties of the zones can be different?