^^ crow 1.0.3

[Galapagoose]

crow 1.0.3

It may be out of character, but these crows can now fly in non-linear paths. The output library has been updated with ‘shapes’ to apply over voltage slopes. This means easy ‘sine’ LFOs, plucky ‘log’ envelopes, or many weirder options…

New ii functionality allows for multiples of a single device to be spoken to (eg. Telex-I, ER-301), and some backend improvements have made the system more responsive, giving faster metros & ASLs.

To update crow, follow the instructions on the update page.

crow 1.0.3

• NEW ‘shape’ parameter for outputs
• NEW Kria ii commands extended @csboling
• NEW multiples of the same ii device are addressable (eg. ii.txi[1] and ii.txi[2] )
• FIX CPU usage dramatically reduced (improves overall responsiveness)
• FIX ii messages are now clamped to available range
• CHANGE 6 timers accessible (for metro(), delay() ). was 7.

Trent

Crow’s Max & Max-for-Live patches have also been updated with big stability improvements, as well as some patching refinements. See the new thread!

Quick reference for the new shapes (based off these interpolators):

'linear'
'sine'
'logarithmic' -- or 'log'
'exponential' -- or 'expo'
'now' -- go instantly to the destination then wait
'wait' -- wait at the current level, then go to the destination
'over' -- move toward the destination and overshoot, before landing
'under' -- move away from the destination, then smoothly ramp up
'rebound' -- emulate a bouncing ball toward the destination

Most asllib functions now take a shape parameter

output[1].lfo( 1.0, 5.0, 'sine' ) -- 1Hz, +/-5V sinewave

Whenever you use the .volts output assignment, the .shape will be applied. To slide to 5V over 100ms with a logarithmic shape:

output[1].slew = 0.1
output[1].shape = 'log'
output[1].volts = 5.0

Or if you’re writing ASL directly you can simply tack on the shape at the end of a to call:

to( 5, 0.1 ) -- 'linear' is assumed
to( 5, 0.1, 'linear' ) -- same as above
to( 5, 0.1, 'over' ) -- applies an 'over' shape to this segment

Reference documentation has all the new details called out.

[Justmat]

very excited about shape! Thanks for the update

[cfurrow]

I can’t seem to update my crow. I successfully updated to 1.0.2 a while back but now I get this message after running the update firmware command (osx_linux-update_firmware.command) in terminal:

dfu-util: can’t detach

I tried the force method as well. I have a feeling it’s something simple…
Any suggestions? I’m on OSX, btw.
Thanks!

[dan_derks]

i’ve seen that as well, but it resolves after a few seconds for me. does that persist for more than 5 seconds or so? does your crow just remain in DFU?

here’s a video of a successful update process, for the curious:

[cfurrow]

You know what? I think my update was successful! My update went just like your video. The ‘dfu-util: can’t detach’ message threw me off.
Thanks a bunch, Dan!! : )

[jasper_ryder]

Hello,

This is my first time trying to update crow and I am having trouble. Here is what I end up with?

[Trent]

You need to setup dfu-util. Install Homebrew, and then install it run the command brew install dfu-util. It’s simply missing the library needed for the update.

[jasper_ryder]

Thanks @Trent, I had recently flashed my Ansible so I thought all of the Homebrew things were good but apparently not. That did the trick alright.

[synthetivv]

@Galapagoose

FIX CPU usage dramatically reduced (improves overall responsiveness)

This checks out! I’ve been working on a Norns script that sometimes makes very rapid changes to Crow outputs, and with earlier versions of Crow, it was prone to glitching out and leaving the outputs at seemingly arbitrary values. I thought this was probably just an artifact of the way Norns & Crow communicate, so I was planning to somehow throttle the data sent to Crow — but this update seems to have made that completely unnecessary. This is great!

Really looking forward to investigating all the different slope shapes, too.

[midouest]

I just attempted to update my crow to 1.0.3 and ran into the issue where the operation hangs at Resetting USB to switch back to runtime mode. It seems to be hanging indefinitely. I tried killing the script with Ctrl-C, but now crow is no longer being recognized by druid. I am still able to force it into bootloader mode by shorting the i2c pins, but I can’t seem to get 1.0.3 or 1.0.2 to install successfully.

Output of firmware update operation:

➜  crow-v1.0.3 ./osx_linux-update_firmware.command
dfu-util 0.9

Copyright 2005-2009 Weston Schmidt, Harald Welte and OpenMoko Inc.
Copyright 2010-2016 Tormod Volden and Stefan Schmidt
This program is Free Software and has ABSOLUTELY NO WARRANTY
Please report bugs to http://sourceforge.net/p/dfu-util/tickets/

