#9

Thank you gentlemen. I will test this and see how it goes.

#10

Yes, this is a known problem. I think it started somewhere with 1.4 here.

@tehn I did not experience it with the new 2.0 Beta by now.

Though @sam is constantly working on it, reported bugs get a quick fix soon and the discussion on the development seems to be pretty informed ( I don not understand much of it) I would not consider the stability of the new firmware as rock solid atm. But there are some very nice features in it already…

EDIT: After a second thought I think it started with the new powered i2c board and the idea was that it was somehow masked by the i2c bug before.

> teletype : code exchange
#11

I need to check , but i think i’ve encountered this issue lately.
I was i the urge of presenting this for an installation and ended up using gate B instead of gate A without further investigation. I’ll check when i have 5 minutes…

#12

a correction - just noticed i’m actually still running v 1.3.2

#13

I updated yesterday from i believe version 1.2 to 1.4 and now i face this issue as well. Good to know its fixed in firmware 2.0!

#14

I just updated to the last firmware and two minutes later the teletype just hang…

this is the simple scene running:

#1
CV 1 N RAND 12
CV.SLEW 1 RAND 50
TR.TOG A

#2
PROB B : 75
TR.TOG B

Script one is run by the output of a sine lfo, script two by the sub of the oscillator controlled by script one.
Basically the trigger outs sort of continue to work, its the cv that hangs…

btw i notice that it never hangs when not using external triggering…

#15

Which firmware revision exactly? Just asking as there’s the official last firmware 1.4.0 and the last 2.0 firmware beta 8.

#16

both :smile:

I updated two days ago to 1.4 and yesterday to 2.0 beta 8 believing it would solve the issue but the behavior is the same.

#17

Just a quick obsevation: This doesn’t result in anything. Typo? Or what are you trying to accomplish?

#18

What do you mean by hang? Does the keyboard and screen stop responding?

(edit: and if it does stop responding, does it start again if you remove any external cables?)

#19

sometimes the screen and the keyboard stops responding, changing a scene doesn’t seem to work in thoses cases. other times the cv doesn’t work. Trigger outs seem to work however…

#20

Do you mean changing a scene using the front panel button?

And if you remove the trigger ins when it stops responding, does it start responding again?

(At the moment I’m not concerned about the CV outs and trigger outs, only about the keyboard and screen)

#21

Ok sorry for the delay, i had to strip the patch down to its basics and tried it again a couple of times…
So what i notice is this.
If the trigger input goes audio rate fairly quickly the cv outs hang.
Everything else works correctly, trigger outs continue to work as normal, i can change scenes with the keyboard and from the module itself and see that these are loaded (because the trigger outs work according to the selected scenes) but the cv outs (all of them! ) never recover, not even if i change the code or move to live mode. They come back when i power down and then up the system. Unplugging/plugging the input triggers doesn’t change anything for the cv’s as well…

#22

Does this mean that the TT hangs only occur if one of the trigger inputs is triggered at audio rate? So hangs don’t occur with e.g. triggers at 32th notes at 120 bpm?

#23

Thanks for the reply, is this on the latest 2.0 beta, or on 1.4 (or on both)?

Could you post the script on the 2.0 beta thread (along with some brief instructions)?

It’s unlikely that anything on the Teletype will be made to work with audio rate inputs, it’s just not designed for it, but I can have a look and see what’s causing the CV to stay permanently locked up, hopefully we can fix that.

#24

Hi Sam, thanks for following up on this.
I believe both because i had the problem in 1.4 as well, but since i installed the latest beta i haven’t gone back to check it…
It is true that i also did not expect teletype to work in audio rate but these divisions do not really exist in the modular, so it should be at least “protected” when inputs get too fast for it imo.
I mean first time i noticed this i had a sub osc triggering a script which at some point while wiggling just went to fast.
It is dificult to contain these sittuations, especially while performing unless you make teletype your clock and even then there is a chance to go overboard i guess.

I’ll post the script in the firmware thread but it is not something special imo, i even took out cv.slew line from it and the behavior didn’t change.

cheers

1 Like
#25

Hi Wolfgan, somehow i missed your message, sorry!
I have no way of knowing the exact bpm where this happens since my system includes only analog oscillators.

However one of them has a switch between lfo and “vco” freq. When in lfo freq i have no issue, if i move to audible frequencies the system crashes even in speeds it responds (after a specific frequency it is audible that it cannot follow the rate of change)

#26

Hey SakuI might be doing something wrong because i missed some messages:(
it is prob b:75
a and b are receiving the same trigger but i want out b to trigger less often.

#27

As stated above teletype is not made to work in audiorange. It is designed to get fed by trigger signals to start small programs and personally I do not see much use in patching audio signals into it.

Also I did experience quite a lot modules, mostly sequencers that do not work in audiorange and just hang when the clock gets too fast.

In this case I don’t see the need of a built in protection as there actually is a distinction between audio rate and non audio rate in modular. If it is possible to protect teletype from all possible user errors, fine. But I would be afraid that more firmware code would make it more unstable too.

Of cours I see that it is very frustrating when you program some scripts and then loose everything while patching cause the trigger accidentally gets too fast. I just think there are more urgent issues to solve.

#28

I am sorry but i really don’t agree with this.
First of the distinction you mention is not embedded in eurorack in any way (actually the only place i’ve seen it is i believe in Buchla systems where control and audio signals are separated). In eurorack you use the output of oscillators, self resonating filters, etc to trigger envelopes, to trigger sample and holds, switches, clock dividers, everything really. It’s part of the magic really.

Second of all teletype has 8 trigger inputs! which means it is meant to interact with the system and not only that, it obviously has comparators too so that it can be triggered by smoother curves like sine waves for example.

Of course one could use a dedicated module for clock but imo this is a unnecessary overlap when teletype is perfectly suited to perform more most of its duties and then some more. The only thing it needs is some protection.

So i truly believe it is a big problem for a module to leave you hanging in a performance ( i really couldn’t care less about “loosing” a few lines of code, no way i am going to forget them).
And i am not saying it should follow, i understand the hardware/software restrictions but definitely not hang.