Multi-mic merge unequal length issue

[d.healey]

@LightandSound said in Multi-mic merge unequal length issue:

Just came up against this issue without using velocity spread - so I don't think it's specifically that.

Are your samples definitely the same length?

[LightandSound]

@d-healey to the sample yeah

[d.healey]

Did you convert them to monoliths before you tried to merge?

[LightandSound]

@d-healey if I come up against it again I'll update here

[LightandSound]

@d-healey Issue was due to velocity ranges of 1 not being permitted and I missed it. Implemented a quick fix.

[d.healey]

@LightandSound said in Multi-mic merge unequal length issue:

@d-healey Issue was due to velocity ranges of 1 not being permitted

They are in my build :) although I haven't tested with multi-mic samples.

[LightandSound]

@d-healey I'll test out your build - though looking at the commit in your build it changes the sampler to allow it, but not the import method unless that was in an earlier commit - since FileNamePartComponent takes the value for the high velocity and adds + 1 (when importing at fixed velocity that is)

[d.healey]

@LightandSound Yeah I didn't fiddle with the import method at all. At the time I'd already imported my samples and then decided I wanted them on a single velocity.

[LightandSound]

@d-healey I've got about 13,000 samples to import to this one sampler so I'm definitely not doing this manually xD

[bendurso]

Is there a way to ignore the length of the samples when using the Multi mic function? I have 1800 samples with 5 velocities and many of them have differences of 2 or 3 points.

[Dan Korneff]

@bendurso I don't think so.

[d.healey]

@bendurso No they all must be the same. You can probably pad them with silence to the same length using Sox and soxi. This might be something chatgpt can help with, I've found it quite useful for simple scripts.