#225

Not 100% sure really. Try M 25? And work your way up maybe.

Even then M 25 is 16th notes at 600bpm…

(FYI M can’t go below 10, you can check this by reading back the value of M)

Correct. It requests the value and does nothing with it. Likewise, the following is a perfectly valid teletype script

1
2
3
4
5
6

Six lines that do nothing.

#226

Damn, you are right - I thought that I don’t hear much difference below M 10 but did not invest further. :grinning:

I just had it crash at M 12 after 3 or 4 minutes then it ran at M 25 for 20 minutes before I switched to M 20 and it immediately crashed.

When it crashes it affects Teletype and Ansible - all other modules on the i2c bus keep working.

1 Like
#227

When i say crash i mean that it stops responding (keyboard, front panel etc…) and everything is frozen in its curent state (leds etc…).

1 Like
#228

I tried some more things and it seems that below M 25 it starts freezing.

I also noticed that I get a lot of screen glitches when I introduce CV slew. This is not connected to i2c read anymore though.

#229

Another documentation update:

Now contains a list of ops that are missing documentation (a long list at the moment) as well as the changelog.

The code is on GitHub, in the docs branch. There are instructions for building the docs in the readme.

Are people generally happy with the format?

If so, I’ll get it merged into the main 2.0 branch, and open up a thread for contributions.

Once that’s done I’ll see if I can help up with the new i2c issues. But I’ve only got till next Saturday…

1 Like
#230

I did not contribute to this and don’t want to discourage someone, esp. because I would really love to have pdf documantation to read offline, but I find it a bit irritating to read that the blocks that are showing the commands and the short explanation are all centered and of differnet sizes.

#231

It may improve once there is more content in them. That might just be the algorithm that Pandoc is using to calculate the widths struggling with the tables being empty. If not I can always left align the tables (but they still won’t be full width necessarily).

Another option would be to have just one table with everything in it.

After that, the time that I would have to invest to fix it becomes disproportionate to the return (IMO).

There is also the possibility in the future to use the data files to generate an even more compact ‘cheatsheet’.

#232

Ah okay, I did not know that it is auto generated. So it will certainly adapt somehow when everything gets filled.

Thank you for starting the new documentation!

#233

Those are all good choices. Some other good open-source monospace fonts are Fira Mono, Hack, and Input Mono. Fira also has many nice proportional styles.

#234

Yeah I’m of the opinion that if it isn’t automated in some way, it’ll never be kept up to date.

#235

I’ve been experimenting with this. What I know is that I’ve been able to blast reads on the Teletype’s metro script as fast as I can get it to go without problems for hours.

I set up a somewhat punishing script to test reads on triggers. I set up my TXo to generate 4 independent triggers at M 75 (not running off the Telex’s clock) and also set them to clock divide so that 1 triggered on every pulse, 2 on every other, and so on.

Here is a version of the patch:

L 1 4 : TO.TR.M I 75
L 1 4 : TO.TR.TIME I 25
L 1 4 : TO.TR.PULSE.DIV I I
L 1 4 : TO.TR.M.ACT I 1

I

CV 1 TI.PARAM 1

1

CV 2 TI.PARAM 2

1

CV 3 TI.PARAM 3

1

CV 4 TI.PARAM 4

1

Here it is in action reading:

On 1.4.1 this thing has run for an hour. I’ve slowly been speeding up the metronomes.

  • Rock solid for an hour at M 75
  • Still solid at M 50
  • Stable at M 40 - a few visual screen artifacts.
  • At M 30 the keyboard stopped reading - but the CVs still update on knob fiddling.

I’m in the process of making changes to the 2.0 branch for TELEX aliases. I’ll most likely be able to run a similar test on 2.0 by tomorrow morning.

The docs look pretty good. It will be a serious accomplishment to have documentation that is automatically generated and in-sync with each firmware release. It will be a small price to pay to have it less “on brand” in order to keep it up to date and consistently organized, in my opinion. Kudos again, @sam, for all of the effort on this.

1 Like
#236

I’ve just been writing up the docs for O… I’m not sure the way it works is entire intuitive, particularly the wrapping behaviour. This is what I’ve got (examples based on real life).

Auto-increments by O.INC after each access. The initial value is 0. The lower and upper bounds can be set by O.MIN (default 0) and O.MAX (default 63). O.WRAP controls if the value wraps when it reaches a bound (default is 1).

Example:

