#103

Okay great, this sounds like the clock is working. However since First overrides the default change handler (which sends change messages out the serial port), I would not expect you to be getting input[1] = 1 at the top of druid like that - in fact this is an issue being discussed, if/when these values should be sent back to druid. Can you try reloading the First script by typing ^^First into druid? (Assuming you are on the v1.0.0 firmware - this can be confirmed with ^^v). When First is what’s loaded, you should see running 'First' script. when you ask crow what script is running by entering p in druid.

This is with nothing patched? With nothing patched on Mangrove except for Formant -> your output, I would expect to hear a constant tone if you put all 6 knobs on the module at 12 o’clock, in either switch position. Mangrove is certainly capable of a lot of scratchy tones, especially with some combination of Barrel, Formant, and Pitch turned counterclockwise.

crow calibration I’m afraid I don’t know about, but I would maybe try unpatching everything, resetting the case, then running calibration? Afraid I can’t be of much help here. I see this same message when I have crow jacks patched but when I re-run cal.test() after unpatching I get Calibration ok!

1 Like
#104

Hi again thanks for your reply. Scratchy mangrove tones only after trying to patch v8 and envelope to air from crow.

I’ve tried the ^^F command many times with no result/change. I’m running 1.0.0. confirmed and reinstalled using the /.flash.sh command on a freshly downloaded file from the crow docs on GitHub.

#105

Weird! It sounds like crow is mostly behaving as expected - accepting your input from druid and responding to change messages. Maybe you could try unpatching everything except crow output 1 to Mangrove v/8, setting Mangrove to “constant wave”, then running

input[1].volts = 0
input[1].volts = 1
input[1].volts = 2

to confirm that you jump up an octave each volt?

To recap, here is the First patch that works for me.

Mangrove FORMANT out -> output
Mangrove settings:

  • switch: constant wave
  • PITCH, FINE, FORMANT, BARREL: all at 12 o’clock
  • AIR: fully to the left
  • AIR CV attenuverter: 2/3 to the right

Clock -> crow input 1
crow output 1 -> Mangrove PITCH
crow output 2 -> Mangrove AIR

Here’s what all I’m running / seeing printed in druid once I’ve got this all patched:

> ^^f
lua bootstrapped
input loaded
asl loaded
asllib loaded
metro loaded
ii loaded
crowlib loaded

> input[1].threshold = 1.0

> input[1].mode = 'change'
#106

Hey there, very grateful again for your responses. I’ve set my mangrove to the settings which you’ve listed without anything but formant > audio output and I get an even tone which sounds normal. I plug in crow output 1 > mangrove pitch and the tone is immediately waaay higher. Like barely audible because the pitch is so high. I plug in crow output 2 > mangrove air and the tone is louder, but the pitch doesn’t change.

The commands which you list at the top don’t cause any change in pitch with mangrove patched as you said.

Could my crow be faulty?

#107

That could be because I totally messed that up! Should be

output[1].volts = 0
output[1].volts = 1
output[1].volts = 2
#108

Ah despite trying those as well I still just get an even, very high pitched, tone. :confused:

My sense is that this is probably a calibration issue… After having tested a bunch of other stuff with your help. When I run cal.test() i still get the same Calibration failed. error stating I need to unplug jacks which have nothing patched in.

In fact, when I power cycle my case (MN powered skiff) and open Druid, I get the Calibration failed error without even inputting a command.

#109

this is very unexpected to get a calibration failed with everything unplugged— it may be defective (despite my testing in house :confused: )

can you email help@monome.org? and we’ll take care of it

thanks @csboling for your help!

#110

Hey there, thanks for jumping in. I sent an email there earlier today.

Yes, very very grateful for you responding and trying to help me out @csboling

#111

I’m having a pretty similar experience.

When you reboot if you do ^^c what happens when you enter a “p” command prior to uploading a script?

It still feels like something is off, but I can usually get it to respond “no script loaded”. Typically, the unit again freezes when I try to upload another script, but upon another reboot I’m able to get Crow to accept a new script (if it had been cleared on the previous boot).

Taking some advice from above (sorry I lost the thread). Removing clock inputs does seem to yield better results when uploading a script. With the clock removed, I’ve been able to get 2-3 scripts uploaded before the unit freezes. Where w/ a clock plugged in I can’t get any more than 1 script uploaded before another upload will freeze the unit. Where I can sometimes get a couple uploads. “r script.lua” seems to crash my unit almost every time. Once it freezes it appears Druid still recognizes the device until I power it down and receive a , but it is unresponsive to commands from max or druid.

