MIDI Input on SooperLooper disappeared

Optimize your system for ultimate performance.

Moderators: khz, MattKingUSA

Post Reply
User avatar
Digital Larry
Established Member
Posts: 150
Joined: Thu Jan 09, 2014 5:25 am

MIDI Input on SooperLooper disappeared

Post by Digital Larry »

Using Ubuntu Studio 19.10.

vmpk and fluidsynth still show MIDI ports under QJackCtl's ALSA tab (where SooperLooper generally shows up). It was there a few days ago and while I've been messing with various things, I don't recall anything that obviously would have made this happen. Anyone seen this before? Have rebooted a few times. As I've compiled SooperLooper from source, I may attempt to debug it but that's quite a hassle that I did not seek to encounter. :?

User avatar
Digital Larry
Established Member
Posts: 150
Joined: Thu Jan 09, 2014 5:25 am

Re: MIDI Input on SooperLooper disappeared

Post by Digital Larry »

I see that my participation in this forum is largely to serve as a warning for everyone.

We can file this under "stupid pilot error for inexperienced developers".

#1 pre-installed or officially installed packages tend to wind up in /usr/bin.

#2 when you get package source, and build and install it, those tend to wind up in /usr/local/bin.

#3 In Ubuntu Studio 19.10, and I suspect many others, /usr/local/bin precedes /usr/bin in the PATH.

#4 I have seen several different methods used to set things up prior to building apps from source:
- autogen.sh, followed by ./configure, make, sudo make install
- ./configure, make, sudo make install
- waf configure, waf, sudo waf install
- "build.sh"
(I probably misrepresented one or more of those, but anyway...)

#5 Some packages will build just fine without some important bit. For example I didn't set the LADSPA_PATH environment variable correctly, and so when I built Hydrogen, it didn't care (it still built), but none of the features that depend on that showed up either.

#6 Some packages, e.g. in this case SooperLooper, are split into client/server halves. While I am focusing on the slgui, it's not currently possible to just build the slgui AFAIK. You have to build the whole thing including the "sooperlooper" server/looper engine.

#7 So, what I'd done was to build sooperlooper, server and client both, from source. Somehow I didn't have MIDI configured correctly, and it built the server without MIDI support. I wasn't aware of this at first because the "configure" stage spits out a ton of stuff and doesn't summarize errors or warnings at the end. So you really need to capture the output of any such steps and review it carefully, because the developer might have been clever and allowed it to build without MIDI support. So, even though what I wanted to do was to use my modified slgui with the stock sooperlooper, in fact I was using the (inadvertently) modified sooperlooper instead.

#8 when I start soooperlooper first using /usr/bin/sooperlooper, then everything works as expected. But if you run "slgui" then it finds and starts the one which it finds first in the path.

Post Reply