Do we have any hints or hunches as to what’s going on here? A last known good version of Max that always works? Any leads of any kind? It’s software, right? Not the Loch Ness Monster or Bigfoot? We can do this?
I’m curious, why a VST, in particular?
I have two reactions to this (frankly somewhat stunning, at least to me) statement.
- This is a major problem that deserves discussion in the cycling74 forums
- It makes me wonder, what is the right way to go forward and use all of our time? Should we be putting that kind of “app” creativity into alternative firmware for monome modular modules? I can see that day approaching, but it feels like there’s some basic framework/infrustructure work in order to make it possible that is just now getting underway. (Which I am really excited about, and I can’t wait till I have some hardware I can use to join in on the fun.)
That being said, there’s something infinitely mutable/fungible with software that lends itself to the kind of creativity we’ve seen in the monome community over the years. If Max isn’t the right way for us to write software for the grid, and we aren’t ready to become firmware hackers, which of the other grid studies languages would we be wise to focus our energies on?
Here’s that link:
There is more that could be done to improve on my efforts and in turn reduce the frustration level associated with perusing the history of the monome app ecosystem.
Bitrot is a real thing, and it’s not realistic to expect every piece of flotsam and jetsam ever produced for the monome to be maintained in perpetuity. That being said, once I installed serialosc v1.4 (why does the official monome installer come with v1.2?) and sorted out a flaky USB hub that was causing me problems, I found a surprising majority of the apps still worked (to whatever degree they ever worked, which isn’t always saying much, to be painfully honest, many apps were created with a fun-time hobby mindset and aren’t exactly spectacular examples of software engineering rigor, but that’s part of the fun!)
What I think might be helpful, if we intend as a community to maintain an archive of old apps, is to add to the page some system of classification that will help a new user understand the level of polish/readiness an individual app has for use. I can think of a few categories:
serialosc support
- Works without modification with the latest version of serialosc
- Works without modification using specific versions of serialosc
- Works with the addition of monomebridge to emulate monomeserial behavior
Max support
- Works without modification with the latest version of Max, or Max For Live
- Works without modification using a specific version of Max, or Max For Live
Operating system support
- Works without modification with the latest version of major operating systems
- Works without modification with specific versions of major operating systems
Hardware requirements
- 64
- 128
- 256
- arc 2
- arc 4
- other requirements
Bugs
- Has no known bugs, just works
- Has known bugs, with workarounds
- Does not function. No known workarounds for known bugs
Adding a table to each entry in the archive summarizing this info would serve two purposes:
- Less frustration/unhappy surprise for new users entering the world of monome for the first time
- Adding serialosc support to older apps or fixing low-hanging bugs might be a nice easy way to introduce a new monome app developer to the typical tasks associated with writing monome grid apps, and this would also have the beneficial side effect of using community effort to fight bitrot.
But doing this kind of librarian/archival work takes time. When I put together the github wiki page, I was really hoping it would inspire the community to join in on my effort and start maintaining the archive as a community. This hasn’t yet come to pass. That leaves me wondering how much effort I really want to continue to put in on something that the community seems to at times regard as a lost cause.
I find this “lost cause” attitude to be pretty tragic in many ways, partially because I don’t feel we’re really all that far off from making most of these apps reliable and trouble free. Seems to me that we just need to identify what changed between major versions of Max/serialosc/operating systems that is causing problems, and then come up with fixes that adapt to those changes. I have a hunch that if we were able to fix 2 or 3 formerly working apps, we’d start to see patterns that would in turn make it easy to fix the rest of them.
Then again, maybe this whole train of thought is simply a poor use of our time. Perhaps the best course of action at this point is to cut our losses and focus on what does work. This implies cleaning a lot of cruft out of the repositories and trimming down the archive page I’ve created on github. If that’s the direction the community wants to go in, so be it, but it’s still a direction that requires effort to determine what’s worth saving. And unfortunately I’ve come across a couple of apps (Monome Notes and Monome Home are two that come to mind) that are very high quality, work perfectly with recent versions of things, and are currently only hosted in forums on archive.monome.org. These apps need to get moved into monome-community/collected/ and I’m going to take it upon myself this week to do that for a couple of them.
But I sure would appreciate any and all offers of help with these librarian/archival/QA related tasks!
Side note: It sure would be nice, when folks make new monome apps, if they’d put them up on Github. It’s not difficult, it doesn’t cost anything, and it makes the chances of your app continuing to be available regardless of changing circumstances much much higher. It also makes it about 1000x easier for multiple people to collaborate on your app (and I’m seeing that collaboration is absolutely necessary, as this community teaches itself about the vagaries of things like Max for Live autofocus, etc). A forum is not source control. The entire community would benefit from a small amount of additional effort, recognizing that even when we are engaged in a hobby coding project, a minimal amount of rigor with regard to software development best practices pays off for everyone in the long run.
Sorry for writing a bit of a novel. I’ve been an observer of the monome community from the very earliest days, and finally bit the bullet, bought a grid, and jumped in with both feet last year. I knew what I was getting into, and it has been every bit of both inspiring and frustrating as I expected. I love this crazy eclectic mess of folks and all the insane beauty we create. I think it’s worth caring for. I hope you agree.
