MPC 3.4.1?

HAKAI 3.4.1 version has been released updating as we speak..Let’s check it out the way it should be right in the first place without barriers..
Will check how it handles RAM..

Seems that 3.4.1 version has it’s limits on the default 8 audio/plugins count..On the previous HAKAI Force 3.3.0 OS on the project i was peaking at 75% now I’m getting glitches and hitting 90%..
Guess that OS 3.4.1 is more CPU intensive..

Yes, I've released Hakai version 2025-02-09 yesterday. it is based on MPC firmware 3.4.1. This time around no support for the Force firmware and I might drop it as a whole if Akai doesn't update the Force firmware with any distinctive features..

For this release these are the key features:

*Enabled SSH*
*Removed the max 8 audio tracks barrier*
*Removed the max 8 plugin tracks barrier*

Enjoy!

zangetsu01 wrote:Yes, I've released Hakai version 2025-02-09 yesterday. it is based on MPC firmware 3.4.1. This time around no support for the Force firmware and I might drop it as a whole if Akai doesn't update the Force firmware with any distinctive features..

For this release these are the key features:

*Enabled SSH*
*Removed the max 8 audio tracks barrier*
*Removed the max 8 plugin tracks barrier*

Enjoy!

New findings..on 3.4.1 CPU goes to red beyond 80% after loading/playing 10 plugins at the same time not bad at all…
Thanks!
Had to remove Stage Piano and Stage EP as they were to intensive on CPU/memory..

Yorgos Arabatzis wrote:HAKAI 3.4.1 version has been released updating as we speak..Let’s check it out the way it should be right in the first place without barriers..
Will check how it handles RAM..

Initially Hakai was made to run Force software on MPC; but now that the MPC 3.0 software is live and its basically a merger of MPC software and the Force software, why is there still a need for Hakai?

Regarding CPU, apparently they've changed the way it's reported in MPC3 so it will appear higher compared to MPC2, so unless it's causing actual issues you might want to ignore in the first instance and see what happens.

jpeg wrote:Initially Hakai was made to run Force software on MPC; but now that the MPC 3.0 software is live and its basically a merger of MPC software and the Force software, why is there still a need for Hakai?

Because it removes the 8 audio/Plugins barrier..Simple as that..

MPC-Tutor wrote:Regarding CPU, apparently they've changed the way it's reported in MPC3 so it will appear higher compared to MPC2, so unless it's causing actual issues you might want to ignore in the first instance and see what happens.

I wonder if they've gone the way Ableton does. IIRC Live by default shows you the highest single core load, not the general CPU use. Sometimes you think you're topping out, but its really only one core.. Cubase has a neat one that shows your peaks, your general CPU usage, and the ASIO Guard buffer, and in 14 its got a live graph so you can see when dropouts happen and try to troubleshoot why..

Not sure if its a feature or a bug, but its not mentioned in the manual

A program can only have one Keygroup XL Once you have switched a keygroup into this mode, you can add new keygroups but they will all use the LFO/Filter/Envelope/Mod Matrix settings you applied in the first keygroup..You may switch the other keygroups into Legacy mode where they will all have their own settings, but they will then lose access to the new features in XL. So essentially Keygroup XL is more of a program type than a keygroup type. This description is incorrect

2. In Keygroup XL the standard two LFOs are polyphonic (each voice starts a new LFO). There is a Reset toggle to control whether the LFO cycle retriggers with key or pad presses, however it's almost a moot point since the LFO is not monophonic and thus every key/voice has it's own LFO and there is no way to make them move together in unison.

3. The two Global LFOs are in fact monophonic, and thus if you are looking for a traditional synthesizer LFO to create a vibrato or tremolo effect across the entire instrument, these Global LFOs are the ones to use, they will affect all voices simultaneously.

4. The Global LFOs are also permanently in free-running mode and do not have a reset toggle.

5. Akai have still not implemented a free-running LFO Reset toggle in the legacy keygroups, despite this being a long-standing popular feature request.

6. Because of 5. above, it's still completely impossible to assign a free running LFO to any sample in a Drum Program. You cannot for example attach an LFO to a cymbal sample and make a notch filter sweep around on that sample over time, because Drum Programs are in legacy keygroup mode, and are permanently retriggering. So while the Keygroup XL is welcome, it has made no improvement to modulation limitations that exist in Drum Programs.




also when i solo a track on the main mode screen and change track with the main encoder the solo uses to follow the track im going to. sometimes it unsolos the track and does a weird short animation over the mute button then

This is not a bug report so I'll move it to the main 3.4.1 topic instead. I did respond to you on reddit, but here's my response pasted here as well:

I think one issue is the way people are describing the new set up in respect to envs, filters & LFO. some youtubers talking about how 'if you change the filter on one keygroup, it affects all the others as well', or 'A program can only have one Keygroup XL'. This is not really describing how the new keygroups are constructed and is leading to confusion

Think of it in terms of 'blocks'. An 'advanced' keygroup instrument consists of a 'keygroup block'. This contains all the individual keygroups, where each keygroup is itself a 'block' consisting of sample assignments, layers and config parameters. After the main keygroup block comes the 'filter/env/lfo' block. This acts on the keygroup block as a whole. Then you have the kg stack etc.

[keygroup block] > [env+filters+LFO] >[Utilities] > [KG Stack] > [track FX]

