By JohnClodVanDarn
Thu May 20, 2021 10:28 pm
I am brand-spanking new to the MPC One OS and I haven't been able to find any direct mention of this in the manual or the "bible" when searching but it seems to be reproducible and I'm curious if this is a feature someone smarter than me knows about or a bug:
1) Assign a short sample to the first layer of a pad in a program (around 10 seconds in length)
2) Non-destructively stretch it from the program editor. Verify that it plays as expected.
3) Assign the exact same sample to the second layer of the same pad in the same program.
4) Note that all of the pertinent warp/stretch settings displayed on the screen mirror those of the first layer but are disabled and uneditable.
5) Hit the pad; hear the first layer play back stretched and the second layer play back unmodified.
I've tried changing the trigger settings to cycle through the two samples so only one has to play at a time and the results are the same. CPU meter never goes above 5-10% for me so it doesn't seem to be running out of horsepower, but I suppose it could conceivably need more free memory than it has available to stretch them both.
My workaround is obviously going to be to flatten the pad, but I was surprised to discover this limitation. If it were intentional I would kinda expect the UI to reflect the fact that the unmodified stretch/warp values were going to be used for the second layer rather than continuing to show the custom values I entered.
1) Assign a short sample to the first layer of a pad in a program (around 10 seconds in length)
2) Non-destructively stretch it from the program editor. Verify that it plays as expected.
3) Assign the exact same sample to the second layer of the same pad in the same program.
4) Note that all of the pertinent warp/stretch settings displayed on the screen mirror those of the first layer but are disabled and uneditable.
5) Hit the pad; hear the first layer play back stretched and the second layer play back unmodified.
I've tried changing the trigger settings to cycle through the two samples so only one has to play at a time and the results are the same. CPU meter never goes above 5-10% for me so it doesn't seem to be running out of horsepower, but I suppose it could conceivably need more free memory than it has available to stretch them both.
My workaround is obviously going to be to flatten the pad, but I was surprised to discover this limitation. If it were intentional I would kinda expect the UI to reflect the fact that the unmodified stretch/warp values were going to be used for the second layer rather than continuing to show the custom values I entered.