Toggling effects with python script

Hi all,

as part of a project, im trying to toggle effects states within MODEP with a python script which gets input from ssh CLI/terminal. So far ive been able to create virtual IO’s with the mido library and rtmidi backend (shows up inpatchage) but have no way to connect to the ports from modep.

This is for testing purposes, in the future i want to be able to send and receive MIDI signals from bluetooth. Any help is appreciated!

@Hanoofy first of all, welcome to the forum!

So just to clarify, what do you mean by “have no way to connect to the ports from modep”? Are you trying to send a midi control code from the command line via the Python script? If MODEP recognizes your Python script as a MIDI device then you should be able to click “Assign” on any control then send a CC from your python script. MODEP will respond with a confirmation that the plugin’s control was assigned to the passed CC.

If you’re interested, I wrote an entire Python program that runs on a Raspberry Pi PICO that I embedded into a custom box to send midi CCs to MODEP: MIDIZilla for MODEP

Maybe my project might answer some of your questions.

1 Like

Hi jayTemp! Thanks for the welcome and link to your project!

After creating the virtual ports with python library mido with rtmidi back end, i am able to see the inputs and outputs within patchage. Suppose i created an input and output named virtIN and virtOUT respectively using python line mido.open_input/output(‘name’, virtual=True) both pop up in patchage. However, they arent listed in the MODEP webpage when i click on midi ports on the bottom corner. There is only virtual midi loopback, agg and sep. and finally touchosc listed as the options. I wonder if im missing anything?

“re you trying to send a midi control code from the command line via the Python script?” Correct.

EDIT: my objective for now is to send commands from my phone’s ssh app to my pi so that i can toggle the effects and vary parameters of the amp sim, such as treble bass output etc.

@Hanoofy your question might be a bit over my knowledge when it comes to MIDI ports recognized by MODEP. I think @Giedrius or @Pranciskus might be able to help on this.

You might want to consider downloading one of the Midi controller apps available from your phone’s app store. Early on when I was playing around with sending Midi commands to the Pi I found a couple of apps that I used to control MODEP. I don’t think I ever got them working over bluetooth but I bought a usb to Midi cable that I used between my tablet and the Pi.

@Giedrius can you help me out? Essentially what I want to do is use a python script as a virtual midi controller application which i can use to turn on/off efx pedals and vary amp sim parameters in modep via user input

opt = input()

If “x” in opt:
Send a midi message to a mido port to toggle efx

Ive been looking at the mido library to create the virtual port, which i assume can be used as an input for modep to read mido messages. However, modep doesnt seem to show the option to connect to to these virtual ports, but ik theyve been created because theyre visible in patchage. Perhaps im just not programming it correctly?

@Hanoofy would you mind posting your Python code here or link to a code repository? I could try it as well and see if I’m getting the same result.

For sure. As you can see, its just a simple menu program with the ports being initialized. it doesn’t do anything right now as im trying to use the python interpreter to figure out how to connect and send messages. Link to the doc: Mido - MIDI Objects for Python — Mido 1.2.10 documentation

#!/usr/bin/python
import mido

# these ports show up in patchage
virtualMidiIn = mido.open_input('vpIn', virtual=True) 
virtualMidiOut = mido.open_output('vpOut', virtual=True)


# main menu
while True:
    menuChar = input("Enter Menu Selection: ")

    if "quit" in menuChar:
        print("quitting program")
        virtualMidiIn.close()
        virtualMidiOut.close()
        print(mido.get_ioport_names())
        print(mido.get_input_names())
        print(mido.get_output_names())
        break
    else:
        if "dst" in menuChar:
            print("this turns on distortion")
        elif "rvb" in menuChar:
            print("This toggles reverb")
        elif "phs" in menuChar:
            print("This toggles phase")
        elif "dly" in menuChar:
            print("this toggles delay")
        elif "status" in menuChar:
            print(mido.get_ioport_names())
            print(mido.get_input_names())
            print(mido.get_output_names())
        else:
            print("Please enter valid choice")

Cool! So I can reproduce this, what hardware are you connecting to the pi when you run this script?

IMO you’d be better off connecting to the existing touchOSC port and sending OSC MIDI messages though the existing interface.

Thanks for the info doug, at first I assumed that these pre-existing ports like touchosc only existed for compatible controllers so i never thought to connect to those ports in python. Now i see thats not the case. Cheers

MOD UI filters out ‘non hardware’ ports (it’s a configurable flag when creating a new port, a virtual port can be marked as a hardware one). Unfortunately, if I remember right, the Python library does not expose this flag to be set by users of the library. To workaround this, I’ve came up with a amidithru program: GitHub - BlokasLabs/amidithru: User mode ALSA MIDI thru port.

It’s used from here: GitHub - BlokasLabs/modep-touchosc2midi: TouchOSC 2 MIDI debian package for MODEP

In a nutshell, amidithru process is started with touchosc argument to create a virtual hw port, not ignored by MOD UI, and then have touchosc2midi use the touchosc port.

1 Like

Hey @Giedrius thx for the info. I figured it out last night when using the amidithru cli tool with the ports i created and now im able the move on with my project. Appreciate the help!

EDIT: any chance i can cluster a few pi’s to save on cpu/dsp? Is that a thing?

1 Like

You could look into using Jack with clients on local network, but I don’t think that would improve things in general scenarios where minimal latency is expected. Only some specific use cases where latency is not that critical, and processing power is really insufficient on a single board to achieve the desired effect.