The mod matrix kind of exists outside of all this and can target individual elements within the first two blocks.

In a legacy keygroup, you still had a 'keygroup block' containing individual keygroups and those individual keygroups had all the samples, layers etc. But they additionally each had their own filter/lfo/env. There was no separate 'filter/env/lfo' block that could act on the 'keygroup block' as a whole.

For many instruments, having env/filter/lfo per keygroup was a restriction as more often than not, if all keygroups needed the same settings here (very common) you had to use 'ALL' to adjust together, and automating something across the entire instrument was not possible using keygroups alone (e.g. a filter sweep or adjusting an instrument wide LFO), so you'd need to use FX plugins instead. The new way is much better for this, at the expense of not being able to have different filter/env settings on individual keygroups, excepting what may be possible via mod matrix, or with individual keygroup insert FX (via the pad mixer).

Legacy mode is likely better for some stuff, but generally the advanced mode is really very good, and not just for all the crazy 'synthesis' style examples you are seeing, it's great for more 'traditional' instruments as well

mi03 wrote:Not sure if its a feature or a bug, but its not mentioned in the manual

1. A program can only have one Keygroup XL. Once you have switched a keygroup into this mode, you can add new keygroups but they will all use the LFO/Filter/Envelope/Mod Matrix settings you applied in the first keygroup. You may switch the other keygroups into Legacy mode where they will all have their own settings, but they will then lose access to the new features in XL. So essentially Keygroup XL is more of a program type than a keygroup type.

2. In Keygroup XL the standard two LFOs are polyphonic (each voice starts a new LFO). There is a Reset toggle to control whether the LFO cycle retriggers with key or pad presses, however it's almost a moot point since the LFO is not monophonic and thus every key/voice has it's own LFO and there is no way to make them move together in unison.

3. The two Global LFOs are in fact monophonic, and thus if you are looking for a traditional synthesizer LFO to create a vibrato or tremolo effect across the entire instrument, these Global LFOs are the ones to use, they will affect all voices simultaneously.

4. The Global LFOs are also permanently in free-running mode and do not have a reset toggle.

5. Akai have still not implemented a free-running LFO Reset toggle in the legacy keygroups, despite this being a long-standing popular feature request.

6. Because of 5. above, it's still completely impossible to assign a free running LFO to any sample in a Drum Program. You cannot for example attach an LFO to a cymbal sample and make a notch filter sweep around on that sample over time, because Drum Programs are in legacy keygroup mode, and are permanently retriggering. So while the Keygroup XL is welcome, it has made no improvement to modulation limitations that exist in Drum Programs.




also when i solo a track on the main mode screen and change track with the main encoder the solo uses to follow the track im going to. sometimes it unsolos the track and does a weird short animation over the mute button then

Monotremata wrote:

MPC-Tutor wrote:Regarding CPU, apparently they've changed the way it's reported in MPC3 so it will appear higher compared to MPC2, so unless it's causing actual issues you might want to ignore in the first instance and see what happens.

I wonder if they've gone the way Ableton does. IIRC Live by default shows you the highest single core load, not the general CPU use. Sometimes you think you're topping out, but its really only one core.. Cubase has a neat one that shows your peaks, your general CPU usage, and the ASIO Guard buffer, and in 14 its got a live graph so you can see when dropouts happen and try to troubleshoot why..

Live's CPU Meter does not show the overall system CPU usage or core usage but rather the ratio of the audio buffer playback time to the time taken for processing.

https://help.ableton.com/hc/en-us/artic ... -CPU-Meter

I'm not sure whether the MPC's CPU meter represents this or the overall system CPU usage.

All that a clip type method needs is an option on the drum program to trigger the sample, it’s simple but the sub standard developers that they have employed are unable to do it.
Also have you noticed on track view page the sequence field top left has been replaced with a track field , that means on that page you have 3 methods to change track and no way to change the sequence without leaving the page. What sort of clueless imbecile are we dealing with.

Just got round to using this feature, and....am I missing something regarding tempo automation? Is there any way to write changes in real time rather than manually inserting one by one? I assumed I'd hit 'W' and make changes via a Qlink or changing seq tempo via data wheel but nothing happening.

‘Drawing’ sequence tempo changes in grid view/arranger is impossible as the scale in grid view is not vertically adjustable and covers 0-1000bpm. I just want to draw in a gradual change from 120 down to 50 over 8 bars, but that requires I try to draw, with my finger, within a region approx 2mm high.

I thought maybe draw in a diagonal line from 1000 to 400 and then 'select all' in list edit and reduce all the values down proportionally, but doesn't appear to be a way to 'select all' for tempo automation events (other than shift & tap each one).

Any ideas?

In 2.15, clearing a sequence also cleared its name. Not so in 3.4: clearing a sequence leaves its name in place.

Why that change ? Was it even requested ? It annoys me... But maybe I'm not understanding its benefit ?

Any workaround - besides copying an empty sequence to the one to clear ?

No workaround other than the one you mention. No idea why they've changed this, I did raise this with them but no feedback as of yet.

I'm also really missing the ability to load a sequence into an existing project. I understand why it's 'complicated' (i.e. unified tracks) but I wish they would come up with something , in the same way they had to deal with this with MPC2 project imports containing mixed track structures.