Keygroups and Sample Loops

Hello Everyone. Let me preface this by saying I looked in the manual and searched online with no success. On,the MPC X, in the computer app, I have created a a keygroup from a VST I own using autosample. The autoloop function is useless so I had to go in and manually edit the loop points in each sample. I got them where I want them and saved the program. The problem is, when playing the keygroup, the loop points I set up are not playing back correctly but when I'm in the sample editor and press the playback pad, they sound great. Maybe I'm missing something really obvious but I'm happy to look dumb at this point. Anyone know what to do? Thanks, Adam

You have TRIM/CHOP/PROGRAM in the sample editor screen, you need to chose PROGRAM first otherwise how can the MPC knows you are editing a sample in a specific program? The same sample can be in many programs at the same time.

^What he said.

If you have a sample already assigned to a key group, editing the sample's loop points in the sample editor won't do anything in the key group. The only thing that will effect that key group is something destructive like trimming or processing the sample in some way. The key group has its own settings it takes the first time you add a sample to it. If you change it after that you have to change it IN the key group itself. Otherwise, just switch out the sample in the key group and put it back and it will grab the settings you just made in the sample editor.

Keygroups only keep the pad layer start/end if you leave 'Slice' set to 'Pad' (Program edit > Samples). Select 'All' keygroups and change this to 'Slice:All' if you want it to reflect whatever you've set up in sample edit. It shouldn't need the sample re-assigning.

You can also override the 'pad' default in Preferences > Project Default > Default Pad Slice. Set this to 'All' if you find this setting more useful (I believe 'all' used to be the default until a few firmwares back).

I usually have keygroup programs use slice: all, but I often tend to use slice:pad on drum programs these days as I find myself using sample edit less and less for simple edits.

ace_of_dub wrote:You have TRIM/CHOP/PROGRAM in the sample editor screen, you need to chose PROGRAM first otherwise how can the MPC knows you are editing a sample in a specific program? The same sample can be in many programs at the same time.

Are you talking about the bottom left in the sample editor? All I have is trim and chop. I wonder why. Running latest firmware. Thanks for the reply

'PROGRAM' is only available in sample edit if the currently selected program is a 'DRUM' program.

Are you talking about the bottom left in the sample editor? All I have is trim and chop. I wonder why. Running latest firmware. Thanks for the reply

Nooo You're in the PROGRAM EDIT Screen.

Choose SAMPLE EDIT Screen

