Question about keygroups

Unfortunately thats one of the Limitations of the Hardware Bruh. For Now, All we can do is create a Workaround.

For Me...when tryin to create your situation, I'll First figure out what Note Range that i want to Pitch Shift, then create it in 16 Levels, with the Sample Warped. Takes me bout 10 secs

I get More Creative when i cant do what Most Software DAWs can do. It can be done tho

ChildOfTheCornDog wrote:Just wanna be able to take single sample and use as playable poly Instruments or loops where pitched samples keep their original length across wider range than 16 levels....

If you are willing to spend a little bit of time initially setting it up, you could set up a DRUM program template with the pads pre-tuned and then load this template each time you need a 'warped' instrument. There's a +/- 36 tuning max, so 72 pads tuned chromatically. Use 'ALL' pads to configure other required default settings simultaneously across all pads.

Save this as a blank program file and whenever you need it, load it up, select 'ALL' pads in program edit and you can then quickly assign a sample to all pads at once. You can enable warp across all pads as required.

It's not as flexible as a keygroup program, but if the goal is to spread the samples chromatically across the pads to play them like a 72 note instrument, with warping, then it will work.

Might melt the CPU though...

MPC-Tutor wrote:
Might melt the CPU though...

Might sound like crap too

[quote="
On one track/keygroup the cpu hit should be no issue on a keygroup with like 6-voice poly...no different from having warp active on 6 separate samples simultaneously..[/quote]

I agree with this. If the polyphony is low there should be no problem. You can imagine the simple example of having three notes/samples played simultaneously creating a simple chord. Stretching the length of 3 notes/samples, can be done in a drum program no problem. We all know that rule of thumb is to use warp sparingly for load reasons. I am guessing they don't want the user to have to manage cpu load. For a beginner, this could be a lot of responsibility. You could image a user potentially unknowingly sabotage themselves by overusing warp. The users will get upset that their unit is 'not working/lagging' and that the overall experience is below expectation...blah blah. That being said, the cpu can struggle recording audio while viewing the waveform in stand-alone mode. Apparently the above reasoning doesn't apply in the latter example.

The obvious solution is to have an 'experimental features' section. Have a disclaimer about experimental features potentially reducing overall system performance and let us have at it. Make it default disabled. We don't expect this to be a robust feature for performance situations. At the very least enable it so we can use it to bounce the keygroup track to a sample with the warp applied during the bounce procedure. This is probably low priority for AKAI. The next gen live 3.0 equivalent may have this in standalone.