Forum to discuss all matters relating to the MPC1000 and MPC2500 operating systems created by 'JJ' (all versions).
User avatar

By punchdrunk Fri Jul 13, 2007 6:17 am
Mike Feedback wrote: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.


:?

i think you're a little confused.

set q-link 1's target to TRACK
now when you record a sequence hitting all the pads and moving the qlink everything on the track is affected by the qlink and that qlink data is recorded into the sequence right?

what i am asking for is the ability to specify a value per pad in the program file that would overide the q-link slider's actual value. maybe i didn't make that clear before but storing this value per pad in the program file is what i've been saying this whole time. maybe you didn't catch that from earlier...

the function/ability is there already...

By ntalec Fri Jul 13, 2007 4:07 pm
punchdrunk wrote:

set q-link 1's target to TRACK
now when you record a sequence hitting all the pads and moving the qlink everything on the track is affected by the qlink and that qlink data is recorded into the sequence right?

what i am asking for is the ability to specify a value per pad in the program file that would overide the q-link slider's actual value. maybe i didn't make that clear before but storing this value per pad in the program file is what i've been saying this whole time. maybe you didn't catch that from earlier...

the function/ability is there already...


But wouldn't the problem still go back to a limitation in the Q-Link design?
Since we are basically talking about Akai evolution.
HiHat Decay>>became the Note Variation Slider>>which became the Q-Link Controller
Maybe it would take more recoding than it appears to get that functionality.
JJ added functions but never changed the way it worked in the grand scheme of things.
Just seems if he could have done it then he would have since as you say that methods almost exist now.
User avatar

By trybtek Fri Jul 13, 2007 4:44 pm
Just seems if he could have done it then he would have since as you say that methods almost exist now



true but JJ may not have thought of it or can't understand what we are trying to get across to him.
maybe if we could get him to understand exactly what we are talking about (having the ability to set qlink values per pad) then MAYBE it would be possible.
you never know, it may be a simple task or not, but it's worth the effort to at least find out for sure.
Having the ability to set start pionts per pad would SERIOUSLY open a whole world of creativity!

Peace!
User avatar

By punchdrunk Fri Jul 13, 2007 7:59 pm
/\/\/\/\/--------thanks trybtek for understanding what i am trying to get across.


trybtek wrote:Having the ability to set start pionts per pad would SERIOUSLY open a whole world of creativity!


EXACTLY!!! :twisted:

By ntalec Fri Jul 13, 2007 9:56 pm
Well we know that the communication barrier has been a bear at times but I found sometimes asking the question in a different way helps.
punchdrunk, try emailing him and ask more about the application of the Q-Links or how they function to see if the per Pad is something he can change or if it's more of a "hardwired software aspect".
Samplers usually have somethings that are pretty much hardwired software wise due to the overlay of it's architecture.
If he can't do it at least you could get a reason why he can't.
If you can talk to him about the Q-Link structure he can understand what you are trying to belay.
Maybe after that you can get into the functional application of it.

By Mike Feedback Fri Jul 13, 2007 10:21 pm
punchdrunk wrote:i think you're a little confused.

set q-link 1's target to TRACK
now when you record a sequence hitting all the pads and moving the qlink everything on the track is affected by the qlink and that qlink data is recorded into the sequence right?

what i am asking for is the ability to specify a value per pad in the program file that would overide the q-link slider's actual value. maybe i didn't make that clear before but storing this value per pad in the program file is what i've been saying this whole time. maybe you didn't catch that from earlier...

the function/ability is there already...


forget about the whole q-link thing you keep mentioning because this has nothing to do with q-link, this is what you really want to be able to do... and remember that all start and end points are used for is specifying the part of the sample that is played.

Method 1 with start and end points saved in the program per layer in a pad:

1) go into program mode.
2) hit A1.
3) select sample1.wav as layer 1's sample.
4) hit the window button.
5) in the play mode window, set layer 1 start point to 0, set layer 1 end point to 100.
6) hit A2.
7) select sample1.wav as layer 1's sample.
8) hit the window button.
9) in the play mode window, set layer 1 start point to 100, set layer 1 end point to 200

What Method 1 Does:

when pad A1 is hit or triggered, rather than use the start and end points specified within sample1.wav, it uses the start and end points specified for layer 1 which is 0 and 100. when pad A2 is hit or triggered, rather than use the start and end points specified within sample1.wav, it uses the start and end points specified for layer 1 which is 100 and 200.


Method 2 with sets of start and end points saved within wav file:

1) go into trim mode
2) select sample1.wav
3) edit->create new end point set (sample1.wav[0] becomes available)
4) select sample1.wav[0]
5) set start point to 0
6) set end point to 100
7) select sample1.wav
8) edit->create new end point set (sample1.wav[1] becomes available)
9) select sample1.wav[1]
10) set start point to 100
11) set end point to 200
12) go into program mode
13) hit A1
14) select sample1.wav[0] as layer1's sample
15) hit A2
16) select sample1.wav[1] as layer1's sample