dfu-util: Invalid DFU suffix signature
dfu-util: A valid DFU suffix will be required in a future dfu-util release!!!
Opening DFU capable USB device...
ID 0483:df11
Run-time device DFU version 011a
Claiming USB DFU Interface...
Setting Alternate Setting #0 ...
Determining device status: state = dfuIDLE, status = 0
dfuIDLE, continuing
DFU mode device DFU version 011a
Device returned transfer size 1024
DfuSe interface name: "Internal Flash   "
Downloading to address = 0x08020000, size = 315996
Download	[=========================] 100%       315996 bytes
Download done.
File downloaded successfully
dfu-util: can't detach
Resetting USB to switch back to runtime mode

[midouest]

I went through the steps to recover from an unresponsive state, after which I was able to update the firmware without issue!

[Oootini]

trying to use the new 1.03 rebound shape. am i doing some wrong here?

I’d like to use the crow outputs to each trigger a separate (complete?) “bouncing ball” volume envelope to control a VCA.

	for i=1,4 do 
		output[i].slew  = 0.001
		output[i].ar( 0.05, 0.5, 7, 'rebound' )
	end

do i need to write a complete ASL function for this?

[Galapagoose]

You need to pass the result of the ar call to action, rather than call it like you have:

output[1].action = ar()
output[1]() — execute the env

—or assign and call at once
output[1]( ar() )

[Oootini]

@Galapagoose

output[1].shape = ‘log’

Thanks Trent.

Am I expecting too much out of this? I’ve patched a bouncing ball patch using VCAs and AR envelopes in hardware before with very musical results. Should this feature approximate that? Or does it need to be coded by hand?

function init()
    input[1]{mode = 'change', direction = 'rising'}
end

input[1].change = function()
    output[1]( ar( 0.1, 3, 10, 'rebound' ) )
end 

This snippet gives a bouncing ball type effect, but it seems to taper off way too quickly. So I guess I need to code a function to also modulate the decay of the AR envelope too?

[Galapagoose]

@Oootini

Am I expecting too much out of this?

Probably. The shapers are based on the set of interpolators from this page where our rebound shape is the easeOutBounce from there. You can see from the diagram that the ball bounces three times before coming to a stop on the 4th.

You could absolutely do a bouncing ball simulation on crow though. Below is a sketch in that direction (though untested and likely some typos).

HEIGHT = 10 -- initial height
TIME = 0.2 -- half of first bounce time
ENERGY = 0.5 -- how much energy is preserved each bounce (out of 1.0)
height, bouncetime -- will change as the ball bounces

function init()
  input[1]{ mode = 'change', direction = 'rising' }
  output[1].action = bouncing_ball
end

input[1].change = function()
  reset()
  output[1]()
end

function reset()
  height = HEIGHT
  bouncetime = TIME
end

function bounce()
  height = height * ENERGY
  bouncetime = bouncetime * ENERGY
  if bouncetime < 0.002 then reset() end -- reset the ball when done bouncing
  return height
end

bouncing_ball =
loop{ to( bounce, time, 'log' ) -- bounce is a function & will be called each time around
    , to( 0, time, 'expo' )
    }

[Oootini]

Thank you! I’ll see if I can use that

[zebra]

i love that penner’s easing functions are all over the place

[desolationjones]

Finally getting around to scripting for my faderbank. Why are only the first two fader values available? Looking at faders.lua confirms this.

[Galapagoose]

Wow! You must be the first person to actually use that support. The reality is none of the core developers have a 16n so it was untested.

Can you confirm both faders are working correctly? I’ll happily copy it out to all 16 channels if everything is working correctly.

[desolationjones]

@Galapagoose

Can you confirm both faders are working correctly?

I should clarify that this is with the MSW F8R device, which shares the same I2C messages as 16n faderbank. There are only 8 faders on this device, but they are set up to respond on 1-8 and 9-16 identically. I have two F8R which I could configure with different addresses eventually but I’m only set up with one right now.

From druid, sequential reads of faders 1 & 2 on F8R #1, address 0x34, with fader 1 @ halfway point (~5V) and fader 2 maxed (~10V):

ii.faders.get(1)
^^ii.faders([[1]],5.024414,1)

ii.faders.get(2)
^^ii.faders([[2]],5.024414,1)

ii.faders.get(2)
^^ii.faders([[2]],9.980469,1)

ii.faders.get(1)
^^ii.faders([[1]],9.980469,1)

ii.faders.get(1)
^^ii.faders([[1]],5.024414,1)

So there’s something a bit squirrely with reading a fader and getting the previous fader’s data instead. But the values look good. I’m not versed enough with druid to set up an ii.faders.event yet.

Let me try pulling reads from Teletype and make sure this is a Crow issue and not a F8R one.

From Teletype:

FB 1
8232

FB 2
16352

FB 1
8232

No apparent issues. Other than me being a dweebus and trying to edit this post with my Teletype keyboard