NON DESTRUCTIVE CHOPPING.....PLEASE!!!!

Co-sign.

Antonym, could you please ask JJ if that's doable? Thanks.

i will mention it in my next bug report, and i do like the idea, but i have to say it is a bit redundant. the current chop version suits me just fine, and since the feature as yall have discussed would 99% definitely take up the QLINK data entry of each recorded note, you'd only be able to effect it with QREAL not QLINK NOTE ON. also, remember that as of now there isn't gonna be any real new features due to the size of the os being filled.

IT might seem redundant if youve never used the ASR but if you have you would know this is the illest way. This is the last step in making the 1000 the illest machin workflow wise ever. It kinda alrady is to me but this is the 1 thing i always hoped for in any MPC.

I think we should see if we get the diff OS idea wit certain features dropped out because i Have never used GRID and dont see myself doing it really. To each his own. It would be ill to get an os with Non Destructive Chopping in place of something you dont use.....in my case GRID,etc.

Not with each note - the way I see it is having different sample start/end per pad. Like, having 16 pads play different parts of each sample. Or have I strayed from the path?

Antonym wrote: the feature as yall have discussed would 99% definitely take up the QLINK data entry of each recorded note

Not with each note - the way I see it is having different sample start/end per pad.

if this was the case, you'd need X copies of the sample. otherwise, you need some quality which tells the mpc to play the sample from a different start point. as of now, the only place in which that happens is 1, trim and 2, qlink data.

to not use qlink data for nondestructive chopping would require additional, completely new code not utilized in anything else before.

if this was not the case, it'd be a better chopping system. however, given our current situation, i really fail to see how this would be worth spending valuable code on as it doesn't really give us any more capability than we already have.[/quote]

for me it would be the best feature ever added to the os ,i dreamed a long time of such a cutting-method (only set start points) before buying my mpc ,if i had known the asr can do it this had been my buying decision.

question: is only the asr-x able to cut nondestructive or also the asr-10/asr-88?

oLsen wrote:question: is only the asr-x able to cut nondestructive or also the asr-10/asr-88?

The asr 10/88 too.

In order to implement this feature there needed to exist a Set Sample Start for each pad at Program Mode. Technically is very similar to the Velocity>Sample Start feature that exist in most new and old akai samplers and mpcs. This Velocity>Sample Start feature is limited to a fixed maximum value, wich can be annoying to use with long samples.

For each pad, a Sample Start (and preferably Sample End too) property that would add values to the start point defined in Edit Mode, but independent from it. Changing one as no effect on the other. Max and min values would be or either in samples unit (dynamically calculated based in the sample length) or in percentage, this way there would be no limit to the Sample Start.

Antonym wrote:to not use qlink data for nondestructive chopping would require additional, completely new code not utilized in anything else before.

actually i was always imagining that it WOULD take up the qlink data for the start and end point. i'm completely fine with that. the function is already there, its just a matter of the pads specifying the start and end points.

rough example: if q-link1 is set to start point and q-link2 is set to end point, then each pad would just need a start point value and end point value. this value would basicly be setting the qlink value for qlink 1 (start point) and qlink 2 (end point) when that actual pad is hit.

i'd be happy with just that. no need for a whole new function
coded in and all that. just let me assign those values for each pad....

Antonym wrote:if this was not the case, it'd be a better chopping system. however, given our current situation, i really fail to see how this would be worth spending valuable code on as it doesn't really give us any more capability than we already have.

chopping this way is a COMPLETELY different feel and method that we don't already have. experimentation with it is dope in this kind of setup. little things like you can have your beat play and change the start and end points in real time, completely flipping stuff in a way you never would have thought of before.

whole other workflow to mess with.
i think this would be so crazy to have...

chopping this way is a COMPLETELY different feel and method that we don't already have. experimentation with it is dope in this kind of setup. little things like you can have your beat play and change the start and end points in real time, completely flipping stuff in a way you never would have thought of before.

yeah that'd be cool for sure. it'd also be cool for some stuttery type madlibbian stuff too, letting the end point overlap barely with the next note of the chop. such stuff is of course possible with the current chopping method but takes a little longer to program.

i'd be happy with just that. no need for a whole new function
coded in and all that. just let me assign those values for each pad....

that'd make it a lot easier on the code, for sure. so as long as people realize that the qlink data entry would be completely taken up by start point (OR end point. only 1 or the other as there's only 1 qlink note no data entry point).

most samplers work this way. i myself was surprised when i found out the mpc didn't...

co- signed for the feature...

this is a great idea... I was thinking that also.

WE NEED THIS....

jhs wrote:most samplers work this way. i myself was surprised when i found out the mpc didn't...

for real me too.. i thought that would be standard - the current methods are workarounds imo

I think people are talking about things that are similar but not the same thing.
Going back to the original poster the ASR-x is the box to see this on, the ASR-10 is similar but not the same as well as most samplers out there.
On the ASR-x Pro when you sample it ask you to send to PADS the ASR-x actually triggers PADS not samples.
You can do this to a degree on the ASR-10 and most multi-samplers but it requires additional movements and setups.
The X has multiple levels of editing parameters one of the levels actually eidts PAD info so you adjust the Filter/Start/Stop/Loop/Tuning/MODs/ENV/FX routing etc per PAD instead of per sample.
So all 13 PADs per octave have their own set of parameters.
You sample something assign it to the PADS (as many or as few you desire) then you can have the option to edit the parameters of the pads.
Very similar in concept too if on a DAW you took a track routed it to multiple channels and the put different effects on each of those channels, you would have many different versions plus the original at your diposal.
On the ASR-x since it is able to do the parameters typically done in the sample editing section in the PAD section you never change your original sample.
The only drawback is you have to replace or have your ASR-x encoders replaced with the bigger heavier ones otherwise the scrolling of parameters and values is a nightmare.
Look at it like this:
Total sample size 995500
PAD1 size 0-1000 FILT setting ENV setting MOD setting AMP setting PITCH setting
PAD2 size 999-2000 FILT setting ENV setting MOD setting AMP setting PITCH setting
PAD3 size 2010-2200 FILT setting ENV setting MOD setting AMP setting PITCH setting
PAD4 size 500-60000 FILT setting ENV setting MOD setting AMP setting PITCH setting
etc
Since each PAD in a MIDI key that gives you a different version os the same (or different) sample on each key without any crazy duplicating, routing and such, it just the strucuture of the ASR-x.
**Not trying to sell anyomne on the X just trying to clarify what the non-detructive is about on it**
Not sure if JJ could effectively implemement something like this without creating a special mode for the MPC since it would effect things like the Sample layers, Simult pads and most of the settings in a Program.

ensoniq samplers had this feature back in the 80s. the whole point is to save memory, so you dont have to copy the same sample.

Dahkter wrote:I think this would be pretty cool, however you'd need to use a small sample or you'd run out of memory pretty fast...