^^ crow 1.0.3

cfurrow · 2020-01-23T01:18:08.121Z

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!

dani_derks · 2020-01-23T01:21:25.750Z

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 · 2020-01-23T01:29:25.081Z

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 · 2020-01-23T04:32:33.385Z

Hello,

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

Screen Shot 2020-01-22 at 9.30.58 PM

Trent · 2020-01-23T04:48:53.972Z

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 · 2020-01-23T04:58:39.410Z

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 · 2020-01-30T05:45:04.593Z

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 · 2020-02-23T05:22:49.443Z

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 · 2020-02-23T06:03:22.168Z

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

Oootini · 2020-03-15T11:39:04.144Z

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 · 2020-03-15T13:04:55.400Z

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 · 2020-03-15T20:27:05.032Z

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 · 2020-03-16T20:18:22.218Z

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 · 2020-03-17T22:56:42.523Z

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

zebra · 2020-03-18T02:02:10.918Z

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

desolationjones · 2020-04-10T17:12:30.243Z

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

Galapagoose · 2020-04-10T21:32:24.109Z

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 · 2020-04-10T23:58:50.811Z

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

Wisdom.Water · 2020-04-12T14:15:53.602Z

Hey everyone, been messing about with crow and max for live devices available for it today and had some issues:

When connecting crow first via commander, then on another track i set up the Outputs m4l device and mapped an envelope follower coming from a drum track to one of the crow’s outputs. Due to envelope follower being very fast in terms of responce, crow would first work fine by outputting envelope follower’s output via output 1, then it would always switch to one of the previously loaded druid scripts. Then I would have to disconnect crow and plug it back in to get the envelope follower output working again. After a few times my Ableton would just crash completely.

Is this caused by very fast cv signal from envelope follower not being able to pass via usb? Is this is a bug? I did try to slew the envelope follower a bit, but the same issue would come up sooner or later.

Steps to recreate:

Connect crow to computer via usb cable.
Connect to crow using commander m4l device on one midi track.
Add Outputs m4l device on another midi track
Create another track that has drums for fast amplitude variation.
Drop a m4l device called envelope follower to the drum track and map it to one of the outputs on the Outputs m4l device for crow.
Crow should translate the envelope follower for a minute and then it will switch to previously uploaded druid script.
To make it work with envelope follower again, disconnect and connect crow using the usb cable.
After a few iterations of the last step Ableton should crash.

Galapagoose · 2020-04-12T14:43:22.527Z

Hearing that crow would switch to a previously loaded druid script seems to me that it might have been running the whole time.

When you connect crow to Max/M4L, the current script is nor cleared unless you specifically ask it to, instead the messages from Max are being executed ‘on top’ of whatever is running.

Easiest solution is to run the ^^clearscript command (from druid or comnand center). You’ll only need to do this if you have since uploaded a script from druid.