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 
