beta 12 bug list (ONLY POST IF YOU KNOW YOUR SHIT)

ok. i started a new thread for this. everyone who has posted def knows their shit, i'm not questioning that, but i just wanted to make sure people knew we were serious here.

you guys have been great help, peace to bigman, joey, utty, mura, h-mann, and others who have generously donated time and effort to the cause. we will see this through and revel in the JJ n co's success.

THE LIST SO FAR

i installed 12 and the first thing i saw was this -

Bug 1 - TRIM CRASH
turn on the mpc w/ autoload off - you have nothing loaded.
go into the trim mode, you crash. bang. nothing big, but something that needs to get cleared up.
Bug 1:

Bug 2 - New TRIM ISSUES
power sources ON→ (unused) selecting the sequence
2 enter trim mode (Mode+Pad6)
3 (problem) user cannot select numeric entry
4 (problem) user cannot select increments of movement without zoom
5 (problem) zoom and increment level are not standard, but dependant on sample length
6 (problem) zoom in and out are inconveniently located if needed to edit properly, zoom in and out should also be selected by using (shift+<cursor = zoom out) and (shift+>cursor = zoom in)
7 (problem) user cannot select via AFTER + QLINK


Bug 3 - Direct Recording
1 power sources ON→ (unused) selecting the sequence
2 select track 61-64
3 set recording preferences in (Tr:+Window)
4 press record using (rec+play start) or (overdub + play start)
5 after metronome counts in, record a take and press (stop) when finished
6 press (play start) to replay take
(bug) recorded take has count in time as well as the original small gap (approx 00.011.700) included in the sample

Bug 4 - Trim List
1. Load a project file
2. Go to TRIM screen
3. Can't scroll through samples, sample list window messed up sometimes
workaround: load a new sample or make a copy of a loaded one

Bug 5 - L+R conversion to mono
1. load project w/ stereo sample
2. convert to L+R mono
3. scroll through samples
4. machine has a CPU Address error (read), does a stack dump and the machine crashes.

posted by bigman in the old 3.0 bug thread:
-------------
Since a couple of features have recently been taken out and/or dramatically changed, I thought this thread would be the best place for this even though it's not technically a bug.

I've noticed that in beta version 10 the trim/loop screen has changed in layout as well as the ways to navigate it. In this new layout the zoom functions are right in the main trim screen which is nice and the up down cursors can make the waveform look larger or smaller which is also a good thing. However, a couple useful ways of adjusting values are absent from this screen now, which are: qlink control of start and end time and numeric entry for start and end time. This leaves you only with the jog wheel, where increment control is now completely tied to the zoom level and sample length as explained below.

For example, a sample that is 00683909 long (<- this is the new sample time readout in trim/loop) will jump in these increments: 00002885, 00005771, 00008657, etc.. when fully zoomed out, which is the default in trim/loop view. While another sample that is say 00345178 long will jump in increments of 00001456, 00002912, 00004369, etc. Zooming in decreases these increments based on how long the sample is, and zooming all the way in is now the only way to be able to scroll one increment at a time.

Since the qlink and numeric entry are gone and jogging has changed, you must zoom in and out and really use your eyes to scroll to the precise spot to make an edit. Then you must zoom out to get to your next edit point which can get time consuming when doing specific tasks like extracting or fixing the track 61-64 problem.

With this being said, there is a good side to this new trim/loop mode. For one, the way the waveform now moves while the start/end point remains stationary (only on the screen of course) feels good in comparison to the opposite way it was before. Also, the new look and feel of the trim/loop screen is generally much smoother, faster and overall nicer than before. It looks almost as if the new trim/loop mode layout is meant to resemble certain computer based DAW's ways of sample editing, which is a step in the right direction.

So, to fix the control problems I mentioned but still keep the updated parts of the new trim/loop mode, I think these changes would work.

