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

yup he did!

yeah. jj said no more new features... then we get bit reduction and ring modulation. not exactly "small" things

actually, they are exactly "small things" that is where it counts - in the code. those are offline, destructive edit tools that take up less than 4 or 5 kilobytes of code data. what is being discussed here is a completely new chopping feature which i would guess to take at least 20 kilobytes.

sorry yall. using bit reduction and ring mod as justification that "more can be added" is kind of a dead horse.

but replacing the old slicing feature with a new one wouldn't really be adding a whole new feature right? its not like you'd leave the old slicer in there taking up space.
i don't know though im no coder, but what I hope for more than anything else is the stability of the os

replacing the old slicing feature with a new one wouldn't really be adding a whole new feature right? its not like you'd leave the old slicer in there taking up space.

no indeed. i've actually drawn the theory behind a non destructive chopping tool that would actually work with the current slice (just a little edited).

i will explain it briefly here but trust me, i doubt it's going to happen - 1, because it's difficult to communicate and 2, because i dont think there's codespace.

it's based on the idea of "flux"
imagine this to be your sample:

abcdefghijklmnop

say you chop it by 4

abcd | efgh | ijkl | mnop

now say you hit F2 to designate new program from slice.
imagine: screen pops up that says "LEEWAY= __" and then gives you a parameter. that parameter determines how much "extra" to leave in each chop forth and back. for instance, let's say i inputed a modest number. the chops would then look like this:

abcde
defghi
hijklm
lmnop

note: overlapping letters at the beginning/end of each sample.
note: each sample would be trimmed with the selection to the actual slice point, so it would play as chopped.

this way, you're not making entire copies of the sample again and again, instead you're inputting the "leeway" you want. you could input more or less depending on your intended usage.

again, so unlikely to happen...

I nearly threw up laughing at the last few posts..............

yo antonym, the example you just gave about "leeway" is something that i've wanted in zoning for a long time......

BUT in your example you just put, wouldn't it STILL be actually chopping the wav into seperate waves?





maybe i misunderstood (if so my bad), but if not then that defeats the whole purpose cause that would be destructive editing. making sepereate wav's for each chop would be destructive.

the whole point is to have one sample that is referenced multiple times but never actually chopped up. so say you've chopped up a break ("break1.wav"), then later on you mess with the original file ( still "break1.wav"). say you mess with bit reduction or putting a ring mod on it for example. normally you would have to rechop all your chops, make a new program, etc.... but with nondestructive editing since you've edited the original file all your "chops" would be referencing this original file, which is still "break1.wav," but now its been bit reduced/ring moded or whatever.

that is just ONE of the advantages of the non destructive aspect.....there's a bunch more....


and @ stale bread: i was never thinking of replacing the old slicing method. that would be too much of a change to the os.

at this point i would really just be happy if i could at the very least set a different start point of a sample per pad. even without being able to set an end point, i think most people could still get by using all pads set as note on and rocking it.....i know i could!

peace!

@punch
i think having the option for a start point per pad is def the way to go!
you could even leave one-shot on and set the program to mono
i think there has to be some code space left, this will make the mpc a KILLA!
ps. i got a 2500 but i think both machines should have this function.
Peace!

You guys do understand that the MPC1k/2500 already does Non-Destructive Chopping to a certain degree??
JJ just needs to expand on it.
A Patch Phrase is in fact plotted points of reference on a given sample, that's why you can undo it and return it back to it's original state.
If you want Non-Destructive Chopping it should come from using that.
JJ has not added anything to the 1k/2500 he has simply realigned and expanded on what Akai did, so that would be along the same lines.
All he has to do is make the unit create hit points that can be manipulated.
Whether or not it would be really beneficial would be the real question since it would create a somewhat proprietary wav file.

trybtek wrote:@punch
i think having the option for a start point per pad is def the way to go!
you could even leave one-shot on and set the program to mono
i think there has to be some code space left, this will make the mpc a KILLA!
ps. i got a 2500 but i think both machines should have this function.
Peace!

/\/\/\/\
' '--------exactly!!




and @ ntalec:

all that propietary wav form etc using the patch phrasing seems way to much trouble to me (and would probalbly take up way more code). you can already do non destructive chopping by setting q-link1 to start point and messing with the q-link slider while playing the pads. while this works it can get a bit messy and not so exact. the ability for non destructive editing lies right there, its just a matter of being able to specify that q-link value for start point per pad instead of with the slider.....it already exists right there (for the most part)....

so.......damn.......close.....

i still can't understand the reason why this topic hasn't been already locked???
isn't that a request topic? (like all the others request topics?)

there were a lot of functions that were pretty near before the os size reached it's limit...

punchdrunk wrote:



and @ ntalec:

all that propietary wav form etc using the patch phrasing seems way to much trouble to me (and would probalbly take up way more code).

No it wouldn't.
The reason I mentioned proprietary wav file is because that's what a Patch Phrase already is.
Only the 2500 and the 1k can interpet the points.
This type of editing is really great because it would expand the 128MB of ram as well since you would be using less.
The EMU Emax has very limited memory but because it just makes new reference to the existing file you can chop the file without effecting the original or using more memory.
Same thing the patch phrase does now but you would be able to trigger the individual time slices.
My thoughts on the Q-Link still makes me wonder if it's possible.
Reason being that JJ could have easily improved that back when he first expanded the Q-Links so I wonder why he didn't?
It would be interesting to talk to JJ to see what he thoughts are on the whole idea of Non-destructive or a Q-Link tweak.

i think the easiest way to accomplish this is to have end points which are saved in the pad rather than in the wav file. since end points are currently saved within the wav file, you only have one set to choose from.

if you had the end points saved along with the program by pad/layer, you could essentially reference the same wav file via different pads but with different end points from each pad.

this would require adjusting the program file layout in order to have end points saved within it. it probably won't happen since the program file currently has a fixed width layout, and since end points could be very large numbers depending on the size of a wav file it would require a lot of file space which the current layout doesn't have. it would require an overhaul of the program file layout to allow for the end points to be saved there.

the downside to this approach would be that if you wanted to move a sound to another pad, you'd have to re-do the end points.

another method would be to save an array of different sets of end points somewhere in the wav file. then the ability to choose which set of end points to use would have to be added which may take up a good deal of coding. rather than just seeing "sample1.wav" at the top of the trim window, it would be "sample1.wav[0]" or something along those lines. the [0] would mean the first set of end points was chosen and to use different sets of end points it would be changed to [1] or [2], etc depending on the amount of sets of end points saved in the file.

/\/\/\/=====thats definitely a whole nother way of looking at accomplishing this, but with code size being such an issue i still think just adding the ability to specify a different qlink value per pad would be the easiest way. that's saying that you specify qlink1 to control the start point. that whole function already exists in the os, so its just the ability to set the qlink value per pad that is missing....

and specifying a different qlink value per pad could even be flipped in different ways cause then whatever was basically specified as qlink1 would be controllable per pad too....

....i imagine that WOULD have been the easiest way to attempt it with the smallest amount of code to add....

punchdrunk, i think you're a little confused. the q-links only have the ability to store the values for a single pad at once. once you change the q-link from A01 to A02, it ceases to control A01, and the values you had for A01 are not retained in memory.

to accomplish what you are looking for the end points would either have to be stored in the pad section of the program file or within the sample as i described. trust me.