#1

There’s a handful of Whitewhale and Meadowphysics on the second hand market, which makes sense as both of these have been incorporated into Ansible in some form or another. Full disclosure, I’m amongst those that are trying to sell theirs, so this is possibly a self-serving thread however, given the open nature of WW / MP, and the number of them that are currently available for cheap…seems like a great target for folks contemplating interesting alt-firmwares.

I’ve dug up a few threads that I found in a quick search.


Earthsea is still unique, it hasn’t been incorporated into Ansible. I know the interface of ES is different than WW, but - seems like an opportunity for a clever person to port ES to WW with an updated interface that allows for glyph CV control without the knobs.

All that said - open source is largely driven by developers scratching their own itches. Hope this thread encourages identifying some itches, would love to see the WW / MP 2/3rds of the original trilogy find some utility!

2 Likes
#2

i’m quite curious about the reason people part ways with WW and MP. ansible is definitely one of the reasons, since it implements a variation of meadowphysics and kria, so i can see how having both, say, ansible and WW could be redundant, especially in a small system.

but you also have the original WW, a sequencer that is very powerful in its own right - i just feel sometimes that people tend to see it as a straight forward 16 step sequencer, which is only a small part of what it can do. so while having more firmwares (there is orca too) might make them more desirable there is still so much to explore in what we have already. having spotlight on NEW THINGS is understandable, but i’d love to see more explorations done in older things too, and new features added - how about microtonal support for white whale, for instance? (i actually have another WW mod that’s been in the works for a very long time now - need to finish it when i get some free time).

10 Likes
#3

It’s a good question. For me, I’m fickle and wanted to change my entire approach, more than a specific issue with either of these modules.

A message I’ve seen in a handful of other threads is that there’s an interest in getting away from a quantized feel to compositions. Earthsea’s longevity backs that up IMO. Meadowphysics has plenty of ways to create complex patterns that don’t feel rigid, its inclusion in Ansible is probably the reason folks look to resell it.

If I were in the alt-firmware game, I’d look for ways to take that clockless / organic Earthsea approach and apply it to the MP / WW hardware.

Also this. Great idea.

What about Tx / Ti style firmware? Those modules are well loved. I know they’re teensy-based and have different hardware, but maybe there’s room for Teletype extensions folks want to experiment with? @tehn delivered totally open hardware, seems like a shame to restrict it to a small set of uses. go forth and alt

4 Likes
#4

MP has a great panel for basic 8-tr-output drum machine ish sequencers, euclidean rhythms, etc. it has clock in, clock out, and a param (clock) knob.

plus, MP is by far the simplest firmware ever. a great starting point for modding.

7 Likes
#5

I’ve dabbled a bit with custom WW firmwares. One thing I wanted to end up with is a really small core where you just hook into a pulse function call and then write everything on top of that.

It’s pretty easy to strip away stuff but having a blank slate to start from might help people start making their own programs for it.

3 Likes
#6

Naive question: if one were to make an alt firmware for MP can the hardware support toggling between modes in the way ansible does?

I’d like a basic tr style trig seq with probability and a live input mode. Maybe some trig nudging and rolls.

1 Like
#7

no— ansible has a ton of extra code to manage flipping between all the modes. it’s complicated at first glance, not good for a beginner project.

#8

I asked in another thread a long time ago but cannot locate it at the moment. Can the current version of Kria be ported to WW or MP? With WW, obviously there would be a channel shortage. I would love to have a permanent version of it that’s consistent and up to date tothen free up my Ansible for Arc.

#9

i really want to do a proper template for firmware development at some point. there is this arc template i did a while ago, it’s pretty outdated by now and is arc specific, but comments in main.c might be helpful for somebody who wants to try a hand at firmware development.

what i’d love to do is create a template with clean separation of layers, so that hardware specific bits, event handling and the actual logic are separated in a way that could make it easy to re-use the same firmware on different devices (including aleph and vcv rack). i’m hoping to get this done as part of work on orca 3, whenever that happens.

it would also be great to come up with conventions for preset management / app switching / USB save and things like that and make them part of the template, so ideally all you have to do is program the logic and configure the hardware. this would also encourage exchange of presets between different apps, if we come up with a flexible serialization protocol. create a sequence in white whale, transfer it to kria, etc etc.

13 Likes
#10

WHAT YES OH MY YES PLZ. an incomplete sentence for a complex reaction.

4 Likes
#11

For the VCV Rack ports, I tried to keep as much of libavr32 as possible and minimize changes to the firmware code, primarily so the Rack environment could be useful in experimenting with new features and totally new firmware. I had some plans to do some of that myself, but of course now my project queue is full up with other Rack-related ideas, as these things tend to go…

After I finally get around to fixing the last connection bugs and releasing the module, I’ll write up a guide on how to add new firmware to existing modules in Rack.

3 Likes
#12

i’ve dabbled a bit in c programming, and one of my original intentions of doing so was to eventually make my own firmwares for these modules. perhaps this summer after i graduate college i can finally make time to do so.

question: has anyone done any module firmwares incorporating tilt? i recently got a 64 grid and can imagine all kinds of crazy cv/gate outputs from flailing it all around in real time.

somewhat related to the tilt question… i also know owners of older monobright and non-128 sizes sometimes feel a bit left out of the monome modular party. thus encouraging the creation alternative firmwares and increasing ease of access to doing so would then not only benefit the coders, but the community as a whole!

1 Like
#13

Closest I got with this was having a pulse_on and pulse_off and some generic key handling. But nothing that would be context aware or have privately scoped variables (though I reckon you could do this with a good ol’ fashioned struct and some function pointers). Grabbed this from the graveyard if any folks want to peep through it: https://gist.github.com/zzsnzmn/45f614052f9c4f2e82ddf419a6f8617d though really the majority of the code in that could be removed since it’s just keeping a track of pressed keys and updating CV on key press— actually not super generic.

#14

I know nothing about coding but would like to throw out an idea for a general trigger sequencer/pattern generator that combines Kria and MP into one Grids sized frame. Make the top four channels MP, make the bottom four Kria-style trigger sequencers. Or even make each channel selectable but still have interaction with the other channels regardless of program (an MP channel could reset or provide a clock to a Kria channel and vice versa). The config button could be used to move through the “pages” in Kria (omitting the pitch, octave, and scale pages) to save patterns or even generate Euclidean patterns for Kria that MP could trigger. Just brainstorming.

EDIT: After thinking about this again, I think what I’m imaging is just an 8 channel trigger sequencer where each channel can be set to operate like MP (counter style) or Kria (step sequencer style) and each channel regardless of operation has control over clock and gate length but can also send clock or reset functions to another channel. Basically combining functions that already exist in both the MP and Kria apps but doing something that you couldn’t necessarily do with these modules as they exist today.

Other bonus channel modes could be a Euclidean sequencer and Turing Machine style random pulse generator (something I didn’t really want before but see how it could be an awesome way to interact with this sort of firmware).

Sorry to be putting all this out there - just hoping someone could make it come true!

#15

the mode switching can be done. i started but never finished alt firmware for the mp which is centered around a high res clock. the tentpole mode was/is going to be a live’ish rhythm sequencer with clips. the lesser modes like an arc based 8 channel clock generator do work (mostly)

i don’t have a ton of time to work on it right now as i have a few other irons in the fire but i would like to get back to it eventually

EDIT: i should add the the above firmware includes my first attempt at refining the mode switching logic in ansible as such it might be a good template to start with. if memory serves one of the things it tries to do is give each mode the ability to do some cleanup before it is switched out.

4 Likes