1. Put back qlink control of start/end points if possible
2. Put back numeric entry of start/end points if possible
3. Since (Shift+Cursor <&>) are now unused in this screen, the Zoom In and Out controls would fit nicely in these spots and speed up trimming. (Since zooming is now manditory to edit precisely and the buttons to do this are only on F3 and F4, it makes it inconvienient to constantly go back and forth from while editing.)

Let me know what you guys think since this is a big change for anyone who edits samples in the MPC.
--------


I agree. Without q-link and numeric entry I think this version is definitely worse than the one before. I use numeric entry a lot and I'd really miss it. Also the new "vertical" zoom (up and down) replacing the logarithmic scale is not a good solution imo. To sum it up, I'd be happy with the old trim (as for this issue). What do you other guys think?

granted i haven't seen the new trim
and i liked the old one just fine
but if they could tweak it so that qlinks did the same thing they used to and if the AJJJ followed the rest of bigman's suggestions on this issue
i'd be a happy camper

otherwise, it wasn't broke so it didn't need fixing.

Antonym wrote:granted i haven't seen the new trim
and i liked the old one just fine
but if they could tweak it so that qlinks did the same thing they used to and if the AJJJ followed the rest of bigman's suggestions on this issue
i'd be a happy camper

otherwise, it wasn't broke so it didn't need fixing.

have u made this clear to JJ? I agree totally
Is JJ gonna sort the slice business out with chop shop? - that's more my concern

A new bug has spawned from an old bug. The track 61-64 sample time problem has been attempted to be corrected and improved in this beta according to the bug fix notes, but the end result is now worse.

Here's what is going on. I loaded beta 11 and immediately went to track 61 to see what has been changed or fixed. I set my recording preferences (tr+window), set the bars to 2 and the tempo was left on 120. I then pressed overdub and play start to begin recording.

The first improvement I noticed was that when you press overdub or record, a small window pops up on the screen telling you your selected recording input(s) and the name of the take that is about to be recorded. After engaging record, I waited for the 1 bar count in and played guitar for four bars instead of two. This is where the second improvement comes in, the MPC now asks if you would like to change the bars of the sequence to match the bars of recorded material, or leave it alone to loop at whatever amount of bars you already have set.

Now here is the bad part, the sample records the count in period and still has the small bit of extra time that created the original problem. So, when you play back your phrase it now comes in 1 bar and about 1/8 note late. What makes this worse still is that the new trim window does not let you easily select exact amounts of time to discard in order to work around this.

This means that there are now two pretty big bugs, where only one small one used to be. So, here are the preliminary bugfix reports I am planning to send to the author. I am posting them here first to see if anyone has any suggestions to more clearly state the problems so they can get fixed properly.


Bug 1:

1 power sources ON→ (unused) selecting the sequence
2 enter trim mode (Mode+Pad6)
3 (problem) user cannot select numeric entry
4 (problem) user cannot select increments of movement without zoom
5 (problem) zoom and increment level are not standard, but dependant on sample length
6 (problem) zoom in and out are inconveniently located if needed to edit properly, zoom in and out should also be selected by using (shift+<cursor = zoom out) and (shift+>cursor = zoom in)


Bug 2:

1 power sources ON→ (unused) selecting the sequence
2 select track 61-64
3 set recording preferences in (Tr:+Window)
4 press record using (rec+play start) or (overdub + play start)
5 after metronome counts in, record a take and press (stop) when finished
6 press (play start) to replay take
(bug) recorded take has count in time as well as the original small gap (approx 00.011.700) included in the sample
(bug) due to the restrictions of the new trim window, user is not able to select exact increments of time to edit from the sample, which now makes this problem virtually incorrectable to the user.

bigman wrote:(bug) due to the restrictions of the new trim window, user is not able to select exact increments of time to edit from the sample, which now makes this problem virtually incorrectable to the user.

i think this last bit (quoted above) is not needed, because it does not help to identify or resolve any of the 2 bugs. The rest seems just fine to me.

This means that there are now two pretty big bugs, where only one small one used to be.

this is a beta version. while developping it is perfectly normal to have a bit of "1 step forward, 2 steps backward".

