#21

uZeus should work - that’s how I eventually updated.

#22

Hello!
I seem to be having some issues getting Just type to work properly. I was trying to use the JF.VOX command last week and Just Friends wasn’t responding. I fussed with getting my commands in hopes that I had some typos but unfortunately I did not. I was hoping it was a loose i2c connection or something but I double checked the connections and everything looked alright. My next guess was to update the firmwares on both the teletype (last beta before 3.0) and JF (whatever came on it when I got it in February). This did not change the behavior.

My problem:
When I use a VOX command through TT the JF stops responding on that channel. Lights no longer respond and no sound is generated. It only happens on the channel I apply the command to. It requires a reboot to bring the JF back but the behavior persists.
Does anybody have any advice?
Triggers work just fine as do the limited other commands I know via Just Type, but the VOX command does not. TT registers it as a valid command which was also concerning because I was hoping it maybe had someting to do with the newer TT firmware changing some of the ops/commands.
I am trying to sequence JF via TT patterns using:
JF.VOX 1 N PN.NEXT 0 6.
Am I overlooking something obvious? This was all working perfectly well until about a week or two ago. I dont recall and bumps to the case or power issues so I’m hoping it isn’t a hardware issue.

Thank you so much for your time and help! I. Love. This. Combo.

#23

JF.VOX chan pitch velocity is the expected command. if you’re inputting

then you’ve got your channel and pitch, but no velocity.

JF.VOX 1 N PN.NEXT 0 6 V 5 should get ya something

4 Likes
#24

How, holy mackerel. And just like that we’re back on track. I thought it was working without the “V” in there before but maybe I was just away from it for too long. Embarrassingly I knew full well of the structure, I just tried everything but.

Thank you so much, Dan!

1 Like
#25

Hi all,

I’m hoping someone can help me with some crashing issues I’m having with Just Friends/Just Type.

What happens is when I type in certain JT commands Just Friends crashes and stops responding(no lights, no sounds, no voltages) until I power cycle.

The commands that I’ve had trouble with are:

JF.VTR and JF.NOTE

Executing either command will crash Just Friends within a few seconds. However other simpler commands like JF.TR, JF.RMODE, and JF.RUN work without any problems at all.

So far I have tried reinstalling the latest(v3.1.2) firmware a few times, as well as looking over my i2c connections.
I do have Just Friends routing i2c between TT and W/. Could that maybe be the problem?

I’m new to the whole i2c and tt world so I have a feeling it’s probably just user error, but I just can’t seem to figure out where I’m going wrong…

Any help much appreciated!

#26

when this happened to me I realized that I had misconnected one of my I2C cables: it was turned upside-down.

1 Like
#27

Hmm I’ll go back and check those again. Thanks @alanza

#28

I went back and checked the connections again and removed W/‘s i2c connections this time. Still having the same problems though…

This time JF.VTR 0 5 was working, but once I changed it to JF.VTR RRND 1 6 RRND 3 5 it crashed. I noticed the crash was kind of slow this time, over a few seconds the sound and led’s just slowly faded out until it went completely unresponsive.

I am using the breadboard cables that you strip apart, and while I am sure that gnd scl and sca are aligned on TT and JF, I can’t be sure that the individual wires are not twisted or facing different directions. I wonder if that could cause issues…?

#29

the order of GND, SCL, SDA is the same on TT and JF.

it sounds like you might need a powered busboard. can you try connecting just TT and JF with a short cable and see if you’re still getting the issue?

1 Like
#30

also I see a typo: the final argument of JF.VTR expects a value in volts, so it’s entirely possible that you’re seeing nothing because values between 3 and 5 are way too low. Actually I suspect that this is the problem? Can you try JF.VTR 1 V 10?

2 Likes
#31

Hi @scanner_darkly,

I’m using 21cm length cable, and yes only connecting TT and JF. I had thought I had read somewhere that a powered bus was only needed for 3 or 4 (or more) connections. Is that not always the case?

@alanza Ah good catch! Though I’m pretty sure that was a typo here and not in my TT script, since the script would function and produce noise for a few seconds before dying out, and then JF would go dead even if switched to Sound/Cycle…

