This isn’t a score, it’s just an outline for the extended version of rain. I’m shooting to do a compressed section of it for February: the end of the D2 section going into the start of the A prime section. In case you can’t read my scribbles, D2 is marked “big windchimes”, E (E1 to E2) is marked “arps” and then the return to A’ is marked “air/small sounds” like the original A section.

For the big windchimes into the arps section maybe I’m thinking about trying a gesture that passes a click around to larger pulses until the sound fills up into the arps section. I can’t do a full realization until I finish the rest of the mixer channels, but a gesture that looks something like a journey from unamplified relay clicks; expanded slowly by pinging the pulsar oscs through their resonators gradually; maybe starting with wood and growing into the cymbols, until it’s a big ringy resonant clatter going into the arp section. Or something like that. It’s an outline because these types of plans always change when listening gets involved.

Seems like a good excuse to dust off the firmware for the microcontroller that triggers the relays though. I’m just planning to start with four channels on the passive mixer with one relay per channel. The relays make a small (still, fairly loud) mechanical click when activated, but they also switch the output of the passive mixer channel from its main out to its aux out. The aux outs on each channel dangle, so this could mute the channel, but it could also route it to an alternate channel if the aux is patched in to the secondary input of a different channel. (Or really anything else I guess.)

For now I’m just focusing on the mechanical clicking. The microcontroller (a teensy 3.2) has some room to grow but I’ve only just soldered on enough components for two relays. There’s enough space for two more but there are also lots of open pins on the teensy, so as long as there aren’t power issues I should be able to add more relays to the same board later, too. I’d like to end up with ten in total, I think. Lots! Maybe four for the mixer and six to use with solenoids and motors, but I’ll have to play around and see what’s useful.

Since there’s so few things to control, and they’re all just toggling states on and off, I think I can leave my serial triggering scheme for astrid basically as-is. The way I’ve prototyped it so far is to make messages a single byte, and toggling states with bit flags.

In a prototype for a firmware controlling six solenoids, there were two sets of flags: the index of the solenoid and its state.

enum SOLE_SELECTION_FLAGS {
    SOLEALL = 0,
    SOLE1   = 1, 
    SOLE2   = 2, 
    SOLE3   = 4, 
    SOLE4   = 8, 
    SOLE5   = 16, 
    SOLE6   = 32, 
};

enum SOLE_STATE_FLAGS {
    SOLE_STATE_TRIGGERED = 1,
    SOLE_STATE_LFO_ENABLED = 2,
    SOLE_STATE_RND_ENABLED = 4
};

typedef struct sole_t {
    char flags;
    unsigned long trigger_start;
    unsigned long lfo_start;
    float lfo_period;
    unsigned long button_press_start;
    int lfo_triggers;
} sole_t;

Triggers in this prototype don’t map to state changes, they cause a short toggle on and toggle off again. That makes more sense for a solenoid than a relay, so if I stick with this approach I’ll add another toggle state type.

The other state that can be enabled and disabled per channel is the LFO. In this prototype it was an internal LFO that ran at a fixed rate. The idea is that the LFO is independent of the triggers (and toggles would be the same probably) so that you can engage the LFO, but still send arbitrary triggers on top if you like.

What’s the point of the LFO if I’m already scheduling triggers with a laptop that is certainly capable of acting like an LFO? It’s a small point, and maybe moot. There’s a limit to the serial baud rate, and I’d like to try driving the relays as fast as I can. The relays have a top speed too though, and I don’t know which is faster (my guess: the relay is faster than 9600 baud) so this might be a non-issue. I probably won’t bother implementing it in this next iteration but I’m going to keep the basic scheduling approach, so it’s possible to add back in again later if I want.

Leaving out the LFO for now keeps the messaging simple, too. I’ll have to add another byte or two if I want to support sending reasonably high resolution values as payloads to control the LFO speeds.