Commented by: rryan
Date: 2015-12-03T17:39:18Z

The reason we removed it is that:

1. It's a usability stumbling block for novice users -- they set up their MIDI through device to have the preset of the controller they plugged in thinking that's how you get a MIDI device setup.
2. Some MIDI through devices send tons of phantom input (no idea why -- never got a machine I could debug it on) and when you load a preset causes the preset to execute CO changes in Mixxx at a high rate -- causing crashes or runaway CPU usage.

So I would suggest adding significant distinguishing UI to the through device that explains what it is and how to use it -- don't just remove the "if developer" preventing it from being shown :).

Commented by: Pegasus-RPG
Date: 2015-12-03T17:52:20Z

Very good points, thank you. (The phantom input would only happen if the Through device was enabled, correct? E.g. just displaying it isn't a problem?)

Commented by: rryan
Date: 2015-12-03T18:04:34Z

Yep, only when enabled. Though users did get stuck in a state where we auto-enable it on startup so Mixxx crashed at startup.

Commented by: rryan
Date: 2015-12-03T18:04:46Z

(i.e. if they enable it once we auto-enabled it again on next boot)

Commented by: markusb
Date: 2018-04-16T10:11:41Z

Just struggled with this again when coming back to Mixxx. I find developer mode overkill to enable midi through.

Could we have a checkbox in the Controller preferences section which enables midi through after a restart ?

This way it does not get enabled to protect beginners, but if you know what you are doing you can enable it there.

Commented by: ronso0
Date: 2021-01-01T16:43:09Z

Can MIDI trough with an command line option "--midiThrough"

Commented by: Be-ing
Date: 2021-01-01T17:00:23Z

How about adding a checkbox in the preferences that exposes it? I think that would be a good balance between making it easy to use for people who want it and not misleading users who shouldn't be using it.

Commented by: ronso0
Date: 2021-01-04T22:41:44Z

btw there may occur many issues when loading a 'regular' controller mapping to the the Through device, like samplers playing on startup and event loops that crash Mixxx.

Commented by: toszlanyi
Date: 2021-01-19T08:33:45Z

Hi guys - any chance a checkbox or --midiThrough option will be added? I also connect QLC+ and by default running the --developer option. This isn't ideal for everyday use. Thanks a lot!

Commented by: daschuer
Date: 2021-01-19T10:12:10Z

I think it is all about finding a contributor who has interests to propose a Pull Request.

Commented by: toszlanyi
Date: 2021-01-19T15:23:20Z

I have interest and would like to change the code, already looked into the task providing the info that ronso shared in https://mixxx.discourse.group/t/using-linux-midi-through-port-0-as-a-controller/21047/5 but I have no idea how to add that --midiThrough option in there.

Another point today was that the sources are not compiling. cmake always stops at the point ... tried with main and latest 2.3 branch

Scanning dependencies of target QtScriptByteArray
[ 16%] Building CXX object CMakeFiles/QtScriptByteArray.dir/QtScriptByteArray_autogen/mocs_compilation.cpp.o
fatal: Referenz ist kein "Tree"-Objekt: faa563f0898b3cbfbd2ed0696deebc8a9b0c9af6
CMake Error at /home/OsZ/Entwicklung/MIXXX/mixxx/build/keyfinder-prefix/tmp/keyfinder-gitclone.cmake:40 (message):
Failed to checkout tag: 'faa563f0898b3cbfbd2ed0696deebc8a9b0c9af6'

So i believe for now the effort is not worth and i keep running Mixxx with --developer option as default. Would be still happy if you can guide me to add --midiThrough as option and would send a PR accordingly

Commented by: daschuer
Date: 2021-01-19T17:22:40Z

Did you update to the latest version of main or 2.3?

Maybe it helps also to delete /home/OsZ/Entwicklung/MIXXX/mixxx/build/keyfinder-prefix

If the issue still exists, you can disable keyfinder by
-DKEYFINDER=OFF
or edit CMakeCache accordingly.

Commented by: daschuer
Date: 2021-01-19T17:28:53Z

The new Flag can be added here:

Commented by: Be-ing
Date: 2021-01-19T17:56:23Z

IMO adding a new command line option would be almost pointless. You may as well keep using --developer. Adding an option somewhere in the preferences GUI would be better.

Commented by: markusb
Date: 2021-01-19T21:14:35Z

Agree that adding a new command line option is not a great solution. That implies that the user has to change the desktop shortcuts manually to invoke Mixxx with this enabled. It is also likely that the change there would be lost with the next update.

A checkbox to expose this is way better !

Commented by: ronso0
Date: 2021-01-20T10:28:48Z

I can confirm #⁠2 that loading existing controller scripts for the MIDI Through controller.
We have no (official) experience how this behaves with other scripts or apps.

Therefore I propose to add the command line switch first so experienced users can test it and we can collect feedback. After we have all issues sorted we can continue to add it to the Preferences incl. additional safety guards for restarts in case a loaded mapping locks up Mixxx (happened to me).

It is also likely that the change there would be lost with the next update.

IMO users that dare to change app launchers are also capable to a) to it again after an update or b) create an additional launcher 'Mixxx MIDI Through' in the first place.
This applies especially because the MIDI switch would be available to 2.4 alpha users anyway.

Commented by: ronso0
Date: 2021-01-20T10:32:41Z

IMO adding a new command line option would be almost pointless. You may
as well keep using --developer.

There is a difference in performance.
I started Mixxx with --developer unintentionally a few times and I experienced buffer issues way earlier than without --developer (same latency, config and hardware setup)

Commented by: eddsalkield
Date: 2021-07-26T20:15:22Z

I submitted a PR to add a --midiThrough argument.
#4148

Comments appreciated!