Help. i2c Just Friends reverts to single output when Ansible is externally clocked

Monome
1

I’m preparing for a SXSW event next week and am experiencing strange behavior with my Ansible x Just Friends i2c combo. It starts up fine but eventually reverts to outputting just on IDENTITY or IDENTITY and 2N.

  • Ansible is the leader, JF the follower, and nothing else is on the bus
    [EDIT: I’ve also tried Crow or TXb starting the chain of bus cables
  • JF is in poly mode getting notes from the first track of Kria.
  • The behavior happens on both of JF’s, the silver and gold cloud versions.
  • Kria sometimes becomes unresponsive when interacting with the Grid.
  • I swapped the i2c cable for a fresh one but the issue persists.

Any help is appreciated as I literally have two days of preparation left before I leave for Austin. This was a last-minute decision to use JF with Ansible and I really do want it to work.

I’ll update JF’s FW to the latest just in case it’s not already there and hope that fixes it. I’ll report back.

[UPDATE]

When JF is externally clocked, it is not round-robin-ing through the voices from 1 to 6 and back to 1, continually cycling from left to right. It exhibits seemingly random selection of outputs favoring IDENTITY and occasionally 1 or 2 others.

JF and Ansible are both on the newest firmware. I tried updating the firmware again but I get no device present errors as per this post.

2

I updated JF and I can tell that I’m on new FW now because CURVE has a different layout/response where the extremes are bright and noon is more sine like (it used to be darkest at max).

BUT, this didn’t fix the issue. JF is still reverting to the single IDENTITY output.

3

Okay, I think I sorted it out. And as usual, it was user error. I had Ansible’s Reset input patched to receive a pulse when starting the transport in my DAW but something was wonky with that routing/connection and I think JF was being restarted at like audio rate or something wacky. Not quite sure what exactly was going down, but after resetting my cable and reset device in the DAW, everything appears to be working.

Nothing like a heart attack as the deadline approaches :man_facepalming:t2:

2 Likes
4

Nope. The behavior is back. I feel like I’m losing my mind.

5

It appears that the behavior happens only when externally clocking Ansible. If I leave inputs 1 & 2 unpatched, it doesn’t happen… or at least hasn’t happened yet.

When externally clocking, I’m running a clock signal from Bitwig’s HW Clock Out using the ES-9, sending 50% duty cycle or 10ms trig, both of which result in the behavior.

6

The behavior is such that it starts off with all 6 voices, then they start dropping off til it’s down to one.

Occasionally, while externally clocking, other voices will activate and then stop again. It’s combinations of two or three outputs, with IDENTITY always being one of them. If I switch to SUSTAIN or CYCLE, they all activate. I feel like it’s something in Kria or almost like a RUN mode is stuck. I tried patching RUN and sending offsets and only got some tonal shaping, the outputs stayed the same.

Question: Kria’s DURATION page is not duration with i2c, right? Sounds like Velocity. Whatever the case, any settings on that page result in "the behavior’.

Then I thought it was an i2c bus power issue, so I connected Crow. Same behavior. Then I swapped Crow for TXb. Same behavior.

7

Rapid tempo changes from the DAW reactivate latent voices but then they drop off again without retriggering.

8

If I clock ridiculously fast (16th notes at 222 bpm) all voices activate. This feels like a gate issue, as if notes are getting stuck.

9

After externally clocking and experiencing ‘the behavior’ I can remove the clock and the behavior persists

10

I reviewed my follower settings and went ahead and disabled all of Kria’s tracks for every follower except for JF where it’s receiving from track 1 and the first of the three buttons in the top right is selected indicating that JF should allocate notes polyphonically.

What is happening is that notes are being allocated around the outputs seemingly randomly. It’s not round-robining the way it normally does, but triggering the same output multiple times before moving on to another output where it stays for a while. But then eventually resorting back to IDENTITY.

11

Are you connected to crow or tt? Edit, just saw crow.

12

Yep. Just Crow. And FWIW, the option to map each track to one output as a synth voice works as expected: the first four outputs of JF each play respective tracks in Kria. Which, actually is pretty nice. Really piano like.

It’s not what I’m aiming at, but it’ll be my workaround for SXSW if I can’t sort out the first polyphonic mode.

13

Let me make sure I’m understanding the three follower operating modes.

In the top right of the follower configuration page, you can select the operating mode for the follower. These modes have different meanings for different followers.

Just Friends, left to right:

  1. allocate notes polyphonically (JF.MODE = 1 and JF.NOTE is sent for each gate)
  2. map each track to one output as a synth voice (JF.MODE = 1 and JF.VOX is sent)
  3. map each track to one output as a function generator (JF.MODE = 0 and JF.VTR is sent).

In Kria, the velocity value is calculated based on the duration parameter.

My understanding is that it’s similar to when using Just Type with Teletype in that the first mode is a round-robin mode that takes the monophonic sequence and relays it around all six outputs so that they ring out over one another similar to the way the module Rings will sustain four notes at a time in its 4-note polyphonic mode.

And then the second mode, each track plays one of the first four outputs of JF.

But then there’s the last statement here:

In Kria, the velocity value is calculated based on the duration parameter.

What are the implications of this? Does this statement refer only to the function generator mode?

Does it just mean that there are no duration settings in Kria when using JF like this and that instead it’s velocity settings? That’s what that page sounds like to me. I don’t hear any change in note duration, but I do hear a change in velocity.

14

I’m getting the same behavior regardless of the TIME setting on JF.

15

If I lengthen JF’s TIME, I get a single monophonic but very legato voice.

If I shorten JF’s TIME, I get a single monophonic plucky voice.

16

I’m now unable to connect to Ansible to reload the firmware. I just keep getting dfu-programmer: no device present. even when completing these steps. Though, step 4 there gave me the same no device present message.

17

hey bryan – oof, very sorry to hear about the trouble + hope all’s well otherwise!

i was also able to get JF into the same state as you described, so it seems like there’s a potential bug here. i’m glad the each-track-as-a-single-voice is working and hopefully will do in a pinch for the event.

just to confirm other bits:

patching

JF means ansible in this case?

fwiw, this shouldn’t matter if everything is working correctly – an aggressive restart will just polyphonically allocate the first kria step across the 6 voices.

duration q’s

correct! increased ‘duration’ settings will increase the velocity argument to JF over i2c.

yes, expected! if it helps, the i2c polyphonic allocation doesn’t wait for the voice to complete its running envelope – the allocator just steals the voice for the new note. so TIME won’t help or hinder the i2c-controlled allocation.

modes + non-ansible repro case

you’re totally correct, yeah. actually, it might be useful to try and reproduce those i2c calls using crow. you likely don’t have time, but i’m curious if you get the same behavior when you disable JF-i2c mode on ansible and send the following commands to crow via druid (i’m also running this, but good to have many hands with this sorta thing):

ii.jf.mode(1) -- then ENTER
notes = sequins{0,3/12,7/12,1,14/12,19/12}:step(sequins{4,2,1}) -- then ENTER
clock.run(function() while true do clock.sync(1/2) ii.jf.play_note(notes(),7) end end) -- then ENTER

eh, since i can repro with an ansible/jf combo here, i’m unsure if reflashing your unit will change anything. but noted for additional investigation!

2 Likes
18

First off, thanks Dan!

Oops, yes I meant Ansible.

I’ll see if I can try this today. I might need some hand holding on it, though :smirk:

19

I dug out the old computer running MacOS 10.14 and reflashed the newest firmware without loading my PSET json file from the USB drive and Ansible is fixed! Maybe there’s an issue with my M1 computer as it wouldn’t re-update Ansible after the first time everything went awry.

I’m relieved that it’s now working properly and so now I have one day to do some practice runs on the set before the event :grimacing:. But hey, one day is better than no days.

Once I’m back from SXSW I can look into testing this M1 setup because I definitely want to use it moving forward for updates.

2 Likes
20

False alarm. It’s not fixed. It just took longer to happen.