If you've ever downloaded something from ETC Labs: OSCRouter, Sound2Light, lighthack files - you've probably used something that starts to slip into the dark underbelly of ETC engineering… and may require soldering.
And that's the whole pitch, really. ETC Labs is the GitHub repository for open-source source projects that connect ETC engineers and community developers - some of them libraries to support industry standards, some of them communication protocols to interface with products like Eos, and a lot of projects marked “unofficial” - which are not supported through typical ETC channels. ETC engineers like to create these projects to help the broader lighting community, grow their own skills, offer new utilities, or sometimes to have fun.
A new project just posted, Tiny Rig, is definitely the latter. It is a silly little program which appears to serve no purpose. It is not a utility or library. It is not a feature or a product. It has no business justification. And I love it enormously.
Tiny Rig comes from Chris Mizerak (Miz, to anyone who's worked with him), Principal Software Engineer at ETC, who is quietly responsible for several features you use in Eos every day. And with its posting and the GitHub repository now being over a decade old, it seemed like a good time to sit down with him to talk about where ETC Labs came from, why our engineers spend Friday's building things nobody asked for, and what happens when the lighting community starts sending pull requests.
Chris Mizerak, Principal Software Engineer
This conversation has been lightly edited for length and clarity.
Nick: Tiny Rig is a lot of fun, but before we get there, let's start from the beginning. How did ETC Labs get going?
Miz: It started because we wanted to expose Eos to more third-party integration, to more platforms. I think we first added OSC input into Eos, and we started with EosSyncLib, which is basically a simple OSC interface to Eos so that third parties could download all the show data and manipulate it, pull it, subscribe to it, listen for events.
And it kind of grew from there. We had a lot of interns who started contributing fun little projects — Sound2Light, and Luminosus, the one where you drag the nodes around. That was a really popular one. Then more of ETC R&D started to get involved, and they started uploading their own libraries. RDMnet is up there now. That's a fairly active one.
Nick: So it was homegrown for a while, and then it became a thing. How long ago was that?
Miz: Geez, I'd have to look. It's been many years. I'm seeing things that were committed eleven years ago when I pull up some random repo up there. That's crazy — I didn't even realize it was that long.
Nick: Over a decade… (laughs) I guess our timekeeping there is unofficial, too. So how much of what's up there is ETC people, and how much have others contributed?
Miz: There are definitely a lot of contributors outside of ETC. In OSCRouter, for example, we made a lot of changes over the past year that came from the community, with a little bit of oversight, and then pushed those changes into the software. That's been really cool to see.
Nick: That’s worth sitting with for a second. OSCRouter is probably one of the better-known things we have on ETC Labs, and a meaningful chunk of its last year of development was written by people who don't work at ETC. I think that’s pretty cool.
Miz: Yeah, I think it's a thing that happened because the code was sitting in the open, and people like to contribute.
Nick: I think lighthack is one people bring up to me the most. Sam Kearney and a few others put that together, right? Where did the idea come from?
Miz: With ETC Labs on GitHub, we had a lot of firmware engineers who wanted to find a way to get involved. And it was kind of the heyday of Arduino… all the little gadgets you could build, all the little sensors you could add on. So we wanted to try to make that really accessible to our users, so they could learn to build their own devices. Especially for budget-constrained environments. Schools, churches, places that needed a go button, or to build a little encoder box to do pan and tilt with moving lights.
So the Eos software engineers got together with the firmware folks, and we came up with a plan to just funnel OSC commands through a USB connection, in a way that was easy enough to write little scripts for. We open-sourced the whole thing and sold a little parts kit on our website. And then some of the software engineers even got to learn how to solder, which was fun.
Nick: That’s not a regular part of a software engineer’s day? (laughs) Yeah, it has been a cool education thing, a way to learn OSC and make it work with Eos, while also getting a little box to work with. It has been a really successful project, which I think speaks to the whole point of open source and the ETC Labs GitHub.
Nick: You and I know how research time works inside ETC, but many people reading this may not. Talk about that space and what it means to you and to the wider R&D team.
Miz: Maybe five years ago there was a big push in ETC R&D to start spending a certain amount of your time on innovation projects. You're able to take any Friday to work on unofficial projects. It can be just experimenting, doing something creative or artistic, or it can be refining your engineering skills.
A lot of times I like to try to build things that users have asked us for as wish list items, and then we can try it out. We might put it into Eos proper behind a configuration flag to let people try it internally, and a lot of times those features make it into the product eventually. That's how Zones became a thing. It's really how OSC became a thing.
Nick: And most recently, Video Streams, which was yours specifically.
Miz: Yeah, exactly. It's been really awesome, both for the engineers who want a break from the giant monolithic codebase, but also because it's helpful to our end users. I mean, that's the goal.
Nick: I think that’s important, because I think it's easy to hear "innovation time" and wonder, like, “why aren’t you working on the thing I want?” But innovation time is not only important to keep engineer's fresh and engaged, but it can lay the foundation for ideas that become great features. And I know for a fact that, while many of them are good, some will never see the light of day!
Nick: Let's talk about agentic coding for a minute. Do you think more people are going to be able to get their ideas into a usable form? Where do you see this moment, with tools that make it easier for non-developers to try things?
Miz: It's an interesting time. I think AI coding is really helpful when you want to just prototype something quickly and try out an idea. And it enables people who aren't super familiar with coding, or for whom it's not their day job, to build something that works so they can try something out.
But, you know, there's a difference between prototyping and using that AI-generated code in a real product. You know, like Eos, that you count on to keep the lights on every day, versus just kind of trying out your idea.
So in my personal view, it's very useful for rapid prototyping. But then you take that concept, you prove it out in the real world, and once you think, oh, this is a viable feature that should be included in Eos, that's when you take what you've learned and write it in a robust way yourself. You own the code, you know how it works, you can support it.
Nick: Yeah, like, maybe a faster sketchpad. But when it is out driving real shows and may need support and fixes, we need engineers to understand and own what they’ve done.
Miz: Exactly.
Nick: So, Tiny Rig just went up. I have to say, I am in love. What was the inspiration, and how did it get to be what it is?
Miz: Tiny Rig is something I spent a bit of innovation time on. It's more of just a passion project, just for fun.
I got the idea from a long time ago. There used to be these little desktop companion apps, little apps that just ran on your desktop just for fun. And I was like, hey, we could just do that, but for production. So I came up with this little floating island with a static rig of twenty Halcyon Platinum fixtures and an opinionated little lighting programmer.
And it was fun. I got to poll the Eos team. Which, to no one's surprise, has a lot of active lighting designers and programmers on it. And like ask them for thoughts and the phrases that come to mind when they're working on their shows. So there are a whole bunch of little fun phrases the programmer says.
Oh, and the rig is actually listening to streaming ACN. It comes with a default Eos show file with the twenty fixtures patched, so you can run the lights on the little floating island on your desktop.
Nick: Visualizers can sometimes be hard to get set up correctly on the same machine; there's a lot of technical knowledge needed. Do you see this as helping people get a feel for how moving lights and effects behave?
Miz: I don't know. It's one of those things that is just - I think of it as purely a fun little toy thing. We'll see what people do with it. If they like it, they can ask for updates or make updates to it themselves. We're open-sourcing it. It's pretty basic. I'd consider it more of a little toy.
Nick: I do like low-expectation releases. But pretty cool, point some sACN at it, watch the fixtures do their thing, and see what the sassy programmer has to say about your cue. Seems worth posting to me.
Nick: Any other side projects on deck, or areas you think are interesting from here?
Miz: Let's see what's next on my innovation list. I'll always want to be adding more and more to third-party integration support, because it's really cool to see what people can build with those things. It's cool to see real, bona fide products like Vor coming out that are really leveraging those integration packages. And yeah, like a few other ideas, but I am not sure I can talk about them right now.
Nick: Yeah, I love growing Eos integration, it is really core to our philosophy. Like, we are never going to build everything that everybody wants or needs, so having a lot of hooks into Eos can help others come up with creative tools that just lock into the Eos ecosystem. Like, if we can't build it for you, we can at least make sure the door is unlocked.
Nick: Last one. Education, open source, community — what's your point of view on why we even bother doing this?
Miz: For a lot of us, this is our passion. We're not just writing code for a bank. We're writing code that supports the arts, and we're very connected to our user base. A lot of us have personal friendships with people in the industry. So when we're writing these kinds of passion projects, these side projects, it's really a personal thing. It's cool to know that your friends will use the things you're writing. It feels good to help out the community. And it feels good to, in a way, give away features to people who wouldn't otherwise be able to access them — people who can't run the fanciest Apex consoles, but you can give them little pieces of that. Which is really nice.
Nick: I completely agree.
Everything about ETC Labs is open source. Genuinely open - clone it, fork it, break it, improve it. Here are some resources:
Issues and pull requests are read by actual engineers at ETC, who are delighted to see them. And if you build something with any of the projects, tell us: seeing how people use these tools is a big part of why ETC Labs exists.