v1.6 bug reports

DJ Hellfire wrote:I'm telling you how the system works. There is no bug. You just don't understand what Shift Timing is. Pete has no idea what you are talking about. I asked. What I'm telling you is the way it works. The fact that it's unclear is another issue. But this is the way it works and is designed to work! Period!

Did you ask what the 96ppqn setting was designed to do, the purpose of it's inclusion in the software, why you would want to display it at 96ppqn but still have the sequence timing running at 960ppqn, why you would want to have some functions operating at 96ppqn and others at 960ppqn simultaneously, etc.?


If you do ask that, could you also please ask about the Latency Adjust parameter, what is it designed to do, why was it added, where exactly does it adjust the latency, what does it affect, etc.?

SimonInAustralia wrote:

DJ Hellfire wrote:I'm telling you how the system works. There is no bug. You just don't understand what Shift Timing is. Pete has no idea what you are talking about. I asked. What I'm telling you is the way it works. The fact that it's unclear is another issue. But this is the way it works and is designed to work! Period!

Did you ask what the 96ppqn setting was designed to do, the purpose of it's inclusion in the software, why you would want to display it at 96ppqn but still have the sequence timing running at 960ppqn, why you would want to have some functions operating at 96ppqn and others at 960ppqn simultaneously, etc.?


If you do ask that, could you also please ask about the Latency Adjust parameter, what is it designed to do, why was it added, where exactly does it adjust the latency, what does it affect, etc.?

I'm guessing that Latency Adjust parameter will adjust your incoming signal latency by milliseconds. I was playing with it one day. It seems to correspond with the amount of latency you are getting in milliseconds and changes according the the value you enter. You can try adjusting it and see if your getting any less latency when you strike the pads.

SimonInAustralia wrote:

DJ Hellfire wrote:I'm telling you how the system works. There is no bug. You just don't understand what Shift Timing is. Pete has no idea what you are talking about. I asked. What I'm telling you is the way it works. The fact that it's unclear is another issue. But this is the way it works and is designed to work! Period!

1. Did you ask what the 96ppqn setting was designed to do, the purpose of it's inclusion in the software, why you would want to display it at 96ppqn but still have the sequence timing running at 960ppqn, why you would want to have some functions operating at 96ppqn and others at 960ppqn simultaneously, etc.?


2. If you do ask that, could you also please ask about the Latency Adjust parameter, what is it designed to do, why was it added, where exactly does it adjust the latency, what does it affect, etc.?

1. Yes, I did. And I have explained it severval times in this thread as well. It is merely for NUDGING RECORDED NOTES at 96 ppqn, nothing more. Not for sequencing and not for any kind of quantizing (including Swing and Shift Timing). It's only effective when you nudge notes with your keyboard arrow keys or from the nudge button in the list editor on the hardware. This is specifically what it was added for.

As for why it was added, it was added as a part of the list editor addition in 1.5. The list editor was supposed to be in 1.5 but was delayed because of issues. This is why the setting made it into 1.5 and the actual list editor didn't come until 1.6.

Why you would need this? My guess is for those that want to nudge notes a farther distance faster. You can nudge notes a larger distance quicker at 96 ppqn than you can at 960 because it's a much coarser adjustment. It's like chipping off a block of ice with an ice pick vs grinding away the ice with a a belt sander. Some people may finding nudging at 960 to be very tedious and time consuming, especially when they don't care about having that much detail in note movement. So 96 was added to help speed up the process and still keep things in the same timing/groove that older MPC's had.

2. I didn't ask but I know what it does. Latency adjust is simply to compensate for the latency added by your actual hardware/interface going out to an external piece of hardware gear and back into the MPC or simply put, the D to A -> A to D round trip process. An example would be when going out to an external eq or compressor from the MPC and coming back into the MPC to monitor the processed signal in real time. That trip causes an audio delay which is a commonly known issue in audio recording. So this is bascically like a manual delay compensation for external processing.

Is this option needed? Not for me. I never have to touch it. I don't use external gear, but many guys still do. So this is just a little something to help keep the audio in alignment after the conversion process.

DJ Hellfire wrote:

2. I didn't ask but I know what it does. Latency adjust is simply to compensate for the latency added by your actual hardware/interface going out to an external piece of hardware gear and back into the MPC or simply put, the D to A -> A to D round trip process. An example would be when going out to an external eq or compressor from the MPC and coming back into the MPC to monitor the processed signal in real time. That trip causes an audio delay which is a commonly known issue in audio recording. So this is bascically like a manual delay compensation for external processing.

It can also help lower latency for slower computers that have to run higher buffers. But it doesn't work miracles!

So this has nothing to do with latency of the pads being struck and the time it takes for sound getting triggered?