What Method 2 Does:

when pad A1 is hit or triggered, since sample1.wav[0] had been selected, the sample plays using the first set of start and end points for sample1.wav of 0 and 100. when pad A2 is hit or triggered, since sample1.wav[1] has been selected, the sample plays using the second set of start and end points for sample1.wav of 100 and 200.


both of these methods would allow for you to use sample1.wav, but have two different pads play different parts of the file.

the advantage to Method 2 is that the sets of start and end points are saved within the wav file, which means that you can remove a sample from a pad and then add it back and the end points were retained. also, if that sample was loaded into a new session, all of the sets of end points which you previously saved would be available.

i personally like Method 2 because you could have a break:

break1.wav: boom tick bap tick boom boom bap tick

and you can save different sets of end points within it and end up with all of these samples in your program:

break1.wav: boom tick bap tick boom boom bap tick
break1.wav[0]: boom tick
break2.wav[1]: bap tick
break3.wav[2]: boom boom
break4.wav[3]: bap tick

now if you load break1.wav into a new program, it's just one file but it has 4 different chops within it and each can be assigned to a different pads without having to re-do the chops. now tell me that you wouldn't loooove that.
User avatar

By punchdrunk Fri Jul 13, 2007 11:06 pm
all of that would be GREAT except you are forgetting one major thing....

codespace is a MAJOR issue!
actually its past being an issue, its keeping any and all of this from happening!

since codespace is an issue, thats the ONLY reason why i've been pushing the q-link angle. man, there are PLENTY of differents way to do all this non destructive editing that would be DOPE (just like the examples you posted). i mean, if codespace wasn't an issue then i would say you should be able to specify each non destructive chop to play in reverse or pingpong loop etc....but that would be ridiculous cause there is basically no codespace left.

so for me, trying to figure out the smallest, most realistic way to get this somehow added one day means the LEAST amount of code...which brings me back to the qlink controlling the start point. all we would need is a per pad value that would effectively just override the qlink slider value. that would require the least amount of code (that i could imagine)...

either way i don't care WHAT version of non destructive chopping were to be added as long as it somehow miraculously appeared one day. i just always assume the qlink way would be the smallest amount of code needed....

By Mike Feedback Sat Jul 14, 2007 2:05 am
using q-link to do non-destructive editing would require the MOST coding because it would require a complete rewrite of how q-link works. each q-link is only set up to work one pad (or track) at a time and using it would not be economical.

the least amount of coding would probably be to use Method 2 that i described.

the reason it would be the least amount of coding is simple. when a sample is triggered, the mpc already looks within the wav file to find the start and end points that should be used. coding would just need to be added to reference a different location in the wav file if a different set of start and end points was chosen.

once that is taken care of, then it's just a matter of writing the algorithm to create and delete sets of end points from the wav file, and then adjusting the list of samples which show in the trim and program windows so that samples get split out to include the arrays of end points.

i know what i'm talking about here since i'm familiar with the program file layout and understand how the mpc loads, saves and stores the data in memory. a few months back i began to make a bluebox type program before i got side tracked. i had it successfully loading and saving program files and it was able to adjust almost all of the parameters in a program.
User avatar

By trybtek Sat Jul 14, 2007 2:09 am
hey, i just wrote JJ an email trying to explain the Qlink idea, I made it as simple as possible and gave him the link to this topic.
lets hope he understands and can let us know if its possible or not!
Peace!
User avatar

By punchdrunk Sat Jul 14, 2007 11:49 am
Mike Feedback wrote:using q-link to do non-destructive editing would require the MOST coding because it would require a complete rewrite of how q-link works. each q-link is only set up to work one pad (or track) at a time and using it would not be economical.



ok, i think we are going in circles here.

why would q-link require a whole rewrite? thats insane. the per pad value i'm suggesting would just be a hack to overwrite whatever value the qlink slider WOULD have provided. thats it. nothing else. i'm not trying to add any new functionality to the qlink architecture, or revamp it.

doing it this way would take up qlink 1's use (cause qlink1 would have to be set to start point), but i'm fine with that. its a sacrifice but its more realistic of this happening that way than anything else.

doing it your method would require writing a whole new function. look at how much stuff you just wrote that needs to be added...

Mike Feedback wrote:coding would just need to be added to reference a different location in the wav file if a different set of start and end points was chosen.

once that is taken care of, then it's just a matter of writing the algorithm to create and delete sets of end points from the wav file, and then adjusting the list of samples which show in the trim and program windows so that samples get split out to include the arrays of end points.



???

that right there to me seems like a WHOLE lot more coding would be required for that method, rather than just adding a per pad qlink value that would be stored in the program file.....


