(And then I add back the selected output if it was missing, so the trigger will continue to work when you run BLT with that device connected.)
Yes, I use the
midi-sinks method in midi-clj to get all available MIDI outputs. I would think that is the same thing its GUI uses, but I will take a look there too.
The
midi-clj readme even says “In Ubuntu Linux I use the snd-virmidi kernel module to provide software midi ports. USB midi devices should be pretty much plug and play.” so this ought to work!
Computers and software have grown so complex that it is amazing when anything works.
If Raspbian and a USB MIDI keyboard is close enough I could try some stuff there, but this is very frustrating.
Okay yeah that should be enough to test it with
Bro, I just wanna say that I am wholly grateful for all your help. I really appreciate you taking the time to help dig into all of this
I will try some experiments with Raspbian and get back to you. I probably don’t have time tonight because I need to finish laundry and then tackle today’s Advent of Code challenge. But hopefully tomorrow.
Thanks, you too! Maybe sleeping on this will give me some other ideas too. I suspect it has to do with the way that BLT opens MIDI devices as soon as it knows about them, and keeps them open, to be able to share them between triggers. I will have to re-learn how that all works, and then see if there is a way to not do that in Linux if it doesn’t work there. But the first step will be seeing if I can reproduce the problem with hardware I have here.
You’ll be the first to know when I do, @whoman321! Unfortunately, last week was too busy, between work and the competetiveness my coworkers encourage in solving Advent of Code problems. I hope to have time to take out and set up the Pi this weekend, though, probably Sunday afternoon.
Well, @whoman321, I finally had time to hook everything up, and I can confirm that Raspbian has the same probelmatic behavior as you have reported. I will try to dig a little bit deeper, but right now I am being stymied as I can’t seem to establish an nREPL connection from my development machine to the Beat Link Trigger process running on the Pi, which will make experimentation far more tedious. I’ll start installing some development tools on the Pi.
But what seems to be the case is that MIDI interface management works fundamentally different in Linux JVMs that macOS and Windows JVMs. So if you can help try to find a way around this, that will definitely speed things up. However, we would have to be very careful not to change the way it currently works on macOS and Windows, because I have many people using it for touring shows, festivals, and clubs today, and can’t risk breaking them. So for now the answer is going to be telling people not to try to use the built-in trigger MIDI features on Linux, and perhaps deprecating that OS family entirely.
Well, I have Leiningen and the BLT source installed on the Pi, and am trying to bring it up in a REPL for more testing. I have some ideas about things to try. But Leiningen has been timing out because the Pi is not nearly as fast as my development machine (go figure! :wink:). I think I just figured out how to work around that.
Ok, it has been very frustrating and slow getting anything testable, but I have already learned something very interesting and promising. The problem may be a lot easier to work around than I feared, because it seems to be simply that in Linux,
midi-clj can’t find a device you are asking for when you supply the name that it gave for that device!
Woo hoo, I think I have an answer @whoman321! It turns out all this time I’ve been calling the
midi-clj functions wrong, because they behave in a way that is not idiomatic Clojure (they are pretty old, they were written when Clojure was new and best practices weren’t widely known). They treat input strings as if they were regular expressions, and so the brackets in Linux device names are making them not match. The more idiomatic (and developer-friendly) way for the functions to work would be to accept both plain strings and regular expressions as the target being searched for (regular expressions have nice, concise literal syntax in Clojure so they are easy to type), and then it could work either way. I may open a PR with midi-clj about this, although the only backwards-compatible way to do it would be to offer a new function that works this way and deprecates the old one. (While I’m at it, I might suggest they get rid of the midi- prefix on all their function names, that is also not idiomatic, the best practice is just to name the functions for what they do, and let people use namespace aliases to make it clear where they come from.) But that is a project for another day; for now I just need to fix the places that Beat Link Trigger is calling these functions to properly escape any regular expression special characters, and we should be able to get MIDI output selection working in Linux!
I have verified that my proposed fix works on Raspbian, and have pushed it to GitHub. When you get a chance, could you download the latest preview jar at https://github.com/Deep-Symmetry/beat-link-trigger/releases/tag/v0.6.3-SNAPSHOT and see if it works for you too?
If this works, it’s definitely time to publish a new official release of BLT. I should have a while ago, there is some good stuff in 0.6.3.
@eric do you know if the Hue can be controlled with a local connection, or if there always has to be a round-trip to some cloud service? In the latter case, latency issues may make it not suitable for show synchronization. I wish I had one to try experimenting with. If anyone wants to loan me one I would tinker! :smile:
Yes, it looks like there is a local LAN API we can use, so it would just be a matter of configuring information about your bridge and lights in the trigger or global setup functions, and then sending HTTPS requests in response to beats or whatever you like to control the lights. I am curious what they are using for their SSL certificate, since the bridge server isn’t going to have a valid public domain name, there may be some of the usual pain around configuring trust for a self-signed certificate. https://developers.meethue.com/develop/get-started-2/
every time I open Beat Link Trigger I have to re-enable the abelton link integration. is there a way to make that happen automatically on start?
ah, here it is in the Triggers menu. sorry about that
Someone just commented about https://www.prodjlink.com/ on a reddit post where I mentioned BLT. At a glance it looks like it just extracts the timecode and doesn't have any show functionality. Ever tried it?
Someone on this chat might have. I personally have to be careful not to look at commercial offerings in this space, because they generally have very restrictive end-user license agreements which could interfere with my ability to continue to research, develop, and offer the completely free and open-source implementations that power BLT. Also, some of the companies in this area have been extremely unfriendly, litigious, and unpleasant in the past (I’m not saying this is one of them, I don’t know what that company is called any more or even if it still exists, I just try to stay far away so I can keep doing my thing).
Sigh… not cutting the release tonight. I fixed one bug about reporting the wrong trigger number when there is an exception in an expression at load time for triggers other than Trigger 1, but then discovered that the search function is not working properly in the embedded user guide, which makes it really hard to use when not connected to the internet. I am looking for help on the Antora users channel, but don’t want to finish the release until that is sorted out.
Hurrah! :tada: I got the search working in the embedded user guide again with the help of the author of that integration. And then I spent all of today rediscovering how very many of my own libraries go into Beat Link Trigger, and cutting the releases of all of them neeed to build each other so I can release Beat Link Trigger 0.6.3. But that is in process right now. I also updated the version of Ableton Link that gets embedded to 3.0.3.