Though JF.VTR 1 V 10 has been going strong now for about 3 minutes so maybe it was just typo errors…

1 Like
#32

Now it’s working just fine! I think it must’ve been typo errors as you thought @alanza… :confounded:

Thanks for the help!

2 Likes
#33

Not to unnecessarily make a problem, but I don’t think it’s possible for a typo on TT to cause JF to crash. Seems more likely to me that you were having the ‘no bus board’ issue which was solved when you removed W/ from the bus.

Just to be sure though - are you running the JF.MODE command at all? That changes how the module works pretty fundamentally so things can seem broken afterward, but it’s just functioning differently.

I’m curious to hear more about the ‘slow’ crash. Does this mean the ‘correct’ sounds continue to play, but the level & leds fade away? In my experience crashes usually result in a high-pitched noise being emitted by all the outputs, so if the correct tones are being output from JF, I would suggest that it is not crashing (ie. becoming unresponsive), but it is in a state that you aren’t anticipating. Again, could be caused by the JF.MODE command.

Curious!

3 Likes
#34

Hi @Galapagoose,

I had thought I ruled out W/ being the problem as I experienced the ‘slow crash’ after removing it from i2c… Though if I had typed in the command with the typo error above - JF.VTR RRND 1 6 RRND 3 5 (missing the V) then this would explain the fading out behaviour…

I had been playing with JF.RMODE without really understanding it at all, but after experiencing the ‘crashing’ I would revert it to JF.MODE 0 with no change in behaviour.

I also had some strange behaviour late last night where running JF.TR 0 1 would trigger all but 6N, with 6N not responding until a power cycle.

I’m pretty convinced this is all just me not knowing what I’m doing though… :man_shrugging:

I will explore further today, this time being more aware of my just typing, and will share any further issues I may run into that I can’t figure out on my own :upside_down_face:

#35

Sounds good - hope you enjoy it!

Just a quick point that JF.MODE and JF.RMODE are completely orthogonal. RMODE 1 is just like plugging a cable into the RUN jack, and is unaffected by JF.MODE messages. The ‘RUN’ behaviour is different in all of these cases - I often worry the just type functionality adds to the confusion :confused:

Regarding the JF.TR 0 1 not triggering 6N, I’m guessing you had previously used JF.VTR 6 x where x is some small number. The value of a VTR will latch and essentially become the ‘volume’ or ‘level’ of that channel until a new VTR (or NOTE or VOX) is received.

So yes! Hopefully all will become clear soon & glad there’s not a hardware problem (though you may need a powered bus-board when reattaching W/ it seems).

2 Likes
#36

to add, the typical i2c failures one might see from teletype would look like either some commands getting skipped occasionally (this would be a good indication you need a powered busboard), or it will freeze completely (won’t respond to any keyboard or front button presses). if it freezes immediately after the first i2c command then you likely have i2c improperly connected (SDA and SCL lines switched, for instance). if it freezes after running for some time you probably need a powered busboard.

2 Likes
#38

@Galapagoose Ah that sheds some of my confusion!

Today is my first day exploring the Synthesis JF.MODE… It is making me so happy to use :heart_eyes: It’s such a tactile and FUN experience. I’ve never experienced anything like it with modular or elsewhere…

Thank you!

@scanner_darkly thanks for the clarification on that!
One strange unrelated behaviour I’ve noticed is TT occasionally double triggering scripts when triggered by Tempi. It seems like maybe it happens when I touch the case or the tt keyboard but I can’t be sure… Is it possible this might be caused by a grounding issue somewhere in my system…? Apologies for the ceaseless need of helping these days :sweat:

1 Like
#39

not entirely sure - it’s possible that tempi produces triggers in a manner that makes TT double trigger, but hard to say without looking at the actual tempi output on a scope. i don’t have a tempi to test unfortunately.

you could try debouncing on TT itself, try adding this as the first line in your script: IF LT LAST 5: BREAK. this will ignore triggers that arrive 5 ms or sooner after the previous one, try using different values too to see what works best.

1 Like
#40

@scanner_darkly Thanks! Tempi is able to output triggers instead of gates actually so maybe that will fix it, if not I’ll try that.