wow, i think we could go back and forth on this forever...:twisted:
trybtek wrote:hey, i just wrote JJ an email trying to explain the Qlink idea, I made it as simple as possible and gave him the link to this topic.
lets hope he understands and can let us know if its possible or not!
Peace!


thanks trybtek! i'm curious to see what he would think about the possibilities of this....

By Mike Feedback Sat Jul 14, 2007 4:11 pm
punchdrunk, have you ever programmed anything? how do you know what requires more coding?

this is the coding mine requires:

coding would just need to be added to reference a different location in the wav file if a different set of start and end points was chosen.

once that is taken care of, then it's just a matter of writing the algorithm to create and delete sets of end points from the wav file, and then adjusting the list of samples which show in the trim and program windows so that samples get split out to include the arrays of end points.


and here is the coding that yours requires:

adjust program file layout so that it can include start and end point data. if there is no more space in the program file, then the layout will have to be completely changed which would also require a rewrite of the saving and loading of program files. the akai OS would no longer be able to load JJ OS saved program files.

also, start and end points per pad will most likely be limited to a relative range (i.e. 0-100 or 0-255), this is because the program file layout is fixed-width and a sample's exact start and end points cannot be stored since their lengths would be variable depending on the size of the sample. it also limits the accuracy of the chops since the values you can choose are only 0-100 or 0-255.

re-write the q-link methods so that if start point or end point is chosen the values shown are loaded from or saved to the pad section of the program file rather than the designated area in the program file for q-link. adjust note triggering to locate start and end points within the pad section of the program when playing sounds. adjust note triggering so that if start and end point is chosen in the q-link, the q-link parameters are ignored. you'd have to ignore these values since they are now being stored and accessed from within the pad as q-link is only being used as a means to adjust the pad values.

limit q-link so that if start and end point is chosen, tracks can no longer be chosen. this is because start and end points now store and load their data from the program file and track data cannot be stored in the program file. if you want it to work for tracks, it would require even more coding.


i know that maybe it seems like your method is easiest and requires less coding, but that really isn't the case. you're coming to that conclusion based on the look of the user interface only and you're not taking into account how the user interface interacts with the architecture of the program file or the inner workings of the machine.

i guess i shouldn't really expect you to understand why your method requires more coding so maybe this post is fruitless.
User avatar

By punchdrunk Sat Jul 14, 2007 10:51 pm
Mike Feedback wrote:punchdrunk, have you ever programmed anything?


yes, actually i have.
moving on...

Mike Feedback wrote:and here is the coding that yours requires:

adjust program file layout so that it can include start and end point data.


:?

maybe i'm not communicating my idea clearly enough cause what you wrote is still different from WHAT I'VE BEEN SAYING. there are some big discrepancies between what you brokedown as my method, and what i've been saying all this time. its not really worth going in circles retyping what i've already said in my last couple posts.

but either way the breakdown you wrote was still interesting. the compatibility between a JJ os and the akai OS especially. but i imagine that wouldn't be an issue seeing as how it wasn't an issue when akai changed the program format in 2.01 to include mulitple mute targets and lfo. those programs still open up in 1.07 so while compatibilty is a good topic to bring up i don't think it would be an issue. plus i think about 99% of the people who have the JJ os aren't really too concerned about going back to the akai OS. :wink:


and as far as accuracy thats a good point too, but for all the times i've tried chopping with the qlink slider on start point, i haven't had a problem with accuracy and that is only on a scale of 0-100. if it was an insanely huge file that wasn't accurately chopping you could always split it into two files and be fine...

Mike Feedback wrote:i guess i shouldn't really expect you to understand why your method requires more coding so maybe this post is fruitless.


:roll:

either way i think its wasted energy on both of our parts since its all hypothetical and either way we still don't have any form of non destructive editing that either of us has been describing... peace!!

By po'pimpin Sun Jul 22, 2007 10:31 am
Everyone give up hope on this one?

By epidemic Sun Jul 22, 2007 9:24 pm
i was thinking the same thing 2day

think about the chop function. it could be as simple as setting each pad to triggor a different region.

when you are chopping a sample you already have the ability to play the region with the pad. but what if instead of having to use the data wheel to select the region each pad was assigned its own region. spread across 16 pads thats 16 triggor points. maybe each region's start and end points could act independently too (so they can "overlap").

just a thought iunno about coding but it seems like a simple way to get it done to me
By crossfade Mon Jul 23, 2007 1:18 pm
punchdrunk I Asked JJ way back when he first started the O.S.
And I got no response.
I still can't understand how Ensoniq did this 15 years ago and no other company can achieve this.......Sound like a bunch of bullish..........
WOW thats why I still got my ASRX today.......Its amazing how everyone is talking about chopping on the mpc and using recycle......Man has anyone ever used a asrx and know what I talking about when I say how much easier it is to sample on an asrx and send it to all 61 notes in a matter of 2 seconds.
Come on JJ come through with this......