MPC 3 -- Let's GO!!

Yes, if you go for that method you have two independent copies of the original kit, so if you make changes to the snare on track 2 it will not change the snare on the pad in track 1 (unless it's at 'sample edit' level). Equally if you change the kick on track 1, the track 2 kick is unchanged.

If you subsequently want to export this as a new kit (with all the individual pad changes) to re-use in other projects you'll have to merge/copy the tracks together and then 'save as drum program'. You could do this on a 'spare' track.

Alternatively: load the kit to track 1, create new drum track (track 2) and use 'send to' to send the midi from track 2 to track 1. Use track 2 for your kick events. Repeat for snare with a new drum program on track 3. The kit is only on track 1, so only 1 kit to manage, but with added complication as you'll need to switch tracks depending on the type of task you need to carry out.

Alternatively: load the kit to track 1, work on it and explode tracks at the end of the process. Track 1 contains the 'master kit' to be used for exporting.

So what I'm asking is what is the alternative suggestion that still retains the concept of an assignable program from a pool of programs? How specifically will that work? If you can come up with some ideas, I could submit this as a feature suggestion directly via the beta system.

LivePsy wrote:

MPC-Tutor wrote:Genuine question for everyone asking that programs to return, what is your suggestion on how that would work within the unified track concept (because I don't see how Akai are going to roll back on unified tracks given MPC3 is centered around this)....

Just for the dummies like me:

One program has kicks and snares
Track one is the kick on each beat, say C2
Track two is the snare on 2 and 4, say D2

Is this 2 independent copies of the original kit? If you make a change to a snare then you have to keep track of which kit if you want to save for the future?

eLuSiVeMiTe wrote: But I build a whole track in a single looped seq with multiple copies of programs keygroups and plugins and have all core elements in place before I copy out sequences. Once linked in song mode I can then edit individual sequences for builds and fills etc before converting to a long sequence for automation recording

Yes mpc3 is unlikely to have too much impact on that IMO, other than if you like having the same program on multiple tracks, in which case you'll need to get used to either duplicating/exploding the original kit or using send to depending on your requirements.

But in many cases having the same kit loaded multiple tracks is no different to the mpc2 method, as you were likely already effectively treating these as different programs.

For example let's say you have a kit with a mixture of drums and melodic one shots (e.g. typical factory kit), with track 1 using the kit for drums (pads A1-A8), and track 2 using the kit for 16 level bass (bass one shot on pad A13).

In mpc3 you would likely just duplicate the kit over the two tracks and then make edits to each kit independently, But that mostly doesn't matter (in terms of pads) as the track 2 drums pads are not ever going to be used on track 2, so who cares if they are no longer the same as those on track 1. You could even just delete them (which is what happens when you explode a track)

The difference is (off the top of my pre-morning coffee head) mostly down to insert fx (that is, if you had any across the original kit, e.g. a compressor). If so you'll need to get used to instead routing these 'same kit' tracks to the same submix and apply the inserts to this instead.

MPC-Tutor wrote:Alternatively: load the kit to track 1, create new drum track (track 2) and use 'send to' to send the midi from track 2 to track 1. Use track 2 for your kick events. Repeat for snare with a new drum program on track 3. The kit is only on track 1, so only 1 kit to manage, but with added complication as you'll need to switch tracks depending on the type of task you need to carry out.

Ableton Live works just fine this way with multiple midi tracks to a drum rack. Is selecting a program really any different to 'send to'. I don't think so.

LivePsy wrote:

MPC-Tutor wrote:Alternatively: load the kit to track 1, create new drum track (track 2) and use 'send to' to send the midi from track 2 to track 1. Use track 2 for your kick events. Repeat for snare with a new drum program on track 3. The kit is only on track 1, so only 1 kit to manage, but with added complication as you'll need to switch tracks depending on the type of task you need to carry out.

Ableton Live works just fine this way with multiple midi tracks to a drum rack. Is selecting a program really any different to 'send to'. I don't think so.

Main difference is that programs can't be hidden in the pool. Now all programs are out in the open a drum tracks. Also, if you reordering tracks you may have update the MIDI send info.

It would be more efficient if there was still the program pool to keep them hidden, but each program could be assigned a unique pc number & we could have each track load/MIDI send any PC#. This will allow for different sequences to have a different programs on the same track. Since each track is plays the pc# it was assigned to. I think I use to do that on the 2500. What do think Tutor?

@B-Wise Good idea on the Program change method, I use that all the time with my TR-6S for changing kits and patterns.

KaoticShock wrote:@B-Wise Good idea on the Program change method, I use that all the time with my TR-6S for changing kits and patterns.

Thanks I use it for TR-8S so I can relate. It's a cool simple way to switch things up & the tracks (& each clip on the Force) can have its own PC, MSB & LSB data already for selecting patches on external synths. Akai needs to use it for its internal programs.

Hey Tutor! Really appreciate the detail breakdown and explanations. From what you’re describing MPC3 won’t be that drastic of a change from my workflow. But I completely understand how it can be a problem for others

MPC-Tutor wrote:So what I'm asking is what is the alternative suggestion that still retains the concept of an assignable program from a pool of programs? How specifically will that work? If you can come up with some ideas, I could submit this as a feature suggestion directly via the beta system.

The feature that retains the concept of assignable programs from a pool of programs is: assignable programs from a pool of programs. To make the idea easier for marketing I'll call it: the Program Rack or Rack Programs. Like in Cubase, there is a pool or "rack" of VST Instruments called the VST Instrument Rack, and then there are MIDI tracks that can be routed to the instruments. BUT there is ALSO a newer thing called Instrument Track. Steinberg made almost the same thing as MPC3's hiding of programs. At some Cubase version I forgot when, they added a new track type Instrument Track which is a glued-together MIDI track and that track's "own" VST instrument. BUT they still kept the VST Instrument Rack there and supported that workflow as well. I think there's no way around this - bite the bullet, show a Program Rack or whatever and support it in the user interface. I'm pretty sure the separation of track and program is still there under the hood, it's only hidden in the user interface.

MIDI tracks would be routable to programs in the Program Rack, and this routing would be per-sequence. Just like track mutes should be per-sequence.

To support automation of program parameters, the sequencer/arranger/whatever would either need to support automation-only tracks for programs in the Program Rack, OR it should be able to dynamically show the automation lanes of the Rack Program to which a MIDI track is routed, alongside the MIDI track. In case of automation-only tracks, the arranger should preferably support grouping and folding of tracks. One such foldable virtual track would show Rack Programs, so that one could draw automation, without any accompanying MIDI event track.

For comparison, here's a random video I found that shows the differences between Rack Instruments and Instrument Tracks in Cubase.



If you listen to the explanation about the pros of Rack Instruments, it's pretty much spot-on exactly what people have been doing with assignable programs in MPC2. IMO.


Disclaimer: that was written by someone who no longer has an MPC.

Nice, I've forwarded this to Akai

HouseWithoutMouse wrote:The feature that retains the concept of assignable programs from a pool of programs is: assignable programs from a pool of programs. To make the idea easier for marketing I'll call it: the Program Rack or Rack Programs. Like in Cubase, there is a pool or "rack" of VST Instruments called the VST Instrument Rack, and then there are MIDI tracks that can be routed to the instruments. BUT there is ALSO a newer thing called Instrument Track. Steinberg made almost the same thing as MPC3's hiding of programs. At some Cubase version I forgot when, they added a new track type Instrument Track which is a glued-together MIDI track and that track's "own" VST instrument. BUT they still kept the VST Instrument Rack there and supported that workflow as well. I think there's no way around this - bite the bullet, show a Program Rack or whatever and support it in the user interface. I'm pretty sure the separation of track and program is still there under the hood, it's only hidden in the user interface.

MIDI tracks would be routable to programs in the Program Rack, and this routing would be per-sequence. Just like track mutes should be per-sequence.

To support automation of program parameters, the sequencer/arranger/whatever would either need to support automation-only tracks for programs in the Program Rack, OR it should be able to dynamically show the automation lanes of the Rack Program to which a MIDI track is routed, alongside the MIDI track. In case of automation-only tracks, the arranger should preferably support grouping and folding of tracks. One such foldable virtual track would show Rack Programs, so that one could draw automation, without any accompanying MIDI event track.

For comparison, here's a random video I found that shows the differences between Rack Instruments and Instrument Tracks in Cubase.

If you listen to the explanation about the pros of Rack Instruments, it's pretty much spot-on exactly what people have been doing with assignable programs in MPC2. IMO.


Disclaimer: that was written by someone who no longer has an MPC.

MPC-Tutor wrote:Nice, I've forwarded this to Akai

HouseWithoutMouse wrote:The feature that retains the concept of assignable programs from a pool of programs is: assignable programs from a pool of programs. To make the idea easier for marketing I'll call it: the Program Rack or Rack Programs. Like in Cubase, there is a pool or "rack" of VST Instruments called the VST Instrument Rack, and then there are MIDI tracks that can be routed to the instruments. BUT there is ALSO a newer thing called Instrument Track. Steinberg made almost the same thing as MPC3's hiding of programs. At some Cubase version I forgot when, they added a new track type Instrument Track which is a glued-together MIDI track and that track's "own" VST instrument. BUT they still kept the VST Instrument Rack there and supported that workflow as well. I think there's no way around this - bite the bullet, show a Program Rack or whatever and support it in the user interface. I'm pretty sure the separation of track and program is still there under the hood, it's only hidden in the user interface.

MIDI tracks would be routable to programs in the Program Rack, and this routing would be per-sequence. Just like track mutes should be per-sequence.

To support automation of program parameters, the sequencer/arranger/whatever would either need to support automation-only tracks for programs in the Program Rack, OR it should be able to dynamically show the automation lanes of the Rack Program to which a MIDI track is routed, alongside the MIDI track. In case of automation-only tracks, the arranger should preferably support grouping and folding of tracks. One such foldable virtual track would show Rack Programs, so that one could draw automation, without any accompanying MIDI event track.

For comparison, here's a random video I found that shows the differences between Rack Instruments and Instrument Tracks in Cubase.

If you listen to the explanation about the pros of Rack Instruments, it's pretty much spot-on exactly what people have been doing with assignable programs in MPC2. IMO.


Disclaimer: that was written by someone who no longer has an MPC.

Isn't this kinda like what I mentioned above?: viewtopic.php?f=48&t=218084&view=unread#p1883134

"It would be more efficient if there was still the program pool to keep them hidden, but each program could be assigned a unique pc number & we could have each track load/MIDI send any PC#. This will allow for different sequences to have a different programs on the same track. Since each track is plays the pc# it was assigned to. I think I use to do that on the 2500. What do *you think Tutor?"

Why does the user have to choose whether to load in RAM or stream from disk ? Shouldn't the system manage that transparently and consider RAM as cache, managed with tricks such as preloading small samples, sequencer lookahead and keeping very large samples on disk ?

Letting the user force load in RAM or stream from disk is nice, but most would prefer the default to be the system's reasonable choice.

Looked a bit closer on the program topic and gotta say I don't see the point of still having them. Tracks with now "embedded" programs go across all sequences, other tracks can send MIDI to those first tracks, and in the event that one would want one of those tracks in another project it can be saved on its own. Just gotta delete the MIDI data before so it's ready to start fresh.

Rack programs could be interesting but they would compete with the new track way of encapsulating things. Looking forward to see how things will turn out though, as the overall usability and UI improvements will definitely make me dive back in.

HanHuman wrote:Looked a bit closer on the program topic and gotta say I don't see the point of still having them.

Did Akai make this beta public so people could get angry at the loss of programs then hopefully get over it? In my view, the benefits of identical tracks across all sequences outweighs the loss of programs as a seperate object. And if you want different songs for a complete live session, you can add new tracks for the new song.

LivePsy wrote:And if you want different songs for a complete live session, you can add new tracks for the new song.

It would help if the track count was increased to deal with all the extra drum tracks people will need to load into the project to make up for the lack of a program pool.

LivePsy wrote:

HanHuman wrote:Looked a bit closer on the program topic and gotta say I don't see the point of still having them.

Did Akai make this beta public so people could get angry at the loss of programs then hopefully get over it? In my view, the benefits of identical tracks across all sequences outweighs the loss of programs as a seperate object. And if you want different songs for a complete live session, you can add new tracks for the new song.

You always could have identical tracks across all sequences..
It's not that this is a grand new feature now.
It's a new restriction.
"Act always as to increase the number of choices" -Heinz von Foerster.

So, this is a bad decision.

And there are always workarounds. A work-around and a work- flow are not the same thing.

Like, you can reach any location making left turns only.
But its much more convenient if you are allowed spontanous left and right turns at will.
It seems a bit silly to me to celebrate a restriction to left turns only as a new freedom.

And I am surprised how well marketing via influencer videos works, when people start to welcome restrictions as innovations.