Help with 1-to-many MIDI mapping: Assigning a parameter to a Named CV crashes system

Patchbox OS MODEP
1

Hi everyone,

I’m struggling to get a 1-to-many MIDI mapping working in the current version of MODEP and could really use some advice.

My Goal: I want to use a single physical expression pedal (via MIDI CC) to control multiple parameters across different plugins at the same time, while also being able to set custom minimum/maximum ranges and inverted sweeps for each parameter.

The Problems I’m Hitting:

  1. Standard MIDI is 1:1: Standard MIDI mapping limits me to assigning the CC to only one parameter.

  2. Assigning Named CVs causes a crash: I tried using the “Control to CV” plugin to split the signal. I can successfully create a Named CV port without any issues. However, the exact moment I go into a target plugin (like a Wah pedal) and assign its control parameter to that Named CV, the system instantly crashes and the UI disconnects.

  3. The old patch doesn’t fix it: I found the old thread about the fix-cv-segfault.patch for mod-host. I cloned the repo, applied the patch, and compiled it from source. The patched mod-host runs perfectly fine, but it doesn’t actually fix the error—the system still crashes at the exact same moment when I try to assign the CV to a parameter.

My Question: Is there a current, working workaround to achieve 1-to-many MIDI mapping in the current build of MODEP?

Has anyone found a way to stop the Named CV assignment from crashing the system, or is there an updated mod-host patch floating around that removes the hardcoded 1:1 MIDI limit?

Thanks in advance for any help!

Attempting to assign CV from Random LFO crashes server
2

I pulled the journalctl logs and caught the crash: Main process exited, code=killed, status=11/SEGV

I also attached gdb to the running mod-host process and caught the backtrace when triggering the crash via the web UI. It is failing directly inside the JACK library:

Plaintext

#0  0x00007fffb5357124 in ?? () from /lib/aarch64-linux-gnu/libjack.so.0
#1  0x0000555644df3248 in ?? ()
#2  0x0000555644df564c in ?? ()
#3  0x0000555644df6800 in ?? ()

It looks like mod-host is passing a bad pointer or invalid port ID to JACK when it attempts to route the Named CV assignment.

3

Try building and running a debug build of mh-host. The repo is here:

Build it like this:

make DEBUG=1 -j4

Then it’s probably easiest to just replace /usr/bin/mod-host with the binary you built and restart the modep services.

4

Hey Giedrius and thanks for the reply. I did that and i got the following result:

It seems to be a segfault in libjack, backtrace explicitly points to line 7142 in src/effects.c inside the effects_cv_map function.

It looks like the smoking gun is value_max = 0x0. A NULL pointer is being passed to JACK.

Here is the full backtrace:

Plaintext

#0  0x00007fff3ed17124 in ?? () from /lib/aarch64-linux-gnu/libjack.so.0
#1  0x0000555617786948 in effects_cv_map (effect_id=19, control_symbol=0x555639c3801a "fslider1_",
    source_port_name=0x555639c38024 "effect_20:Cvoutput", minimum=0, maximum=1, mode=0x555639c38049 "+")
    at src/effects.c:7142
        value_min = 0x555639e50ae0 "0.000000"
        value_max = 0x0
        uuid = 4294967370
        op_mode = 43 '+'
        source_jack_port = 0x49
        effect = 0x5556177b4730 <g_effects+15352>
        port = 0x555639d54250
        cv_source = 0x555639e568a0
        jack_port = 0x4a
        cv_source_to_delete = 0x0
        source_is_mod_cv = false
        source_has_ranges = false
        source_min_value = -5
        source_max_value = 5
        source_diff_value = 3.06127663e-41
#2  0x000055561778abd0 in cv_map_cb (proto=0x7ffffe0334b8) at src/mod-host.c:399
#3  0x000055561778c458 in protocol_parse (msg=0x7ffffe033518) at src/protocol.c:216
#4  0x000055561778cff8 in socket_run (exit_on_failure=0) at src/socket.c:363
#5  0x000055561778bb4c in main (argc=5, argv=0x7ffffe0337d8) at src/mod-host.c:861

Thanks for the help.

5

jack_get_property is supposed to be fine with NULLs.

It looks like the crash happens in between getting the minimum and maximum values, as minimum does get initialized by jack_get_property.

Looks like Debian has some options to get a better backtrace. I haven’t tried this myself, but I think it could work, as Raspberry Pi is using Debian APT servers directly. Try setting this environment variable before gdb:

export DEBUGINFOD_URLS="https://debuginfod.debian.net"

and then run gdb like before.

Here’s some more info.