jack2 and mod-host versions (or: CV segfault in jack2)

[geedubess]

I understand some of the reasons that we might want to lock our installed libs/apps to a version, and why we might want to additionally patch them, but is there further information available about these choices or a maintenance plan? In particular I don't see the value-add of the diffs in the forks (eg mod-host fork only seems to add optimization for cortex-a53 and I can't see the jack2 fork adding anything).

https://github.com/TreeFallSound/pi-stomp/blob/pistomp-v3/setup/mod/install.sh installs from:

https://github.com/micahvdm/mod-host (71 commits behind parent)
https://github.com/micahvdm/jack2 (1.9.14 vs 1.9.22 from ChangeLog.rst, https://github.com/jackaudio/jack2)

I came to this because of a segfault in mod-host whenever I assign a CV signal to an effect parameter. After updating to https://github.com/mod-audio/mod-host [master] and https://github.com/jackaudio/jack2.git [develop], my CV problem is fixed.
My initial hint was: mod-audio/mod-host#88; building a debug version of mod-host and attaching gdb to it showed the segfault was in /lib/aarch64-linux-gnu/libjack.so.0). (I wouldn't recommend pulling from develop, instead using a 1.9.22 tag for distribution of course.)

Some notes about updating to these versions (I'll continue to test):

• mod-host required a small Makefile patch to update to the current processor and
• I needed to ignore /usr/local/lib/liblilv-0.a; I was trying not to rebuild more than I had to like lilv):

diff --git a/Makefile b/Makefile
index ba5bf86..42164a3 100644
--- a/Makefile
+++ b/Makefile
@@ -20,6 +20,7 @@ MANDIR = $(SHAREDIR)/man/man1/
 CFLAGS += -O3 -Wall -Wextra -c -std=gnu99 -fPIC -D_GNU_SOURCE -pthread
 CFLAGS += -Wno-deprecated-declarations
 CFLAGS += -Werror=implicit-function-declaration -Werror=return-type
+CFLAGS += -mcpu=cortex-a76 -mtune=cortex-a76

 # debug mode compiler and linker flags
 ifeq ($(DEBUG), 1)
@@ -46,7 +47,8 @@ CFLAGS += -Winit-self -Wjump-misses-init -Wmissing-prototypes -Wnested-externs -
 endif

 # libraries
-LIBS = $(shell pkg-config --libs lilv-0)
+# force a link against the shared library instead of the installed static library
+LIBS    = /usr/lib/aarch64-linux-gnu/liblilv-0.so -ldl -lsord-0 -lserd-0 -lsratom-0 -ljack

 ifeq ($(MOD_DESKTOP),1)
 LIBS += $(subst -ljack ,-ljackserver ,$(shell pkg-config --libs jack))

[maarthome]

Hi Greg,

I do not manage to compile the Pi-Stomp application. I get lots of errors. (I used to compile on a Pi4 and that worked.. :-))
I am not knowledgeble enough to solve the issues.
Could you please upload the Makefile version you use compiling mod-host?
(or even a procedure...?)

You seem experienced. Did you ever look at https://github.com/sejerpz/alabs-mod-custom-images?
He made some great additions to the web interface of moddwarf! Do you think it is possible to adapt his adaptions to the PI-Stomp code? And will this a lot of work?

Cheers and thanks for your time,
Maarten

[geedubess]

Hi - the only changes I made were to the mod-host Makefile above, but they shouldn't always be necessary (the CFLAGS is just a performance optimization, and the LIBS is only because I didn't want to rebuild lilv but noticed the .a lib file was present, which was breaking my link stage).

I don't know what you mean by 'the Pi-Stomp application' - do you mean the whole image? I haven't done that; I just built jack and mod-host in situ from git sources.

The sejerpz changes sound interesting. Of course anything is possible, but I have no idea how much work that would be. I am in some contexts an experienced dev, but I had literally never looked at any of this until last week. There are quite a few local deltas between the pistomp version of mod-ui and the main branch, for example.

[maarthome]

Hi,

I was not clear... I meant installing mod-host gave errors... but also with the old Makefile....
I keep on using the already compiled image....

Cheers,
Maarten

[geedubess]