O           => 0
O           => 1
X O
X           => 2
O.INC 2
O           => 3 (O increments after it's accessed)
O           => 5
O.INC -2
O 2
O           => 2
O           => 0
O           => 63
O           => 61

I don’t think I’ve got time to change it, but just putting this out there if someone else does.

#237

I’m wondering if part of the issue is that metronomes are run via the event queue now, and if there are lots of events generated with slow running scripts (i.e. bi-directional i2c), that too many critical events are dropped (e.g. keyboard input, screen redraw).

If you get a chance to run the test with the serial port connected, let me know you see any event dropped messages.

#238

Ok i just tried the same things on 1.4.1 using the metro script and i encountered no problem at all. So you might be on the right track :wink:

@bpcmusic

I need to go back to what i said earlier, using TI.PARAM in M result in freeze too in certain circonstances. Here is the si;ple thing i tried on 1.4.1:

M 100
M.ACT 1
SCRIPT 1 is empty but triggered by an external clock

M

TI.PARAM 4

If SCRIPT 1 isn’t triggered i encounter 0 TT crashes :confused:

Oh and sometimes navigating from a page to another makes the module crashes (with the above scripts)

I hope you guys will find a solution to that problem because TI is kind of unusable as it is. :sob:

ps: By the way I got a TI, TO andJust Friend linked to the TT

#239

My cursory search didn’t turn anything up, hopefully this isn’t a duplicate issue:

On 2.0b8, executing “TO.TR.PULSE.DIV” in live mode with incomplete args crashes the device. For instance:

TO.TR.PULSE.DIV
TO.TR.PULSE.DIV 1
TO.TR.PULSE.DIV X

All of these freeze Teletype.

EDIT: The only device on the ii bus is a TXo, nothing else.

1 Like
#240

Hmmmm, I think that might be because the name of the op is too long for the error message to cope with it!

(i.e. a buffer overflow)

Nice spot @Pampalini

1 Like
#241

@sam - added some aliases and init ops to the 2.0 branch for the TELEX.

New Commands:

TO.TR.INIT n      = Initialize TR n
TO.CV.INIT n      = Initialize CV n
TO.INIT x         = Initialize all outputs for unit x
TI.PARAM.INIT n   = Initialize PARAM n
TI.IN.INIT n      = Initialize IN n
TI.INIT x         = Initialize all inputs for unit x

New Aliases:

TO.TR.P           = TO.TR.PULSE
TO.TR.P.DIV       = TO.TR.PULSE.DIV
TI.PRM            = TI.PARAM
TI.PRM.QT         = TI.PARAM.QT
TI.PRM.N          = TI.PARAM.N
TI.PRM.SCALE      = TI.PARAM.SCALE
TI.PRM.MAP        = TI.PARAM.MAP
TI.PRM.INIT       = TI.PARAM.INIT

Note: No new TELEX firmware is needed for these additions.

Looks like Travis barfed due to configuration errors. Hope my ignorance didn’t do that.

I’ll be happy to fill out all of the TELEX documentation when you are ready with that branch.

Thanks again, @sam. Working on this latest code is an absolute dream. :slight_smile:

2 Likes
Telex: Teletype expanders
#242

I had some time this morning to try the exact same patch as described previously (with 1.4.1):

Pluging a cable from TO in one of the TT’s input makes it crash (near from instantly) however TO is still operational it seems as TO.TR.M won’t stop blinking after TT entered its “freeze” state.

By the way, my TT is linked like this: TT => TI => TO => JF (i don’t know if that info can help though)

1 Like
#243

@martinmestres - I’ll reach out independently. I have a feeling you need an iiBackpack with that configuration. It is rock-stable for me at down to M 50 in my road case with 1 x TXo and 1 x TXi. I have found in the past that read instability is directly affected by the quality of the bus - a factor that the iiBusboard helps with immensely.

It is hard to calculate where the tipping point is for the number of devices. It has seemed like “around four” to me in the past, but clearly has a lot to do with what devices are connected and the cabling involved. Might be safer to say “around three” if this proves to be your challenge.

That isn’t to postulate that there isn’t a natural limit to the amount of reads per second that your can do over the i2c bus. I think @sam’s comment above is right on target with what I observed:

As you observed, @martinmestres, the TXo will continue to run the TO.TR.M metronomes as they are independent of the Teletype once initiated. However, in my tests, I also noticed that the Teletype continued to update its CV values even after the keyboard became unresponsive. I’d never seen this behavior before in my overload testing.

In the past, the TT would just freeze and do nothing when it was overloaded. Now, it seems to still be able to run scripts - even when the keyboard is unresponsive. I’ll play with this again and see if unplugging the trigger cables restores the UI’s function.

Alas, I don’t have a working configuration with a serial cable. I purchased one - but a) am not sure where it is right now with all of these boxes and shipping labels everywhere and b) I hadn’t figured out how to use it with the TT on my mac. I wish I could be of more help here.

#244

I think this is a misconception as four (ES, MP, two Ansibles) never worked for me without the powered i2c bus board. I had issues with the trilogy too before Ansible began. Now i2c works better with 2.0 but the price seems to be teletype getting a bit unstable as a whole atm.

Unfortunately I cannot test TXo and TXi by now cause they are still in pieces.