hey hey!
AH, that’ll do it, yes. ^^command_center is only necessary if you are not supplying your own [crow] object inside the device – it has one built into it.
if you’re going to route to ^^command_center from another Max for Live device, instead of using a [crow] object, just use s commands_to_command_center with an index so ^^command_center knows which crow hardware to talk to, eg.:
all of the crow m4l devices are built this way. ^^command_center is necessary because there can only be one [crow] object running at a time. just like druid – it creates a special bond with the hardware, so having multiple [crow] objects talking to one hardware destination creates the connectivity + communication troubles you experienced.
yes, it was not patched properly – but also, crow’s adsr operates as a description of an envelope, rather than one which waits for a note-off event. so the timing of each stage just executes linearly, after it is triggered. i will work on a traditional adsr patcher, but I do think that using an external envelope module with a note-on-to-gate patch would be best – and i’ve posted a thoroughly tested one here: ^^ recipes: max / m4l snippets for crow 