Do I understand this correctly: in a keygroup program, it is not possible to utilize LOOP TUNE to fine-tune the loop-portion of the sample? I can even get pad loop x-fade working (for which there doesn't appear to be a user interface) by manually editing the XPM file, but how to tune the pad loop? Loop length alone is not accurate enough to tune a sustain loop. At 44100 Hz, a loop of 100 samples produces a fundamental frequency of 441 Hz, and a loop of 101 samples gives 436.6 Hz. Loop lengths are integers, a loop cannot be 100.23 samples long. To get closer to the desired fundamental frequency, the only way that I can see, if loop tuning doesn't work, is to use a longer loop with multiple fundamental wave cycles in it. For example in Kontakt you can tune the loop independently of the rest of the sample. And Akai has clearly at least considered this, because there seem to be some partial facilities for loop finetuning, I just can't get them to work. My current best-working idea is to use a longer pad loop (SliceLoop) with an x-fade.

I was able to get PAD LOOP X-FADE to work, so maybe there's some way to get pad loop tuning to work as well, by manually editing something in the XPM file. I'm interested in this, because I made a nicely working program which automatically finds good sustain loops from WAVs, and I want to use it to auto-loop keygroup programs. So I'm now looking at what would be a good way to get the loops accurately tuned.

Some investigation: -------------------------

There are parameters for both of these saved in a Keygroup XPM file. The "SliceLoop" attributes are shown as "PAD LOOP" in the user interface. But in addition to those there are "LoopStart", "LoopEnd", "LoopCrossfadeLength" and "LoopTune". For example



As you can see, for every sample in a keygroup, there is SAMPLE loop, cross-fade and Loop Tune, and SLICE loop and crossfade. But there is no SLICE LOOP TUNE. Which is a bummer. And like I said, the SliceLoopCrossFadeLength parameter does work, even though it's not shown in the user interface. Or maybe I couldn't find where it is.

I tested that the Force loads AND SAVES BACK the Loop attributes from and to an XPM file, but it doesn't seem to actually DO anything with the information.

The information that's set in the Sample Editor, is saved to an "atem" RIFF meta chunk in the actual WAV files. It's a pun, "atem" is "meta" backwards. The data in an "atem" chunk seems to be nice and indented JSON text, like so



(I wonder what "PulsePosition" does)

But the corresponding info in the XPM is empty. (and even if I manually write something in there, it doesn't seem to affect playback)

HouseWithoutMouse wrote:The information that's set in the Sample Editor, is saved to an "atem" RIFF meta chunk in the actual WAV files. It's a pun, "atem" is "meta" backwards. The data in an "atem" chunk seems to be nice and even indented JSON text, like so

Code: Select all --- MooG Bass21-052 E2 046.WAV ---
WAVE
|_fmt
|_atem
atemú{
    "version": 1,
    "value0": {
        "defaultSlice": {
            "Start": 15848,
            "End": 17480,
            "LoopStart": 15848,
            "LoopMode": 1,
            "PulsePosition": 0,
            "LoopCrossfadeLength": 372,
            "LoopCrossfadeType": 0,
            "TailLength": 0.0,
            "TailLoopPosition": 0.5
        },
        "numBars": 2,
        "Num slices": 0
    },
    "value1": {
        "version": 1,
        "note": "E",
        "scale": "Major"
    }
}
|_smpl
|_meta
|_data


Interesting. So that's why Wavelab always complains anytime I open an audio file the MPC has touched hah. You always get an error about a damaged header and Wavelab attempts to 'fix' it when opening them.

It could be something else too. IMO, applications like Wavelab should have no trouble skipping over RIFF chunks they don't understand. That's kind of the whole idea with the chunk system.

Here's my Python script for showing the RIFF chunks.




https://www.loc.gov/preservation/digita ... 0025.shtml

Chunks are identified by four-character codes and an application such as a viewer will skip chunks with codes it does not recognize. ... Applications that play or render RIFF files may ignore chunks with labels they do not recognize.

"Will ignore" or "may ignore" ... go figure. Maybe it's ok to not ignore.

I figured out something. If I set SLICE to "All" in the keygroup, then it uses the sample loop that's stored in the WAV and that's edited in the sampler. It's the defaultSlice thing stored in the atem chunk. Which is what MPC-Tutor said

And "PulsePosition" seems to be linked to the sample START position in some way.

For my sustain-loop finder, I think I'll use the pad loops, because then I don't have to edit the WAV files at all.

Bump. The lack of loop tuning is a bummer. Nobody ever needed to tune their short sustain loops to match the audio before the loop, how do you do it on the MPC or Force?

For example in Ableton's Sampler it's called Sustain Loop Detune

I just don't use the MPC for sustain looping (or any remotely complex sample editing or processing), prefer to use the computer for that kind of work, life's too short, especially when you have thousands of samples to get through.

That's actually what I'm doing here... I made a Python script which automatically finds fairly nice sustain loops. Sometimes a single-cycle loop would be ideal, but any short loop is usually a bit out of tune, unless the sampling rate and the desired output frequency happen to have a nice fractional ratio, which is practically never. My script gives the proper tuning correction for the sustain loop and it's pretty accurate, down to 0.1 cents and Ableton's tuner agrees with it. The problem is, I need to store the loop tuning correction somewhere in the XPM file, and the only place I found so far is <LoopTune>, but it doesn't seem to do anything. I'm thinking, surely it can't be like so, it feels like a fairly basic thing? The loop length in short loops is a very coarse tuning method, a loop length change of 1 sample can change the tuning by something like +-40 cents. And having the sustain loop out-of-tune with the beginning of the sample isn't good either. And if I change the tuning of the whole sample, then either the attack, or the sustain loop, or both are out of tune. :/

My goal is to take e.g. an auto-sampled keygroup program, feed it to the loop finder script, and boom, it makes an XPM file where all samples are automagically sustain-looped. I'm pretty far already, I can parse the XPM data and get sample names, I can give the WAV file name to the loop finder with some parameters like "start searching for a loop only after 100 ms after an initial attack peak" and it tells where the loop start and end points should be set. And what the sustain loop tuning correction should be... but there's nowhere to put that information.

If it's worth doing, it's worth over-doing. I figured out a ridiculous solution to the lack of sustain loop tuning. If I cannot tune the loop according to the audio, I'll tune the audio according to the loop. I resample the whole wave file so that the actual frequency content in it happens to nicely align with a frequency that can be produced with a loop of integer length. For example if the sample has A=440 Hz sampled at 44100 Hz, it cannot be reproduced with any single-cycle loop of integer length, 100 is too high and 101 is too low, 100.2273 would be optimal. So I'll resample i.e. stretch the whole thing by a factor of 1000000 / 1002273, and bingo, now I can use a sustain loop of exactly 100 samples and it's in tune, no pitch jump. A pitch tuning adjustment for the whole sample tunes it all, the start and the sustain loop. As a downside, I'll have to save copies of all the wav files, but it's OK, I can cut out the extra stuff behind the sustain loops at the same time.