Looks like there might be a conflict with the midi.event for the midi_out_device (line 151) when there’s only one device for both incoming and outgoing midi (maybe it’s blocking the event from the one on line 81)
If I comment out line 151 - clock in works OK.
just updated with param for crow clock output.
OUTPUT 1 on crow sends a 0.5ms pulse at 5v if the param is on.
here’s the diff, if you want to see how easy the code change was:
Had an idea that I think would be fantastic.
Would it be possible to add the morph sequence and randomise functions to be controlled with gates on crows inputs?
Then we could have endless synchronised sequence evolutions.
Love being able to sync awake via crow. Here’s awake crow JF ii, marbles/rings and w/. Thanks for adding the clock output @tehn!
I’m sure someone’s already done this, but since it was a good learning exercise, I’ve just created a copy of awake using the Karplus rings engine. Sounds lovely 
Can, of course, share if anyone else wants a copy.
I’d be game for a share of this!
20 characters of PLZ?
20 chars of OMG gimme gimme.
Ok, I’ll bundle it up and share it later this week.
I added trigger probability to awake this morning. Is that something other people could see themselves using? Should I make a PR?
yes
i would like to see it
thanks dude
sounds good! curious to see the interface.
interface is just a param at the moment.
edit: i ended up adding to the step page. alt + enc2 sets probability.
This would be fantastic! Thanks Mat!
It is done 
Ok, the Karplus-Rings version of awake can be found here:
Zip https://github.com/GoneCaving/awake/archive/KarplusRings.zip
Github: https://github.com/GoneCaving/awake (in a branch called KarplusRings).
After installing the Karplus Awake its giving me duplicate engine error. I tried deleting the awake script and polyperc engine from the Karplus Awake folder but im still getting the issue. Am I on the right track here?
Do I need to remove the Karplusrings engine from the folder as well?
It also exists under “we”. I made some changes to the naming of the synthdef which seemed to fix some issues I was having. I suggest you delete the copy under “we” unless you have something using it.
so, a weird and unfortunate fact about the supercollider class inclusion system (as presnetly configured) is that all .sc files in ~/dust/code are “visible” at the same time. and of course multiple copies cannot be tolerated by supercollider.
so yes, if Foo.sc [*] exists in ~/dust/code/we then it must not exist anywhere else in ~/dust/code and vice versa.
so unfortunately the user/maintainer of the system must manage script->engine dependencies at the moment. script writers that use existing engines should probably not include local copies of them, but instead clearly indicate that their script requires the installation of another project. this isn’t ideal and it will certainly change at some not-to-distant point.
([*] technically, any file defining class Foo, but this is the convention)