Contimuing Pedal/Modep project: Latency

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…

You may use:

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.

I have been reading the source code.

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

That is where my thinking is at now.

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. :slight_smile:

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.

Good point.

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

This is a improvement and easy to implement.

1 Like

Hi Worik.

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).

Just my 2 cents.

Adrian

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:

  1. Get then patch list from Gx
  2. Send previous/next patch MIDI command
  3. Get the reply and show it in LCD 16x2 display
  4. Send some MIDI commands for other tasks (mute/unmute Gx, drum start/stop, change drum speed etc.)

But RPi (3b in my case) is very capable, so I have implemented all of that in Python, including a Tunner (based in this: www.chciken.com/digital/signal/processing/2020/05/13/guitar-tuner.html)!

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.

Adrian

1 Like

Cool.
Is there any documentation for guitarx?

guitarix - Browse /guitarix at SourceForge.net looks like a code repository. Without the sort of documentation mod-host has, it is probably not worth embarking on the journey

Arnout's blog: Linux portable wifi guitar amp on an orange pi zero looks very interesting. I have just glanced for now, but I think I need to read it closely.

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.

Frustrating and frustrated!