Just Friends v4.1

This is very interesting to me. I had assumed the notes were stuck at full level, but this sustain-level suggests something more sinister in the code.

It is probably related to the large number of devices on the bus, which suggests JF has some bug that happens when communication slows down. I say this as the only 2 people that have reported hung-note issues since 4.1 have large ii bus configs. I think 4.1 is helping as it speeds up ii transfers dramatically, but i didn’t actually find the root cause of the hung notes (because i couldn’t reproduce them).

I’ll just hang some caps on the bus and see if it fails :smiling_imp:


So is this slowdown related to high traffic, many devices or both?

Thanks so much for looking into it, let me know (here or PM) if there’s anything I can do to help!!! Would you like a video of the behavior?

I’ve been running your scene for a couple hours but at M 100. It’s really nice, especially with Triple Sloths slow modulating ramp, curve & FM, and with some clocked delay and reverb, and a pulsing kick courtesy of my STO :slight_smile:

I’m not experiencing anything that I would describe as stuck notes, though, if as you say JF is retriggering successfully, wouldn’t any note get retriggered by your test script at least once a second?

Edit: also, FWIW, this is my actual setup:

  • Teletype, green PCB, with backpack w/pullups, running CB56E83 (latest official beta, linked here: Teletype 3.2+ feature requests and discussions)
  • JF w/ 4.1
  • 2 X W/ running 2.0 beta 4
  • TXi
  • TXo
  • Ansible running 3.0.0
  • Crow running 2.1.1

But so I think that gives me more pull-up resistors than you probably have on your bus. My understanding is that JF 4.x and W/ 2.x both provide a small amount, as does Crow. I don’t know how the backpack compares to the black PBC Teletype version.

more resistors in parallel = less resistance
less resistance = faster rising edges
much less resistance = threshold issues (i don’t think anyone really has this issue, though)

1 Like

I don’t think high-traffic is the culprit, as you said it occurs regardless of whether TT+JF are the only ones communicating.

Reading your script again, it’s possible that both JF.NOTE calls will happen with the pitch set to 0 (the 2nd one always is). The other report I’ve heard is that the hang happens only when sending 2 notes at identical pitch, at the “same” time.

If this is the cause, it would suggest that the hung note is always the bass note. Is that the case? Or does the pitch of the hung note change?

I’ve had a very simple TT + JF x2 patch running for about 20 minutes now and haven’t experienced any hanging notes (and I was experiencing them occasionally before).


J RRND 1 12
JF.POLY N P.RND V 5 (jf.poly is like jf.note for two JFs)

My i2c bus has TT, JF x2, TXo, TXi, w/.

And fwiw my experience with running @a773’s scene was the same as @xenus_dad’s - I don’t think I had any hanging notes but the script makes it hard to tell.

Also thank you very much @Galapagoose, these changes are fantastic! Especially happy to have intone working the way it was before.


This is working amazing for me! I think mine shipped with the 4.0 firmware, but the “sweet spots” are definitely very apparent!

A little composition from yesterday with JF’s new firmware: 2NDLIGHT by Mark IJzerman | Free Listening on SoundCloud

Thanks Trent!


Top post updated with 4.1.2 which solves the hung notes issue. Thanks to @a773 for the video that helped me understand what was going on. This will likely be the last JF update for a long while, but feel free to report any further bugs (though the firmware seems very well tested at this point).

For the technically curious

The hung note issue turned out not to be related to the ii bus at all. The issue was in the Vactrol model, specifically in transient mode, when the current vactrol level was higher than the level of a new note.

Practically this would occur when a voice was stolen by JF.NOTE (or by sending a command to a busy voice with JF.VOX), and the new velocity was set to a low value, but the previous note was still ringing at a higher level than the new note.

This would primarily happen with fast note retriggers, when TIME was set very long (counter-clockwise). Setting the velocity with a random value of a very wide range emphasized the problem.

One thing I will note is that due to the way the Vactrol model works, when you steal a loudly ringing voice and set it to a low level, the volume won’t instantly drop to that lower level. Instead it will decay from the current state toward zero. This is expected behaviour, though it may be confusing to those more familiar with a traditional ADSR voice-stealing style.

One way to think of it is that as TIME moves CCW, notes will all tend toward the highest velocity in the sequence. Great for making swirly drones, but not great for expressive playing from a keyboard etc.

Speaking of keyboards, I think the ii interface is now solid enough that the crow m4l patch for JF can re-enable ‘sustain’ style playing…


Amazing, thanks, both for caring, listening, fiixng this and for your superb module!

Have had it running for over 30mins now, no stuck notes!

Thanks, so much!


Thank you @Galapagoose for fixing the bug and for the new firmware! Will try it out as soon as possible.

@desolationjones I will also test the new OPs! Am I correct that for single JF users the new OPs are

  • JF.TSC
1 Like

Yes, those plus the knob/CV getters:


(here’s the beta if anyone’s looking)


This compressor is interesting to me.
At one point I owned two JF and I love the module, but I started hearing something in the summing of the 6 signals which sounded harsh to my ears, some sort of clipping, and then I just couldn’t un-hear it, so I sold mine on.
If this is now addressed, I’d love to try again.


20 chars of Great track!

1 Like

This is what I’m most pleased about with this update. It’s a lot smoother and less harsh now with the compressor added.


My two Jfs work a treat!

Great to hear, thanks. Will order!

Aside - boy! the gouging on Reverb for used JF is depressing. The free market!


Updated JF last night and the process went smoothly. Began patching and had no problem finding the
2 o’clock sweet spot. Thanks @Galapagoose for this update :slight_smile:

Regarding that 2:30 sweetspot, while I was figuring out what had happened to the scaling, I found an interesting way of thinking about what it represents.

The equations

For positive Intone values (0…+1):
freq = TIME * (1 + Intone * (n/d - 1))

For negative Intone (0…-1):
freq = TIME * 1/(1 - Intone * (n/d - 1))

Effectively these are linear crossfades from 1 to n/d)

n/d is the ‘ratio’ setting of the channel. Defaults to the number on the panel. eg 3N is 3/1.

EDIT: For those wondering, the 4.0 version (which is no longer), used a continuous exponential mapping. I thought a continuous curve through +ve and -ve Intone values would sound better, not realizing the transform changed the mid-way relationships.

freq = TIME * ((n/d) ^ Intone)

When Intone is at the maximum, the outputs represent the first 6 elements of the harmonic series.

When Intone is at 1/2 in the above equation (this is the 2:30 location) the frequencies can be seen as 6 consecutive elements of the harmonic series, starting at the 2nd harmonic. ie, for an imaginary 100Hz fundamental, tune IDENTITY to 200Hz, and the outputs will follow (300,400,500,600,700Hz).

If you decrease Intone to 1/3, this effectively starts the series at the 3rd harmonic [300,400,500,600,700,800]. You can continue up the harmonic series, by adjusting TIME & INTONE.

Thinking about it this way made a lot of sense to me in terms of building harmony. Might be fun to make a crow or TT script that CV’s TIME & INTONE such that you can scan up the harmonic series…


This makes me want to see if I can find that 1/3 spot on the knob!


Thank you for sharing the math! I was really curious about it.