mlb-led-scoreboard VS zellij

So this is the instructions for the scoreboard: https://github.com/MLB-LED-Scoreboard/mlb-led-scoreboard/wiki

First and foremost, thank you to Tommy Farley’s MLB LED Scoreboard Project for the inspiration + most of the code base. My brother and I have been wanting a CFB equivalent of this forever, so we decided to build our own using a Raspberry Pi Zero and a 32 * 64 LED Matrix. Here is a link to the video demo. If you just so happen to have the same equipment, great! Here is our GitHub repository with the code + instructions on making your own. We’re also looking to sell these in the future (once the semiconductor shortage has hopefully settled down)— if you’re interested please let us know! As always, feedback from you all is great appreciated on how we can make this better.

About $200 in parts, runs out of a Pi.

I help maintain the MLB LED scoreboard project and we don't recommend anything less than 5A for a single matrix, and you're running 6 of them. In fact, the tutorial you linked suggests that you are way underpowering your matrices: https://learn.adafruit.com/32x16-32x32-rgb-led-matrix/powering

quick paste of an old how to file i made however heres the github link gh

I bought the RGB matrix and Raspberry Pi and assembled it. Just followed the process here to get the software running - https://github.com/MLB-LED-Scoreboard/mlb-led-scoreboard

You can look at the code/follow steps to build one yourself here: https://github.com/MLB-LED-Scoreboard/mlb-led-scoreboard. It's pretty straight forward if you have a technical background but if not it might take you a bit to get up to speed with the raspberry pi.

It supports a bunch of different matrix sizes, requires no assembly, and is free, so developers of software like the MLB LED scoreboard don't have to set up and maintain physical hardware to maintain the project. Consumers of those types of projects get the same benefits so you can run the emulated version without needing to pick up a soldering iron.

Having a common set of tools already set up in different windows or sessions in Tmux or Zellij is obviously an option, but there is a subset of us ( 👋 ) that would rather just have fingertip access to our common tools inside of our editor.

Of my series of PRs, I suspect the third (i.e. https://github.com/zellij-org/zellij/pull/3043) is most likely to have an effect. But if it does it'd only be as a side effect unfortunately - my focus was on fixing lag with splitting of extremely long lines.

From what I saw while making my changes, that area of the code has a bunch more possible optimisations, but it's 'good enough' for me at this point so I'm not planning to continue pulling at the thread right now. If you wanted to look yourself, I left the script I used for benchmarking and profiling in https://github.com/zellij-org/zellij/issues/2622#issuecommen...

For this reason, and because I think the Zellij project is interesting, I currently use a combination of Alacritty and Zellij, as I consider the risk of OSC52 in my use case to be relatively low.

Hot to run a script on a keybind

Wait until you hear about Zellij

I entered a comment ( https://github.com/zellij-org/zellij/issues/1625#issuecommen... ) before I read your comment here. Please let me know if that is sufficient.

We do support attaching and detaching. And persisting sessions to disk (and indeed, to any serializable form) is being worked on: https://github.com/zellij-org/zellij/issues/575

Read more here: https://github.com/zellij-org/zellij/releases/tag/v0.36.0