#8

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.

1 Like
#9

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.

2 Likes
#10

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
#11

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

#12

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?

#13

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() )
1 Like
#14

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?

#16

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' )
    }
3 Likes
#17

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

#18

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

1 Like
#19

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

1 Like
#20

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.

5 Likes
#21

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 :laughing:

#22

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:

  1. Connect crow to computer via usb cable.
  2. Connect to crow using commander m4l device on one midi track.
  3. Add Outputs m4l device on another midi track
  4. Create another track that has drums for fast amplitude variation.
  5. 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.
  6. Crow should translate the envelope follower for a minute and then it will switch to previously uploaded druid script.
  7. To make it work with envelope follower again, disconnect and connect crow using the usb cable.
  8. After a few iterations of the last step Ableton should crash.
#23

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.

2 Likes
#24

I have been having difficulty getting crow to talk to a second ansible using the ii.ansible commands. They both work just fine when the ansible address is set to 0, but they don’t appear to receive commands when set at 1 or above.

using max I can successfully send ii.ansible.trigger(1,0) to the unit addressed as 0, but don’t see any indication of response when the unit is addressed as 1 and I send ii.ansible.trigger(5,0) or any trigger on a channel above 4.

Am I missing something here?

Thanks for the help, really enjoying max and crow!

#25

This is because crow only currently supports a single ansible connected at once. The good news is it’s 1 line of code to enable it, I just had no idea that multiple ansibles could be chained like that! I’ll get this into the next release.

2 Likes
#26

Thanks, glad to hear! I’m just starting to scratch the surface on the 1st one, so this will help me from rushing into complexity. Just getting around to integrating old max patches and crow and it is a blast

1 Like
#27

I received my crow somewhere in January. Is there a way to check its firmware version?

#28

Type ^^v into druid or the maiden REPL. Or from max use the help patcher which has a page for these system actions.

1 Like