In case anyone is still tuning in out there, I thought I’d drop a (long overdue) post to let you know where things are at.
My absence from this blog has been necessitated by an ongoing project with Livid and Bitwig to get controller integration working between the two. I learned a lot of things and met cool people, and you’ll be able to check it out very soon indeed! But, alas, it’s taken a large toll on my productivity in Live.
I’ve been working fairly constantly on many aspects of Monomodular over the past several months, you can see the progress on Github. I can’t thank you enough for your participation in this ongoing process; bug reports and feature requests are always welcome and needed. There’s still a lot of work to do (it’s endless), but I’ve made some major breakthroughs lately, and a tentative version of b996 has made its way to my production machine and I’ve been testing things for the past several weeks. It’s looking good so far 🙂
This monster I’ve created has, quite frankly, become far too large for me to manage by myself. This is a large part of the reason it’s taken so long for me to get Live9 integration working. Constant updates to Live’s _Framework have caused uncountable delays, as every time I get things working, they change vital elements that I then have to track down. This is compounded by the fact that my own personal setup relies on Push, which is the most frequently (and drastically) changed component of their Python library. It’s more than a little frustrating.
I’ve basically rewritten the entire project from scratch, and this is the other primary factor for the delay. I’ve endeavored to remove the “tweakiness” from the fundamental design, so there isn’t a need to enter “modMode” or assign individual modAddresses, instead things “just work”. I have started writing mods that don’t require m4l, but live in Python and just do their thing alongside the m4l mods.
There was a huge need for some universality with the internal structure of my code. I found myself spending far too much time over the last year making the exact same revisions to countless versions of similar scripts with only minor variations, and addressing for “weird” controller configurations (like Base or CNTRLR) were a constant impediment. I’ve removed the need for all this, thus opening up a pathway for improved ease of integration for almost any arrangement of buttons or knobs (or whatever) into Monomodular’s framework.
For what it’s worth, I’ve had this mostly finished for six months, but couldn’t work on it due to other commitments. With some of that behind me now, it’s time to git’r’dun.
What you may already know (because I’ve said it before) is that some very fundamental things are changing about how Monomodular works with your controllers. There will not be a dedicated “modMode” in b996, nor will it be necessary (or possible) to assign mods to “modSlots”. Some of you have been concerned about how this will affect your workflow, and you’re not alone. I’m using this stuff as well, after all 😉 I’ve been testing a few different methods of dealing with this, and the results are encouraging. With the b996 release, there will be a new DeviceSelectorComponent which allows selecting any device in your set (no matter how deep it’s buried in a rack, etc) based on the name you give the device. The device chooser screen gives a visual indication of what type of device is assigned to which button in the selector if you have an RGB capable controller, as well as whether or not a device is linked to the selector slot and whether the slot is selected. In addition, there will be a “modLock” mode, so that a mod can be selected and then “locked” to prevent the controller from wandering to different devices as they are selected in Live’s view. These new features will definitely need some tweaking (both technically and ergonomically), but it’s a good start and I’m so far enjoying the workflow.
What you probably don’t know unless you’ve been peeking at the newest files on Github is that I’ve been working on some NEW material. Well, not actually new. Well, actually, I’ve been working on it for years. Okay, so it’s not new at all. BUT: its new”ER”. What the heck am I talking about? Good question.
Plinko2. My favoritest patch ever, but I’ve ran into far too many limitations when needing to make additions or changes to it because I’d long ago converted the main engine over to Java. Soooo, I decided to rewrite it a bit. And then I decided to rewrite it a lot. Like, completely. Now everything is native Max and javascript, mostly done in [poly]. It works extremely well, and is head and shoulders above the original. It’s not quite complete yet, but it’s as functional as the original and much faster, more robust even in its current state. There are more new features than I can list (or remember right now), but my own favorite is “trigger mode”, in which you can play the plinko board like an instrument in real time. It was always my original intention for this patch to be an instrument as well as a sequencer, but it was very difficult to implement with the way things were in the old version. Now it works beautifully 🙂
Jove. This is a working title for my audio TapeLooper patch, which I’ve been working on for years and have finally gotten into a really functional state. Not many of you have tried this one out, and for good reason: it required a bunch of third party Max Externals that were really picky about what they would run on, and documentation was scarce due to the patch’s ever evolving state. I’ve been wracking (probably wrecking is more like it, or wretching) my brain on this one for a long time. It is, for me at least, the “squaring of the circle” I’ve been talking about all along, and although it is far from finished, it is finally perfectly functional and very cool.
Root. This is some hardware that I’ve been designing over the last several of years, and it has taken up a good bit of my time over the last couple of months. It’s an evolution of the looper pedal that I’ve been using for the last couple of years to control Jove, but I’ve compartmentalized it, added 4 RGB LED’s and a Livid Brain Jr. to control it all. I’ve written a control surface script for it that automatically connects to 4 instances of Jove or Live’s Looper; it’s capable of displaying their states and controlling their functionality. Additionally, it does some nifty things like device control and scene banking/launching. It’s still a work in progress, but at some point it will probably be available for purchase. I still need to integrate the 7-segment LED display that hasn’t arrived yet, but I’ll be posting some pictures as soon as I get around to taking some.
Hex. It’s coming along nicely. I don’t know how much more I will get done before b996 release, but you’ll see a bunch of cool things for it in the near future, including clip exporting, new modes, and up to 128-step sequences for each of its parts.
Skin. This is a hand-percussion patch for assigning zones to Push or Base and playing the entire surface as a single drum with different voices. I designed this specifically for using these controllers as “Electronic Tabla”, but the patch is useful for lots of stuff.
Base. Base support has been ready for a long time (it was actually the first surface I prepared for b996). It’s pretty cool.
Livid Device Support. That’s right, no more “this works with this script but not that script, but that doesn’t work with this script”. You’ll see synthsteppr, drumsteppr, and accent support in Monomodular. However, you’ll probably want to use hex anyway, since it does what they do in a single patch plus a whole lot more.
Codec. I’ve completely redesigned this script yet again (it seems to have become an annual task), since it has become the main Livid controller I’ve been using in conjunction with Push. It’s pretty darned cool. Most of the functionality has been retained from the original, but no more double-press weirdness, and the ergonomics are generally much better now.
New mod.js. I’ve completely rewritten the mod.js object, which will mean very little to most of you. But if you get an inkling to make something with Monomodular, it will be much easier with the new version.
That’s about it. As I mentioned, I’ve got working versions of Base, AumPush, and Codec, and will be fleshing out the rest of the scripts over the next several weeks as I work out little bugs I’ve found in the current test versions. I’m anxious to get this done, and I’d love to hear your input.
Oh, and one more thing: I’ll be cleaning up b995 for a “re-release” (or, a proper release, as it was never actually officially released in the first place) for all of you that don’t wish to move forward with the b996 stuff right away.
Happy blinking 🙂
a
Posted in Uncategorized
