The Development of Univer Inter, part 2

From time to time, Stephen and Kris like to write a bit about the development of a product. Today we’re talking about Univer Inter: part history, part technical, part wacky look into what turned out to be the most frantic and wacky release we have probably ever had. Today is the second of two parts. Today, we’ll talk a bit more about the history of the configuration app and some of the design and development behind that, and the extremely wild ride of the release. If you missed part one, where we detailed some of the hardware tech, you can find it here.

USB drivers and app development, oh my.

Back in December, Stephen started work on our own USB drivers that we would need for the product. That took a while in the context of other product releases happening and active development on several other things we have cooking for later this year, but it’s been on the to-do list for a long time.

Last time, we talked a bit about the configuration app we started writing way back in 2019. In the brutal light of 2023, we knew that we needed to update it. For many reasons, this would entail a complete rewrite of the entire Customer Portal using React. We also decided to redesign the firmware since the original UI prototype was built using HAL rather than our own library. The original UI was also our first ever attempt at using a STM32 processor, and it turned out that we have learned a lot in the intervening years. 

Putting the UI configuration in the Customer Portal also makes it one-stop functionality for our manufacturer: we can give them separate permissions that allow them to access features we build in for factory test and calibration.

Of course, to get started, there was one small problem: none of us knew React.

So in May, Stephen sat down and taught himself the language and threw together a skeleton of the Customer Portal for us to start working on. In June, he pointed Kris to the framework that we would use and her head sort of exploded. She beat her head against it for a day, realized she didn’t have enough knowledge to even get started. On day 2, she jumped into a tutorial. On day 3 and beyond, she ever so slowly started taking on bigger and bigger chunks of the site. The team oscillated between testing the site and testing the module. It was chaos.

The app, as we have said, is really part of the product. It’s our first web app of any real complexity. And there are some circular dependencies between the app creation and the firmware creation that made the process really chicken-egg complicated. For example, as we added support for polyphony, the app had to support it to make it testable. Seems obvious. But as we tested, we found bugs and had to edit the firmware and the app interface, so virtually everything was constantly in flux. Firmwares were being built constantly and dropped in slack or just built locally. There were constant questions of “which firmware are you on?” As we said, chaos.

We used localhost for rapid development of the app, pushed everything to a development site for test by the team, who is completely remote (and mostly not even in the same time zone). For their part, the team had to expand their knowledge of MIDI and really break out of their comfort zone. Markus did a tremendous amount of helping educate the team, while the team did a fantastic job of learning different workflows and having fun with it.

Because we started the app way back in 2019, we had a lot of preconceived notions about what it should look like when we started. We had some layout help from a phenomenal designer (Sydopia Design) for the other pages but the UI was too nebulous when she designed those pages to get any input, so we started from where we were. As we used the app (and learned more about how to design in React), we chucked most of our initial design out the window in favor of a far more streamlined version that we think is much easier to use. 

The reality: we weren’t sure if we’d make it.

We knew that getting this thing out the door would be a lift. Indeed, this has been a rollercoaster for us. We initially set a ship date of June 22 (at least internally; we never announced this date). At the beginning of June we knew we wouldn’t hit it, and we really hate to miss ship dates. The hardware was set but the firmware and app were not ready. We pushed it out a week. We consider a release ready when we have all the components ready to hand over to Patrick (at least more or less) and he can start working his video magic. 

We really like to give retailers two weeks’ notice when something new is coming. Two weeks and one day before release, we said we are in good shape! We’re going to make it. Two weeks before release, we called our manufacturer and said, “We aren’t going to make it!” They talked us off the ledge and convinced us not to push the release into July. 

At this point literally everyone on the team was now testing and/or writing code in support of this product.

We try to cultivate a culture of balance here, but the month of June was definitely not so much balance. Kris carried a laptop to her circus-training sessions and worked in the in-between moments. Stephen stayed up at night on his tablet pondering how to solve issues. Weekends were non-existent. Cocktails may have been imbibed at the end of the days. As much as humanly possible, we tried to keep the team from bearing the brunt of the extra work, but everyone here helped in what became a Herculean effort to get this thing done.

We finally announced on June 22, and it was a real question about whether we’d hit send on that release until that day. We looked at what remained on our JIRA board and were reasonably confident we could get there. We remain grateful to our retailers for sticking by us.

The UI app has been under constant construction as we continue to learn ways to make it better; even now we have an active board of things we want to improve and a list of features we want to implement (and we’re taking feature requests!). 

Of course, as soon as we announced, everything went off the rails. We started some plumbing work here at our house (where Stephen and Kris work) and there was jackhammering non-stop for the next week on the first floor directly under our offices. A neighbor called Kris about a stray pup and Kris is nothing if not a total sucker for a pitbull so we ended up with a stray dog on the back porch while waiting for space to open up in the LA County Shelter (we couldn’t keep him, much to Kris’s eternal disappointment because he was AWESOME). The day we started shipping the module, internet in the entire area where we live went down. We were trying to deploy updates to the website by tethering to Kris’s phone and the single wifi antenna we had (how is that possible?) that we moved from computer to computer. They kept failing because, it turned out, GitHub was ALSO down that day for completely unrelated reasons. Our manufacturer, who also serves as our distributor, also just lost power that day. All the while, jackhammering. Incessant jackhammering.

As soon as it was out the door, Stephen and Kris had a quick vacation that we planned way back in March. Because we wanted to be sure that anything that might have been missed during our test could be fixed as soon as possible, we packed every single thing we could possibly need to do firmware and website fixes on the road. We unplugged but kept the phones on with instructions for the team to phone if there was a problem. We were thrilled that the phones never rang.

So yeah. Getting the UI out the door has been a journey. Every time we release something, we say it was a team effort, but more than anything we have ever done, Univer Inter was supported by every single person here. We never stopped getting emails about this one, and we are so happy that it’s finally out. If you are in need of a way to get MIDI into your Eurorack, we hope you’ll consider Univer Inter.