I have posted some questions here about pedals. I have made a lot of progress very quickly
I have made this little programme call /usr/modep/scripts/modep-ctrl.py to change the pedal board that is loaded.
The problem I am having is the latency between depressing the pedal and the pedal board changing. About half a second. It needs to be more like 10ms.
I have experimented in the past with adjusting mod-host via port 5555, with out much problem with latency.
I think the latency is the python interpreter starting up. I need to read the data and control mod-host directlt form my C without loading the python interpreter every time.
To that end I thought I would ask here: Has any body done this? Is there any example code (in C, C++, Rust, Go, and compiled language) for reading the data that modep writes (in /var/modep/pedalboards/) and driving mod-host to set up the lv2 effects and the jack connections?
Perhaps some one can convince me I am barking up the wrong tree…
time { /usr/modep/scripts/modep-ctrl.py ...args.. ; }
to see how long exactly the command took. Usually, loading the dependent libraries in python takes the longest. You could just look at the source code of the script and take the stuff you need and try to implement it in a more performant way. In the end, it boils down to a http request on the MOD UI server. You could just try to call curl with the appropriate command line to make the requests. Then you could also use the same time { ... ; } to see if it’s better.
It is a very useful programme, and has been brilliant for my purposes so far, proving I can make the pedal work.
But the steps of:
Fire up teh python interpreter
Prepare a HTTP message and call the server
On the server… That is as far as I have read. I am knee deep, soon to be eyebrow deep in host.py
You are correct about profiling. Must be done. But the overhead of starting the python interpreter, the over head of wending through the network stack twice (out and in) is not a good model, in the end, for what I want to do.
$ cat /tmp/test.py
quit()
$ time perl -e 'for($i = 0; $i < 100; $i++){`python3 /tmp/test.py`}'
real 0m5.498s
user 0m2.972s
sys 0m2.123s
$ time perl -e 'for($i = 0; $i < 100; $i++){`touch /tmp/test.py`}'
real 0m0.533s
user 0m0.250s
sys 0m0.271s
So starting the python interpreter is worse than 0.055 - 0.0053 ~= 5ms which is half my time budget.
Fantastic work the whole modep project is. For my purposes I need to read the data it writes in /var/modep/pedalboards/ and talk directly to mod-host
I think it’d be worth it to check out how long it’d take to do the same http requests directly, without the Python overhead. Once you start accessing the files directly and communicating with mod host, it may break at any moment when the version gets upgraded.
Btw, to workaround the startup delay of Python, the script could be reworked to run as a daemon in the background, waiting for commands to perform the actual useful work.
wget -q -O /dev/null localhost/reset ; wget -q -O - --post-data="" http://localhost/pedalboard/load_bundle/?bundlepath=/var/modep/pedalboards/D20210709b.pedalboard as far as I can tell mimics what modep-ctrl.py D20210709b does
It does it in about 100 to 200 milliseconds. modep-ctrl.py takes about 500ms
I think that the delay (not latency) between pedal board changing, is due to how MODEP works: in each change, it redo all conections from/to Jack server.
You can see this on qJackCtrl Conections window, and it´s slow (plus pedals/settings time to load).
Dow did I figure it out?
My 1st RPi setup was with Guitarix: it keeps jack conections on and active, changing only the “patchs”, which is virtually instantaneous…
So… Why I changed to MODEP?
Answer:
More stomps (pedals) - including many from Guitarix
Free stomp conectivity (serial / paralell - Gx appears serial only to me: input > pre-amp / gain > modulation > fx… > … > output)
BEAUTIFUL designed pedalboard and stomps (although never seen in stage, just in “build” - I use Arduino and 16x2 LCD just for “patch” name)
Modular (Gx LV2 integration seemed hacky and seamed)
And yes: for real stage playing Gx is OK too (and FASTER).
Is there a way of controlling GuitarX from a external programme? The documentation of GuitarX seems woeful to me, I have not found a good source. If it can be, and it is responsive, I will use it.
I think you may be correct about the cause of the latency. Or may not be. Without measuring it it is impossible to know. I am busy hacking the modep server to talk to it directly (rather than through the HTTP stack) but I am not sure it is worth it, but if I succeed it may be fast enough. If I can get it to less than 100ms it will probably be god enough. In the end it is a subjective judgement. I have a target of 10ms
The modep chain is a ball of Python code: The server is Tornado and as far as I can tell pure python. Generalising from my experience these sorts of systems tend to be wasteful of resources.
The alternative is to parse the modep files and wrangle mod-host (and thereby jack - mod-host is very good at wrangling jack) myself. I have done the second part of that, the first part - parsing the files - well I was hoping there would be code somewhere (other than in the modep python ball of string) but I have not found it.
As things stand modep is useful for finding the good settings for the LV2 plugins. It is less useful for actual live work as it is so slow. Latency of 200ms at best and 500ms typically from pushing the pedal to hearing the change is too slow.
Yes, you can control Guitarix through MIDI and/or “remotely” through their web ui interface (sourceforge .net/projects/guitarix/files/guitarix/).
MIDI is far the fastest way, specially if you start Gx with command line option “-N” (no UI).
If you go for the web ui route, it is achieved starting a webserver in Python (yes, resource intensive and “slow”, but you can “renice” it).
You can make your Pi act as access point, so you dont need be connected a router, but this misses the point here…
That web ui is mobile friendly, so you and change patchs, add/change/remove FXs etc. through your phone! ([see this - step 3](www.google .com/url?sa=i&url=http%3A%2F%2Farre234.blogspot.com%2F2018%2F02%2Flinux-portable-wifi-guitar-amp-on.html&psig=AOvVaw3–zY2LefN77msqYB6VHM5&ust=1627041019681000&source=images&cd=vfe&ved=0CAwQjhxqFwoTCKjEm4rO9vECFQAAAAAdAAAAABAD))
What I did: hacked the web ui traffic in desktop browser (F12), so I could see JSON calls/responses from Gx.
So, I´ve made a python script to make that http calls to:
Get then patch list from Gx
Send previous/next patch MIDI command
Get the reply and show it in LCD 16x2 display
Send some MIDI commands for other tasks (mute/unmute Gx, drum start/stop, change drum speed etc.)
The most critical part I´ve felt was Jackd start params, specially real time settings… That did made a difference from stuttering audio to fluid, without xruns etc.
I am using a Raspberry PI 4b naturally. I will be running headless (with a simple web app I have built to display what settings exist, on a phone) and live. Changing settings with the phone requires taking my hands away from where they are busy making music so it has to be a pedal and it has to be real time. Real time means no python (or Perl, Go, JavaScript… and language with GC pauses) in the chain. So probably C/Rust.
The big problem is the settings for the LV2 control inputs. It has to sound as good as possible. Which makes those settings very important, and I need a good GUI for that. That is the hard problem MODEP and GuitarX solve. But so far it seems MODEP is not suitable for my live purposes (fabulous though it is, love it to bits, great work!) if I could find some documentation of the protocols GuitarX speaks then it may be. It would save me a tonne of parsing blues if that were so.
But try guitarx at DuckDuckGo The word is too common, it is very hard to find anything useful.
Looking a bit more closely at GuitarX’s source distribution there is some notion of a client/server over TCP using JSON-RPC. Looks perfect but the documentation is a bit woeful.
Sourceforge is a really bad site - it is impossible to find the documentation on that site. Following the instructions in the source the documentarian for teh client/server part does not build.
tl:dr Extract jac/mod-host settings from /var/modep/pedalboards, set up mod-host effects and all the jack piping between then have my pedal driver own a jack client and just adjust the system:… jack pipes.
I gave up talking to the Modep process. After finding it took ~500ms to use modep-ctrl I did spend some time hacking around the tomahawk based server to talk to it directly (that is not through the web stack).
This was not fun, I am no fan of python, and fun is the point, partly. I looked closely at the way it interacted with the /var/modep/pedslboard/ files, and it was doing a lot I did not need (I am not using midi). So I did a swerve away from that and wrote a perl script to read those files and collect the settings for mod-host and jack. Set up mod-host and the jack connections between the mod-host effects. Leaving just the I/O connections (involving jack pipes of starting with “system:”)
Writing a programme that reads the definitions of the jackI/O, connect to jack and disconnect/connect what is needed to switch pedalboards was very disappointing. Took ~200ms. Really? Why is Jack so slow…
Turns out it takes about 200ms to initialise a jack client. (Aside: Really Jack? What are you thinking? I have not opened the box and looked in, much, so I do not know what you are doing when you initialise a client, but 200ms???)
So now I have integrated the jack client into my pedal driver and I am achieving 5 to 50 ms regularly. I can switch pedals without any audible click.
I will post the code to github soon. Some corners to shave etcetera.
It would be nice if I could make this play nicer with modep. Currently when I start my process I shut down modep-mod-host and modep-mod-ui.
The next step might be to let modep set up all the pedal boards (I have to modify it to not ever take them down unless they are edited) and switch the jack inputs only. I have been following the path of least resistance to getting to the goal of having a set of digital effects that I can design in modep and run with a pedal.
There will be a better way - but good enough is good enough, then I make it better.
