How do I swap L and R?

Maldon wrote:

Straker wrote:What's wrong with you, my friend?
You can duplicate your track as many times you want on MPC3, no need to complain for how they change the structure.
You are a cry baby.

For this precise subject, try duplicating a drumsynth plugin track and you'll see. And try organizing your tracks to use them as mute tracks, for example drum in pad 1-5-9-13 etc...
The MPC 3 isn't perfected at all yet (and that's normal, it's a beta). Complaining about the “one track one program” or the various midi bugs is justified, but complaining about a L R inversion when it's perfectly possible to do it by taking 30s of your time is ridiculous. You know the eternal victims: it's everyone else's fault, it's shameful that the mpc doesn't do this or that.

You're really sarcastic and you're not capable of respecting people who offer you solutions... If you're not happy with your MPC, take an Octatrack or a Maschine and you'll see that despite its MANY problems, the MPC really is an exceptional tool.

Translated with DeepL.com (free version)

Man, sorry if I have been rude but your workaround (thanks for explaining it) means stopping the flow and diving into sample edit.
As I said before, and I am sorry I have not been clear, I need to be fast and mix while music keeps going.
Thanks anyway, I try to see if your workaround works without stopping the playhead.
I also don't like that they changed the structure, I have many projects with a single program spread on different tracks.
And I tried mpc3 beta for 2 hours, so many bugs, my old projects didn't load smoothly, track mutes settings and qlink assignments in project mode were lost, opx4 got unauthorized, it crashed 4 times.
So I switched back to 2.15.1
And I really like it, it's flawless and I am appreciating it a lot, beside this LR inversion omission.

[/quote]
Man, sorry if I have been rude but your workaround (thanks for explaining it) means stopping the flow and diving into sample edit.
As I said before, and I am sorry I have not been clear, I need to be fast and mix while music keeps going.
Thanks anyway, I try to see if your workaround works without stopping the playhead.
I also don't like that they changed the structure, I have many projects with a single program spread on different tracks.
And I tried mpc3 beta for 2 hours, so many bugs, my old projects didn't load smoothly, track mutes settings and qlink assignments in project mode were lost, opx4 got unauthorized, it crashed 4 times.
So I switched back to 2.15.1
And I really like it, it's flawless and I am appreciating it a lot, beside this LR inversion omission.[/quote]

Yes, it's a bit of a flow breaker to go fiddling around in "SampleEdit”, but think of it as sample preparation, like when you chop a sample, for example.
I certainly took offence a bit too quickly, thinking that you didn't give a damn about my solution and that you were just grumbling, so excuse me again and let's move on.
The MPC (new versions) frustrated me for many years, and I also found certain “oversights” unacceptable, even though there were workarounds that required several time-consuming actions.
But now, the MPC has become my main tool for creating music, and I can plug in all my synths and drum machines via USB. There are plenty of plugins that are quite qualitative, And let's not forget that all updates are free for now.
In a word, long live MPC, and see you soon on the forum.

Yeah, same for me, MPC is my main tool for composing, and it started to be since a couple of years, before that it was unreliable.
I really think that with 2.15 it reached its potential, it took 7 years, but here we are.
A lovely box where you have all you need inside and I have to admit that this CPU/RAM is enough for me, so it's very well optimized.
My fear is that, after 7 years of development and after we finally have a working multipurpose music box, now we are going to another painful process with MPC3 to solve bugs, I hope it really won't be like MPC2 process, I hope Akai learned to speed up the development and make a flawless MPC3 soon.
Yeah, we'll meet here, thanks for replying.

Speed and Flawlessness...is going two different directions...

Patience!!!

As far as coding is concerned, if it were so easy to “add a few lines of code”, there wouldn't be any bugs for a long time.

As a SW Dev, THIS!

It's crazy how often something appears rather simple on the surface, but then you dig into it and it takes days to implement. Yeah, it's all 1s and 0s, but sometimes you spend a week to figure out which 1 to change to 0.

JacobH wrote:

As far as coding is concerned, if it were so easy to “add a few lines of code”, there wouldn't be any bugs for a long time.

As a SW Dev, THIS!

It's crazy how often something appears rather simple on the surface, but then you dig into it and it takes days to implement. Yeah, it's all 1s and 0s, but sometimes you spend a week to figure out which 1 to change to 0.

Channel swap?
Come on.

Channel swap?
Come on.

Just FYI even an obvious feature would require designs for the icons its using (most likely going through at least a few designs), small decisions on where in the list of processes to put it, discussions on product level to fully clarify the feature, discussions to align priorities among stakeholders and when/if it should be implemented.

Also regarding code - depending on how it's structured sometimes obvious things could take a week or weeks.
Regardless of all that when one adds new feature also a set of tests needs to be implemented as well which can be also not as trival as one would think depending on the architecture. Assuming desktop software should be compliant it could be that two separate codebases should be updated by most likely two separate teams.

On edge case front - when working with larger files such operation could introduce out of memory issues if data needs to be copied (just hypothetically).

I'm not saying it's easy/not easy - 99% of cases it's not as easy as one would think.

handthrow wrote:

Channel swap?
Come on.

Just FYI even an obvious feature would require designs for the icons its using (most likely going through at least a few designs), small decisions on where in the list of processes to put it, discussions on product level to fully clarify the feature, discussions to align priorities among stakeholders and when/if it should be implemented.

Also regarding code - depending on how it's structured sometimes obvious things could take a week or weeks.
Regardless of all that when one adds new feature also a set of tests needs to be implemented as well which can be also not as trival as one would think depending on the architecture. Assuming desktop software should be compliant it could be that two separate codebases should be updated by most likely two separate teams.

On edge case front - when working with larger files such operation could introduce out of memory issues if data needs to be copied (just hypothetically).

I'm not saying it's easy/not easy - 99% of cases it's not as easy as one would think.

I think my Commodore64 in 1984 had the chance to swap channels with a simple code in basic.
I mean, ok for the icon or whatever, it's just reverse left and right.
The first thing any coder codes in a multitrack, it's just very surprising to see this sort of omissions in a modern multitrack.
I think it's the only multitrack in 2025 to have no channel swap.