^^ crow: ideas

hell yea!!!

Would this also work the other way round - syncing Norns to/from the modular clock? For various practical reasons and how everything is set up, I would not want Norns to be the main clock in my studio.

1 Like

It would be great to collect examples of low level functions that we might expect to see in other modules. Comparators, rectifiers, logic ops, sequential switches, etc. These could be useful as building blocks for more complex scripts / functions.


Yep I agree; I’d like to see just simple scripts for Druid for utility type functions e.g:

  • Shift register (CV and Trig In, Four CV outs).

  • Sample and Hold (CV and Trig In, S+H out, Quantised S+H out, Random out, etc.)

  • Simple 8 step sequencer (CV on input 1, if present, is read and assigned to 8 steps which are stepped/scanned through with Trig/CV on input 2).

  • Simple clock divider (Clock to input 1, Divide ratios on Input 2, clock divisions on outputs).

Just simple scripts in Druid like those above that would be a good start, and could be a nice intro for Crow/Code newbies.


One challenge that I see is that when not using i2c, you only have two control inputs. One of those will likely be needed for clock unless there is a way to detect voltage change on an input and use that as the clocking mechanism.

Here’s a script which treats input[1] as a clock, input[2] for data, and lets you switch between different modes and clock divisions for each of the four outputs by changing up options in a user data table (think Pam’s New Workout). You can also change the options in real-time from Druid, Max etc

Options include a S+H, slewed S+H (slew time set by input clock rate), stepped random, slewed random (slew time set by input clock rate), a few different LFO waveshapes, a trigger pulse, etc, a sequence, a quantizer, etc.


If you change the modes in real-time, will these values persist after a power-cycle, or would you need to read/write a separate configuration file, sort of like the norns preset system?

The changes would not persist - you would need to update the modes/divs/levels arrays in the script for your desired defaults.

Thanks for the response. I think it could be interesting if a script could read/write to a separate file, so you could save and load any live coding data changes, but maybe this is not currently possible.

1 Like

Norns + crow = Analogue Systems rs-35 external processor

Norns analyzes an audio input’s pitch & envelope
Encoders adjust sensitivities & ranges
Crow outputs v/oct following pitch, envelope & gate

Seems like something supercollider is more than capable of, though I don’t know the first thing.


I don’t think you’d even need supercollider. There is a norns poll for input pitch. I have already used it to send midi note data to external synths. :slight_smile: I imagine it would be fairly easy to use crow as the output.

  • Quad LFO with quadrature and divide modes (a la Batumi) selectable via live coding

  • Rotating Clock Divider emulation (minus the reset input)

  • cv step recorder (brainseed emulation)

  • Norns screen as sub-audio-rate oscilloscope?

  • Softcut based sampler with CV control over rate and sample position (probably unrealistic… I’ll have to think through this one a bit more).

It occurred to me also that Norns could expand the interface of a standalone script to give you control over additional parameters, or if a script has multiple modes, enable you to select the mode through Norns. After you select the mode, (if you selected “quadrature” mode in the LFO script, for example) I imagine you could open up a different Norns script and Crow would continue to do its thing.

In other words, standalone Crow scripts could have companion Norns scripts that exist solely to send commands to Crow that you would otherwise have to send through live coding.

Edit: after typing this I realized this probably won’t work, since I’m guessing crow won’t load the standalone script if it detects that Norns is plugged in.


Rate of change script might be doable? (paging @ParanormalPatroler)

2 inputs:
Control signal
+? (Some sorta filtering CV or S&H)

4 outputs:
Rate of change, absolute value
Rate of change
Direction of change, -5/+5 gate
Saw/ramp pulse LFO (speed and ramp direction set by rate and sign of change)

1 Like

Rate of change scripts should be relatively straightforward!

You would use the metros to calculate the average rate of change. something like this:

-- sampling time in milliseconds
fs = 5

-- placeholders for the adjacent datapoints.
oldVal = -1
newVal = -1

-- Average will be stored in here
average = -1

-- setting up the metro
metro[1].time = fs/1000
metro[1].count = -1
metro[1].event = function() 
    oldVal = newVal
    newVal = input[1].volts
    average = (newVal - oldVal)/fs

-- when you are ready to start your metro

That’s the basic idea! Then you can do whatever you want with the average to generate your output values…

You might also use the second input to determine how quickly you are sampling the firs tinput…


is it possible to have full access to druid from norns? would it take designing a norns script which “contains” druid and accepts keyboard input?

does anybody know?


Not hard, but norns screen is really too tiny (in pixel count) for editing Lua code. I guess single commands with line wrapping could have some utility?

Actually sorry, now that I think about it, there are a couple boring technical steps to make norns understand usb-serial devices that aren’t grdi/arc. But this would be good to do anyway.

Actually actually duh nevermind, crow already has a device profile on norns

1 Like

thanks for looking into this z

even if the features are limited i’d say yes, definitely

sidebar: does it make sense to build something that approaches events/limited line space/etc in some of the same ways TT does? just addressing crow via ii or serial to control the i/o ports?

1 Like

I’m going to hack a micro-terminal together for this today (hopefully!) amongst other bits. I don’t think it will be really useful in the tiny norns-screen context, but perhaps a stepping stone to exactly what you mention. In many ways it’s where I want a druid or whatever comes after that to head – some combination of live-coding with user-definable macro gestures. Starts to sound like an instrument to me!


ok cool i’ll wait to see what that looks like before asking any additional q’s

An interesting experiment would be making a super high level teletype-ish language on Norns where the individual pieces of code expanded to larger chunks of lua code that get piped over to Crow.

1 Like