So I got the device working with ansible! But I had to use a different send/receive channel than commands_to_command_center for it to work. But no issues when I used a separate send/receive connection and added that to the ^^command_center device:

Maybe there is a more elegant way of doing this which doesnt involve altering the ^^command_center device?

Either way it does exactly what I wanted (starts and clocks kria when transport starts in ableton live and resets kria when live transport is stopped). The clocking is somewhat jittery but it works well for my purposes!

Thanks again for everyone’s help :slight_smile:

1 Like

Your issue was probably that you did not pretend an index - the message sent to the command center should start with an integer index (the address of which command center to talk to) before tell_crow:

1 tell_crow ‘<lua chunk>’

or

2 tell_crow ‘<lua chunk>’

(Or another higher address)

Sorry that part is only relevant to working with command center - should have mentioned it in my previous post.

1 Like

sam’s spot-on. if you want to post yr device, we can help modify it to match what ^^command_center expects! will also fold that into some sort of documentation

Ok cool! Just updated it for all outgoing messages to include an index of 1, but I am away from my eurorack at the moment so can’t test it.

Here is a download link for the device. Feel free to edit / improve / streamline !

1 Like

awesome! looks good, index message is formatted how it needs to be, but I’d encourage adding the address functionality if you want to share the device with others. as it stands, multi-crow folks couldn’t easily use it. lmk if you need help with implementing this – ^^dual has it pretty straightforward if you want to crack that open?

beyond that, [loadbang] works fine but [live.thisdevice] is the recommended way to bang on load in m4l devices. it sends a bang from its first outlet when the device is loaded, but also when it’s re-loaded or saved, which is a bit more tightly integrated within Live.

1 Like

Thanks for the pointers! Updated and added address functionality now:

27

Voila !

5 Likes

Trying to sequence ableton from crow. ^^ins shows connection and receiving cv, setting cv-to-note to arpeggiator works as expected, but when set to alt input none of the triggers into input 2 are registering. Same issue on both of my crow’s. Latest firmware. Anyone else having this issue? (thanks for moving this Dan, didnt see this specific topic will give it a read through)

1 Like

hmm, not seeing this same behavior on my side:

jumpy thing on the right is the CV-to-trigger.

  • are you on Mac or Windows?
  • have you tried executing ^^c from druid or crow.clear() from norns? there keeps being weird reasons to have to do this, so it’d be a helpful data point
1 Like

Thanks Dan! On mac, Fixed it with ^^c in druid. Working as expected now.
Cheers!

1 Like

I had no idea Crow was out. This looks awesome!

1 Like

finally diving into crow/max programming after some life curveballs

I’m having no issues sending commands to ii devices, but I’m also interested in getting information back from them, and I seem to be having trouble with this.

for example, if I tell_crow ii.kria.help() I get back a list of all the commands and such. tell_crow ii.kria.scale(2) (or whatever number) changes the scale accordingly on Kria. But if I try tell_crow "ii.kria.get( 'scale' )" as stylized in the printout from kria.help(), I’m not getting anything back from crow. I don’t get any string evaluation errors which is promising, but getting nothing in return makes me think I’m missing something here.

really stoked for what you build! your max patches have been very inspiring.

i thiiiiink getters are getting fixed in the coming update (there’s a beta release on the crow github if you’re feeling curious) — not at my synth at the moment, but if you can confirm that the commands also don’t return anything in druid then that’ll rule out max troubles.

woop, @voidstar has it. sorry for confusing the convo!

1 Like

Getters don’t return anything. They initiate a query; a callback occurs when the data is returned from the queried device. You have to define what happens to the asynchronously returned data within the corresponding device’s callback event. You can pass the data into max with a print.

2 Likes

@ellips_s @voidstar
To clarify, by default, ii.kria.get('scale') queries do print a message to the usb port. This is in the form ^^ii.kria('scale', <number> ). This is true for all ii getters.

The reason these might not be appearing in your max patch, is because any message from crow preceeded with ^^ gets sent out the first outlet (and typically into a [route] object). Try printing the rightmost [route] outlet and you should see the responses.

@dan_derks ii getters have been working in general (since launch!). It’s just that Just Friends hadn’t implemented them on the JF side.

2 Likes

apologies for misrepresenting + misunderstanding!

Im running kria on ansible into crow to play ableton midi instruments with cv-note and ableton is one step behind kria. The trigger must be happening before the cv note is updated? Is there a way to sync kria and ableton?

paging @Lervais, you feeling good about sharing more about the device you made?

1 Like

Thanks @dan_derks, The kria_command device is awesome and Ive got it working with the transport controls, I can start and stop ableton and kria listens when teletype clocking is enabled. But still the grid sequence is one step ahead of ableton, is this your experience as well @Lervais ?

Reseting my transport in ableton to 1. 1. 1 sets the grid to the second note in the sequence, not the beginning. So i tried using teletype to KR.RES 0 0 and instead of setting the grid back to the first note in kria it actually jumps it to the very last note in the sequence.

1 Like

Bizzare! Maybe worth mentioning that kria_command resets all parameters of kria when the ableton transport is stopped (so it has to be playing first), the playhead location shouldn’t make any difference.

Your issue goes beyond my understanding of kria, but the fact that TT clocking is also misaligned might enable an easier diagnosis. Maybe something is up with how your ansible is reading i2c messages? I wonder if anyone else has had similar issues with kria_control?

Strange indeed, Ive now lost any CV pitch via i2c from kria, teletype polls 0 and jf only responds to triggers. Might be a conflict of teletype and crow both talking to ansible at the same time? Can’t figure out how to get it back, power cycling doesnt help, will reflash the firmware.