OS1 trim screen behavior not consistent with Akai OS

i started with a 2000xl that i got in 2001. i've said since i switched to the 2500 that the end point behavior for the 2500/1000's akai OS and JJ OS both pail in comparison to the 2000xl.

i've requested many times that the speed of the data wheel determine the amount the end points change. that's the way that it is in the 2000xl. your zoom should be independent of the amount of positions the end points move.

you shouldn't have to press the zoom button 10 times just to change the end point by a single digit, and i don't care if that's how most sample editing software works. as someone said above, you don't need to see the waveform, the waveform display isn't even that accurate (especially when zoomed out).. these mpc's don't have 19" flat screens. use your ears, not your eyes. i NEVER used the zoom feature when i had the 2000xl, the JJ OS forces you to.

you also shouldn't have to hold shift and press the cursor button to change the 10's position or the 100's position or whatever position like with the Akai OS. it's just annoying, and i don't know which position i need to change. it's trial and error... you change it to the 100's and notice it isn't moving quick enough, so you have to hit shift + cursor and change it to the 1000's only to realize it's still not enough. then to slow down you need to hit shift + cursor to change it to a lower position again...

if JJ would just implement velocity sensitive scrolling, our problems would be solved. no matter what zoom you're in, if you move the data wheel slow, it would change the end point by 1 position. a little faster and it would move by 10 positions, faster than that 100 positions, then 1000 positions and so on. that's the way it should work. anyone who's used a 2000xl knows what i'm talking about.

it's just so much more intuitive and smoother and easier to work with.

>> So to summarize the discussion, there would be 2 enhancements in Trim Mode to perfect it:

1) "Velocity Sensitive Scrolling" >> like that a lot - don't know if its possible on the tech tip though...

2) Moving Cursor to specific digits of start/end point value without having to zoom in - should be easy..

EDIT: This afternoon I sent JJ an email, asking of these thing were possible to implement in the TRIM Mode. I'll let you know when he answers...

stan steez wrote:>> So to summarize the discussion, there would be 2 enhancements in Trim Mode to perfect it:

1) "Velocity Sensitive Scrolling" >> like that a lot - don't know if its possible on the tech tip though...

2) Moving Cursor to specific digits of start/end point value without having to zoom in - should be easy..

yea! that would help alot.


i think that velocity sensitive scrolling would rock... along side with the q-link trimming which i ve grown to like....

i've messed with a 2000xl and i know whats up with that....


if you tick along then it should be in increments of 1

but if you spinning the wheel like crazy then it should be intuitive.... like following your pace.




im still waiting for my doctor dre beat template.

come on jj

make my beats!!!

lol