Adding to this line of questioning (looking for reasoning on the forks we're using), I see that that the micahvdm fork of touchosc2midi introduced a breaking commit here: micahvdm/touchosc2midi@d4f2061

This resulted in a bad restart loop:

Dec 17 13:37:12 pistomp systemd[1]: Started mod-touchosc2midi.service - TouchOsc2Midi service.
Dec 17 13:37:12 pistomp bash[3164]: Traceback (most recent call last):
Dec 17 13:37:12 pistomp bash[3164]: File "/usr/local/bin/touchosc2midi", line 5, in
Dec 17 13:37:12 pistomp bash[3164]: from touchosc2midi.touchosc2midi import main
Dec 17 13:37:12 pistomp bash[3164]: File "/usr/local/lib/python3.11/dist-packages/touchosc2midi/touchosc2midi.py", line 32, in
Dec 17 13:37:12 pistomp bash[3164]: from .advertise import PORT, default_route_interface, Advertisement
Dec 17 13:37:12 pistomp bash[3164]: File "/usr/local/lib/python3.11/dist-packages/touchosc2midi/advertise.py", line 101
Dec 17 13:37:12 pistomp bash[3164]: if len(self.info.addresses) > 0 else "--none--"
Dec 17 13:37:12 pistomp bash[3164]: IndentationError: unexpected indent
Dec 17 13:37:12 pistomp systemd[1]: mod-touchosc2midi.service: Main process exited, code=exited, status=1/FAILURE
Dec 17 13:37:12 pistomp systemd[1]: mod-touchosc2midi.service: Failed with result 'exit-code'.

I patched it locally, but I'm still not sure why we're using micahvdm forks? If that's just the way things are, then I can start introducing bug reports against the micahvdm repos.

[rreichenbach]

Thanks for identifying these issues @geedubess. The short answer is that Micah had been fixing issues for pi-Stomp, and although I was aware of the changes, I've not taken the time to understand all the details of them myself. I've taken the short term stance of if it ain't broke, don't fix. But yes, you're finding some breaks, and not updating misses out on upstream fixes and features, so I'm certainly in favor of reducing the number of custom forks. I would prefer that over fixing the forks, but there were valid reasons for them in the first place, so understanding the reasons and deltas are important before switching back to the original. Would also be nice to have some level of QA to verify that expected behavior still works.

Feel free to log issues. I can try to address one per week.

[geedubess]

Thanks. I'm diving in with no context, so please bear with me and my questions! I think it makes sense for me to fork this repo - I'll get it working against the upstream repos (release tags if they have them) and generate a pull request. I would hope that most of the bugs that we encounter would be specific to pistomp and don't require hacking the modules being pulled in - if you can avoid forking the pulled in repos, that'll save quite a bit of maintenance overhead. I'm most curious about the mod-host fork...

I think it would also help if you outline your roadmap for the software side somewhere - I'm glad you're using debian instead of patchbox os (my personal preference; learning new custom builds just gets in the way)! Informal notes in the wiki or even slightly more formal tracking in this repo would be welcome. (For example, are you planning on staying with debian bookworm and just building more and more stuff from source as it gets more outdated?)

[rreichenbach]

The bookworm migration was a fairly major effort, as was adding support for pi5. I do not wish to do that again any time soon. It would be good to keep mod-host and mod-ui fairly up to date, but we have done fairly significant changes to mod-ui at this point, so pulling from upstream may not be simple. Most of the other support libs are chosen to align with the mod libs.

You may already know, but building from source using the setup scripts in this repo is no longer recommended. We switched to using pi-gen for the official release builds:

https://github.com/rreichenbach/pi-gen-pistomp

That's where the dependencies are defined. So changes to non pi-stomp specific libs should probably be done in the lib itself or pi-gen-pistomp.

[geedubess]

🤦 I wasn't looking at that repo yet, as everything I saw on the installed image aligned with what I was seeing in this repo. Thanks!

I did notice that this repo is owned by treefallsound; pi-gen-pistomp is owned by you, and I can't file issues there - does it make sense to keep submitting them here?

[sastraxi]

If you are looking for a contributor to help manage the dependencies and patches here and try to get things upstreamed, I'd love to help out (and have the time to do so). A good metric of success here would seem to be minimizing the number of patches applied in pi-gen-pistomp. I agree that it would be somewhat easier (from a mental load POV!) to contribute if pi-gen-pistomp was owned by TreeFallSound.

[rreichenbach]

That would be awesome @sastraxi! I have moved pi-gen-pistomp to be owned by TreeFallSound and it's public.

https://github.com/TreeFallSound/pi-gen-pistomp

I enhanced the README to get you started building images. Let me know if and how else I can help.

[geedubess]

Thanks @rreichenbach, that helps! I'll fork and start submitting PRs/issues against that instead.