Yeah, you're right about the last bit not being clear about identifying or resolving the bug. However, not being able to select exact amounts of time to edit is a problem that should be addressed. I just don't know how to put it, since when I look at (bug 1) now it kind of contradicts the entire new trim windows way of functioning. This is where it gets hard for me explanation wise, because I do like a lot of the changes in the trim window, but I can't get around not being able to select exact amounts of time to edit.

I don't know the best solution to this, maybe what I said before would work, or maybe it could have the (shift+<or>cursor) select the next digit up/down as it did in the old trim screen. Or not, since I suspect the start and end times are now in sample length rather than old standard min,sec,milisec which makes everything about my trim mode bug suggestion go out the window. This is why I am at a sort of standstill on which way would be the best to get the benifits of all of the new and old sample editing capabilities of trim/loop mode. If you guys could test it out and post which way you think would be best, that would be great.

I know it is a dicey process beta testing, but since he labeled the track 61-64 problem as fixed in the notes, it created a bit of urgency to identifying this new issue so he wouldn't just write it off as fixed and move on to all the other bugs. Also, things are not only being fixed or bug corrected in the later betas, but entire new layouts to pages (like trim and loop) are being introduced for the first time, which gives them a disadvantage in comparison to other features introduced in earlier betas, since their bugs/problems havent been able to be identified or commented on until now and effect other bugs/problems in a negative way.

One last thing (sorry to go off topic), but I don't think the 2500 manual really covers a lot of what is being implemented here as the site says. The direct recording feature is completely different as well as trim/loop, grid edit, etc... If someone is in contact with the author, could you ask them if they are planning on releasing an english manual or 2500 manual addendum for the release version of 3.0? Otherwise, some of these great new features could go overlooked.

deep

This might be a bug:

If sync 1 is on and my pc's sequencer is controlling the stop and start of the mpc, the mpc plays fine. If I hit play on the mpc it plays the sequence twice as fast. When I turn sync 1 off, the mpc plays at normal speed. Essentially, the mpc plays twice the internal tempo when sync is on and play is engaged on the mpc. If off, it plays fine.


Anyone having this problem?

s

bigman wrote:A new bug has spawned from an old bug. The track 61-64 sample time problem has been attempted to be corrected and improved in this beta according to the bug fix notes, but the end result is now worse.

Here's what is going on. I loaded beta 11 and immediately went to track 61 to see what has been changed or fixed. I set my recording preferences (tr+window), set the bars to 2 and the tempo was left on 120. I then pressed overdub and play start to begin recording.

The first improvement I noticed was that when you press overdub or record, a small window pops up on the screen telling you your selected recording input(s) and the name of the take that is about to be recorded. After engaging record, I waited for the 1 bar count in and played guitar for four bars instead of two. This is where the second improvement comes in, the MPC now asks if you would like to change the bars of the sequence to match the bars of recorded material, or leave it alone to loop at whatever amount of bars you already have set.

Now here is the bad part, the sample records the count in period and still has the small bit of extra time that created the original problem. So, when you play back your phrase it now comes in 1 bar and about 1/8 note late. What makes this worse still is that the new trim window does not let you easily select exact amounts of time to discard in order to work around this.

This means that there are now two pretty big bugs, where only one small one used to be. So, here are the preliminary bugfix reports I am planning to send to the author. I am posting them here first to see if anyone has any suggestions to more clearly state the problems so they can get fixed properly.


Bug 1:

1 power sources ON→ (unused) selecting the sequence
2 enter trim mode (Mode+Pad6)
3 (problem) user cannot select numeric entry
4 (problem) user cannot select increments of movement without zoom
5 (problem) zoom and increment level are not standard, but dependant on sample length
6 (problem) zoom in and out are inconveniently located if needed to edit properly, zoom in and out should also be selected by using (shift+<cursor = zoom out) and (shift+>cursor = zoom in)


Bug 2:

1 power sources ON→ (unused) selecting the sequence
2 select track 61-64
3 set recording preferences in (Tr:+Window)
4 press record using (rec+play start) or (overdub + play start)
5 after metronome counts in, record a take and press (stop) when finished
6 press (play start) to replay take
(bug) recorded take has count in time as well as the original small gap (approx 00.011.700) included in the sample
(bug) due to the restrictions of the new trim window, user is not able to select exact increments of time to edit from the sample, which now makes this problem virtually incorrectable to the user.

Dang.. i FINALLLY got track recording to work for me!
with my tables.
all other versions were all wacky when id try it. ive tried so many different ways i was discouraged... i decided to try again with beta 11. walla!
no delays.

EDIT>>>> EHHHHH... its being goofy again.

Stokes,

I tried to recreate this problem, but sync worked okay when I did it. Im going to run over what I did, to see if I recreated it correctly.

1. plugged midi in 1 of the MPC to my midi interfaces (motu fastlane usb) out port 1.
2. I set midi sync in to 1 on the mpc and left sync out alone
3. I loaded a drum kit and recorded a simple 2 bar drum pattern on the MPC on track 1
4. I used the program Ableton Live 5.2 and set that to sync the mpc to.
5. I set both Ableton's and the MPC's tempo's at 120bpm.
6. I pressed play on Ableton and the track played back fine
7. I stopped Ableton and pressed play on the MPC and it also played back fine.
8. I then tried other combos like pressing play on the mpc while still sync'd to Ableton as well as alternated between pressing play and play start with the same steps as above (Also, while doing this I did notice play start resets the sequence, but ignores where in the the counter is, hopefully syncing with MTC will fix that).

I did not get this bug, could you describe what program, midi interface, etc.. you are getting this problem with so we can pinpoint what is wrong and if it is a bug?

Anyone experienced that? Loaded a project and can't scroll through the samples in trim mode, plus the sample list in trim mode shows weird artifacts sometimes (can't scroll here, either). When I load a new sample or just make a copy of the one that's displayed, everything works again fine. I guess this one can't be reproduced in general cause someone would've posted it before. But on my MP it happens with all the projects all the time. Anyway:
1. Load a project file
2. Go to TRIM screen
3. Can't scroll through samples, sample list window messed up sometimes
workaround: load a new sample or make a copy of a loaded one

And I have to say again I don't like the new trim screen a bit. The old one was fine, and I've no problems with new chop options (though I've never used slice), but the operating is a mess imo.
Peace

japspecvr6 wrote:not a bug but .........could he throw this in.........indivdual tracking........not like that left right ****...........1. 2. 3. 4............just like the 2.5k does at the mixer page...... .........thanks

hasnt that already been implemented??
i mean.. im tracking right now from 1. 2. 3. 4. not any panning crap you were mentioning. i love this new lil feature.

Wow H-Mann, that is a nasty one, good catch. When I went to recreate it, I noticed this bug occurs with loaded project files, but loading programs themselves or even a whole folder of programs does not do this. The sample list window screwing up when the sample is locked looks trippy with all that jibberish on the screen. I also noticed this window was locked from scrolling through samples as well. When trying your workarounds, I found that the extract feature also cures this as well as the copy, or load methods.

I think this is good that we are catching all of these bugs and we should keep listing the problems the in the bugfix format like this after explaining them, since whomever caught it can probably make the most sense out of it. Otherwise, someone is going to get stuck with the tedious job of trying to interperet and translate all of the listed problems into bug report format to submit to the author. And a translation of someone elses description of a problem/bug into another format, which then goes to a person that speaks mainly Japanese is just asking for something to be misunderstood (and not fixed).

**EPC, that's cool, I never noticed the 1.2.3.4 thing being there until you just posted it. I think it's in the 2500 manual, but like I said I really hope for a 3.0 specific document, so we don't have to decipher what is different or not from the 2500 for each feature.

Bigman, seems like you're doing it the right way. I wonder if it's a Sonar thing. Trippy thing is that it use to do this on 2.1 but only the first time you hit play on the mpc after hitting play on the computer. The second time you hit play on the mpc it would play back fine. I'll take a deeper look tonight. Thanks for taking a look at this.