you guys are talking about regular data wheel use in TRIM, correct?
i'd enjoy accelerative scrolling IF the old "tap tempo+data wheel" specification remained. you get it? when you're just using the data wheel, it moves in SMOOTHLY increasing/slower increments (NOTa "threshold of speed increase" like in earlier jj os's), but when you hit tap tempo, it works as it currently does when you hit tap tempo.

likewise, upon zoom, the entire resolution of your scrolling/accelerative scrolling should decrease sympathetically as you zoom, keeping with current specification.

i agree w/ mike feedback's post most of the time, and for small adjustments i would be very excited for accelerative scrolling, but i will argue upon the ever popular "use your ears" and "the screen isn't very accurate"

if i were completely deaf, i could use just the screen and the zoom functions in chop, i can slice a drum break (drum break, mind you, not a no-transient string melody) with sharp accuracy.

this isn't regarding you, Mike, as i don't count you among this group, but i attribute the frustrated howl of "use your ears" to old timers who for some reason feel threatened by a graphical representation of a wav file and would love to attribute the downfall of hip hop on what is actually just an additional sensory asset! an extremely useful one, at that!

since i turn every note into its own wav file AND because i can read a transient like it was a good book, zooming in is an integral part of my chopping. if this wasn't an issue i'd almost prefer to leave it the way it is, as chopping note per note on the 1000/2500 is awful goddamn speedy if you've got quick fingers...and aren't busy talking to a virtual audience

http://youtube.com/watch?v=2K3sfXO6ySY

largely this depends on how it was implemented
-it shouldn't slowly ramp up, as you spin at a constant (fast) speed
-or suddenly kick in higher gear as you spin at a constant fast speed (it did this in earlier jj os, and it was removed because it was unpopular

-it should take an immediate reading on how fast the ticks of the data wheel are spinning and move at that speed, so if you start fast it realizes it and runs along, but if you slow down it will slow down too. truly accelerative, not a workaround.

cool thread

Nym wrote:if i were completely deaf, i could use just the screen and the zoom functions in chop, i can slice a drum break (drum break, mind you, not a no-transient string melody) with sharp accuracy.

come on now Nym, if you were completely deaf, would you really have an mpc or be able to comprehend transients? lol.

i'm not saying to remove zoom, it just shouldn't be necessary to zoom in to do a fine adjustment. and once you get velocity sensitive scrolling, i think you'll soon realize that it's far better than the current way.

and it's certainly possible to implement velocity sensitive scrolling. i'm not entirely sure how the data encoders pass information back to the mpc, but in theory all you would have to do is set a date variable every time the data encoder clicks, and you'd compare that date variable to the previous date variable in order to get the speed at which the wheel was spun. if the difference in time is large, then the wheel was spun slowly, but if the difference is small, then the wheel was spun fast. it's the same concept as tap tempo.

hahah dude if i became deaf i think i'd still use my mpc, cling to it like a bizarre token of what could have been. i'd die a year later of starvation, and my skeleton would drum lifelessly on rubber

but in theory all you would have to do is set a date variable every time the data encoder clicks, and you'd compare that date variable to the previous date variable in order to get the speed at which the wheel was spun. if the difference in time is large, then the wheel was spun slowly, but if the difference is small, then the wheel was spun fast. it's the same concept as tap tempo.

this is the way it would HAVE to happen, any other way is potentially a real headache and not worth the struggle.

do you remember like a year ago how in trim when you'd move along, if you'd been turning the knob long enough suddenly it would speed up? that was a lesser perfect implementation of some sort of 1 time accelerated scroll.

if we ever have it at all it's gotta be just the way you just described. but data wheel + tap tempo should speed up the 2x the calculated speed for those huuuge samples

very good, i hope this happens. i agree, it'd be nice to make chopping a less clicky affair

yes, this accelerative scrolling would be a good thing imho. it would only need a resolution of 4 or 5 steps: 1's, 10's, 100's, 1000's and, perhaps, 10,000's. We need to work out what we need. Possibly even adding an adjustment in [mode] [other] would be worthwhile, catering for the obsessive/compulsives among us (you know who you are nym) and the minute long samplists too, as they could adjust what step size turning the data wheel at maximum speed would do. So: with the adjustment set to 4, turning the data wheel fastest would change the sample position by the 1000's, change the adjustment to 3, and it would only change it by the 100's. Basically, we'd work out an average top speed of turning the data wheel, and that could be our top marker. Then, according to the adjustment resolution value, the speed range of the data wheel would be spilt into equal portions giving an even distribution across the speed range.

Another idea (maybe getting too out there, but what the heck) is that this accelerative scrolling could be a system wide, kernel-level-type function (if the JJOS works similarly to PC OSs) and would work on any value that can be adjusted by the data wheel, like the sequence position etc.

some of the ideas in here are good, but I'd really just like to see the ability to select the increments manually added back to the OS

for instance, your end point is at 15982

shift + cursor allows you to highlight:

15982
5982
982
82
2

that's how it is in the Akai OS

I had already e-mailed this to JJ -- I was told the request was sent to the coder

thedvs01 wrote:some of the ideas in here are good, but I'd really just like to see the ability to select the increments manually added back to the OS

for instance, your end point is at 15982

shift + cursor allows you to highlight:

15982
5982
982
82
2

that's how it is in the Akai OS

I had already e-mailed this to JJ -- I was told the request was sent to the coder

i do NOT want that back, nor do i want to have to zoom in to change the increments.

Mike Feedback wrote:i do NOT want that back, nor do i want to have to zoom in to change the increments.

100%!!!

punchdrunk wrote:

Mike Feedback wrote:i do NOT want that back, nor do i want to have to zoom in to change the increments.

100%!!!

so then how would you prefer the increments get changed?

currently SHIFT + the cursor keys doesn't do anything at all while in TRIM mode, so I don't see what the harm in adding the option is

i think his view is that accelerative scrolling would work to the same effect as your idea of changing increments. rather than the increment being determined by zoom OR a parameter, it'd be determined by speed of scroll. i agree with this. i hope to make a graph to show jj at some point regarding this but i'm too fkin busy...

Nym wrote:i think his view is that accelerative scrolling would work to the same effect as your idea of changing increments. rather than the increment being determined by zoom OR a parameter, it'd be determined by speed of scroll. i agree with this. i hope to make a graph to show jj at some point regarding this but i'm too fkin busy...

lol @ "make a graph" reminds me of being at school thinking 'what's the point of making these graphs, i'm never gonna use them in real life!'

yeah and that's why i'll look online for some "free graph making" website, which will probably also boast the ability to save me money on taxes

I like the accelerative scrolling as well, but even with that feature implemented, SHIFT + cursor will still have no function, so it might as well be added.