It only effects latency related to the external ins and outs on the mpcs interface? Not the internal sound of the software? Don't know if I'm explaining this right, u understand what Im asking right?

Just repeating on what Simon said, but Hellfire I know you explained but could you please (on your free time, whenever you're not busy) if you get the opportunity to speak or double check with anyone at Akai, can you ask if Latency Adjust affects latency time between pad strikes and sound getting triggered? I thought thats what it was related to, also, if its not related to pad strikes/sound output latency than what exactly is the latency between a pad getting hit and the sound outputting on the Renaissance? I know on hardware mpcs, the pads latency were almost nothing, like 2-5ms, but what about on the Ren Software? I really thought that Latnecy Adjust had to do with the time in between hitting the pads and getting sound back

InspectahEX wrote:Just repeating on what Simon said, but Hellfire I know you explained but could you please (on your free time, whenever you're not busy) if you get the opportunity to speak or double check with anyone at Akai, can you ask if Latency Adjust affects latency time between pad strikes and sound getting triggered? I thought thats what it was related to, also, if its not related to pad strikes/sound output latency than what exactly is the latency between a pad getting hit and the sound outputting on the Renaissance? I know on hardware mpcs, the pads latency were almost nothing, like 2-5ms, but what about on the Ren Software? I really thought that Latnecy Adjust had to do with the time in between hitting the pads and getting sound back

Yeah, I'll ask.

Ask for the Ren's pad latency, when it was first announced, Dan said the goal was to get to 2ms and that the guarantee was to be no higher than 5ms, and he said that was successfully achieved with the "ultra highspeed midi driver"!

the latency of hitting the pads to actually hearing the signal is only adjusted by the buffer size. If you want < 5ms latency, you should pick a buffer size of 64 samples.

The latency adjust is the number of samples between incoming and outgoing audio signal. This is so you can record audio better, in sync with your sequence, and/or sync audio to midi.

HouseT wrote:Ohhh ok, so the latency of the pads is fixed to a set amount between 2-5ms regardless of any settings, thats good to know. Hopefully its true.

No, pad latency is based on your Audio Buffer setting. 2-5ms would be based on your lowest buffer setting your computer can handle. If you raise the buffer, your pad latency will increase!

Thanks, I understand 100% now thanks for clearing that up, I totally forgot that buffer size was separate from the latency adjust, its the weed

Pete, do you guys plan to fix that small issue where shift timing does't correctly honor the 96ppq resolution? Or like Hellfire said, has it been decided that it will remain how it is, or that its working as intended? Im confused on this one whether it supposed to be like that or not?

InspectahEX wrote:You are completely wrong. This is not how it's supposed to work. When you dial in "100" and it shifts "10" that is a bug.

Going back to this though! 100 @ 960 ppqn = 10 @ 96 ppqn. Remember, you are just dropping a 0 off when switching to 96. So a note at 01:01:100 on 960 is equal to a note at 01:01:10 on 96.

So it seems the issue you are having is just an issue of the display not removing the 0 so you can quickly shift to :10. But the actual note placement is the exact same. Currently, when you dial in 10 in shift timing, it is actually :010. So this is why you have to dial in :100 to get :10. Is this what you are referring to?

InspectahEX wrote:Pete, do you guys plan to fix that small issue where shift timing does't correctly honor the 96ppq resolution? Or like Hellfire said, has it been decided that it will remain how it is, or that its working as intended? Im confused on this one whether it supposed to be like that or not?

fixing it right now. It's just a display issue, but should be consistent with other pulse displays

Sometimes when I open the browser to audition the samples in my folders, they're not there. This happens after I have been on the MPC for a little while. I have to save my work and restart the program once or twice for them to reappear in the browser.

I'm on 1.6; Windows 7; AMD Processor

dazastah wrote:When trying to assign an effect in the qlink page to a qlink that has been inserted on track , the data wheel doesn't work to assign the effect, but data + and - buttons work.

Although you can see it on the hardware, the change doesn't actually happen on the software..

It only does the change via software/mouse..

I'm getting this too

Windows 8.1 64bit

Mpc studio (software/firmware updated and current)

When I go to shut down / close the program it stops responding. Kind of annoying because when I restart the program I am unable to load anything recent (because there is no recent projects in there) and I've gotta "end task" to turn the software off.

It also "forgets" the settings (eg: midi controller) when this happens as well.

Anybody else having this issue?

::::::::Update::::::::

....So, I went and copped jbridge (for an unrelated reason - I use Cubase as my main DAW and from time to time I'd get an annoying vst bridge error) so I wanted to fix that so all of my vsts would work without issue and somehow -I'm not sure if its related - but all of the sudden the mpc studio NOW shuts down normally.