Not sure what I’m doing wrong here. I have 1.0.0 installed on my Crow and I’m using the recent install of druid. Would there be any benefit to flashing my Crow again?

#112

^^c actually freezes crow even after a fresh reboot!
I actually can’t change scripts; I had an unfinished sketch loaded up and now it’s kinda stuck on there. Trying to reinstall the latest firmware doesn’t do the trick either, it’s still got the same script I was messing with a few nights back… and again, any time I try to clear the script or upload or run a different one, it only loads the first three libraries into crow and then freezes up, and Druid becomes unresponsive to sending commands unless I power cycle crow.
Sall good though we’ll figure it out :ocean:

#113

Try setting crow into bootloader mode and then running erase_userscript.sh, which is found in the same folder as flash.sh.

2 Likes
#114

oooooh. I’m about to go to work but first thing when I get home :slight_smile: I wouldn’t be surprised if my script broke crow.

#115

If you any issues getting into bootloader mode, remember you can always use this method!

1 Like
#116

If I start an LFO like so:

output[n](lfo(4,2))

The only way I can find to change the rate, is to reassign it. Something like:

output[n].action = lfo(1,2)

But this appears to wait to the end of the cycle before switching, and it also seems to (sometimes?) have a bit of a delay before the new LFO starts.

Is it possible to dynamically change the rate of an LFO so that it can smoothly change rate at an arbitrary time/point in it’s cycle?

2 Likes
#117

Here ya go - this handles changing lfos without creating entirely new actions - off the top of my head, pretty sure the effects wait until the next break point to take effect, but I could be wrong…

period = 2.5
amplitude =5

dynamicLFO = lfo(function() return period end, function() return amplitude end)

output[1](dynamicLFO)

then send new vals - you do not need to create a new action:

period = 0.4

amplitude = 1.3

instead of creating new variables “period” and “amplitude” above, you can also take advantage of the output tables:

output[1].rate = 1
output[1].level = 5

output[1]( lfo(function() return output[1].rate end, function() return output[1].level end) )

more info here

2 Likes
#118

it would be awesome to have these little functions and patterns collected somewhere in the docs (thinking of your quantize function as well) so people didn’t necessarily have to go digging through the forum or reading other people’s scripts to figure it out.

just a thought. since you can’t include external library functions in a crow script, it might be cool if this type of thing was centralized somewhere for reference

3 Likes
#119

See this thread

Maybe the index can gather or link to collections of code…

#120

In addition to the scripting reference and scripting tutorial, I think that bowery can serve that purpose to an extent - while some of the scripts are more complex (e.g. boids.lua), others are clear demonstrations of brief, useful concepts on crow (e.g. samplehold-basic.lua). I’ll upload my quantizer script tonight as another basic example!

Having said that, there is of course always lots of room for more educational analysis of scripting, whether in video, text, or tutorial form - something I (and many others I’m sure) hope to continue working on!

and the relevant discussion thread:

2 Likes
#121

Yes, that appears to be the case, so unfortunately, this doesn’t solve my problem. It is a useful construction though, so thanks for the example.

#122

In an attempt to solve my own LFO problem, I’ve come up with a (very) rough solution. The script below is just a proof of concept, and this example is limited to a sawtooth wave, but it does seem to work pretty well (as far as it goes).

I’ll make a more full featured version and post it in the script thread when I’m finished, but I think I’m about done for the night so I thought I’d post the rough version here in case anyone finds it useful in the meantime (or has any better ideas…).

Does anyone know what the smallest interval that is recommended for the metros? Values as small as .001 seem to work, but I wonder if that’s a Bad Idea.

--- cv controlled lfo
-- in1: LFO rate
-- out1: LFO

function init()
    resolution = 0.01
    rate = 1
    depth = 3
    phase = 0

    input[1].mode = 'stream'
    input[1].stream = function(volts) rate = (volts / 5) + .05 end

    lfo = metro.init{event = run_lfo, time  = resolution, count = -1}
    lfo:start() 
end

function run_lfo()
    phase = phase + ((1 / rate) * resolution)
    if phase > 1 then
        phase = 0 -- + (phase - 1)
    end

    output[1].volts = phase * depth
end