#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.

#245

This is what I want to try as well. One of the theories I have is that under high load, that the keyboard and screen code is effectively starved of CPU time. If that is the case, then it’s not such a big deal with triggers if just unplugging the cable fixes things. But if the metro script is overloading the system, you have no way of turning it off as the keyboard isn’t working.

It’s pretty easy to use on the Mac, there are some instructions in the libavr32 readme. The biggest pain is getting the cable to your computer.

Really? If you’ve got non-i2c things that are more unstable in 2.0 that 1.4 (or 1.4.1) can you let me know please. Hopefully I can get them fixed.

1 Like
#246

I thought of the screen glitches and the latest crash reports above. What I noticed when using faste metro speed (say between 25 and 50) is that tt just skips single metro ticks every now and then.

#247

Thanks, I will try and pay more attention to the screen glitches. I’ve not given it a lot of attention as though they might look bad, they’re not normally anything to worry about (unless the system is under high load). The Teletype code only redraws parts of the screen when it thinks something has changed, a lot of that has been rewritten and so there maybe cases where that calculation is off.

The dropped metros at < 50ms is a change introduced in 2.0, and it’s a good one in my opinion. Basically there is an ‘event queue’ on the Teletype, if you fill it up too fast it will start dropping things added to it to keep the system stable.

One small tip, the screen drawing code in pattern mode is really not very efficient and can often redraw the screen even when nothing changes. Try keeping the screen on live mode to gain a bit of extra CPU.

#248

Ok guys, just unplugged the Just Friend and ran some tests with my TI and everything works as expected (with only 1 TI and 1 TO linked to the TT). So that configuration may need an iiBusboard or iiBackpack :slight_smile:

1 Like
#249

@martinmestres - great to hear. I’m officially changing my tune to “three or more devices” for requiring powered bus boards.

@sam - I’ve been running my nutso test on 2.0 and it is rock solid down to an external trigger rate of M 11. This is polling the external params a hell of a lot due to the clock-divided triggers coming from the TXo to the first four trigger inputs to trigger reads of the four TXi pots.

On 2.0, even if I exceed the trigger rate (<=10ms), the UI is still completely responsive. The only thing is that the CV writes of the potentiometer values stop happening. I could still use the Teletype and modify my script to reduce the read rate.

To be fair, I saw a little gunk left around once on a screen refresh, but it was hardly problematic. I wasn’t able to cause it to happen again. This feels acceptable in such an extreme situation.

In my opinion, this is damn impressive. With two or fewer i2c devices or more with one of the powered bus board options, the Teletype is able to poll these external inputs at a blazingly fast rate. When exceeded, the TT is still stable and can be interacted with.

Given the processor in the TT and the i2c bus rate that it operates at, it feels almost miraculous. (A serious credit to all of the i2c work that has gone into the platform lately.)

For those wanting to push the envelope here, just know that there is a limit to the amounts of reads that you can do per second. This is the case for all microprocessor systems, it is usually hidden from you due to value caching and parameter smoothing. You can do the same in your Teletype scripts. (For example: read external values at a fixed rate using M and put them into variables that your scripts can use, turn on a tiny slew on a corresponding CV out to smooth out the steps, …)

#251

I looked this up today, in 1ms, you can send 12.8 bytes over i2c. Once you factor overheads and round trip time (esp. w/TXi), that really doesn’t leave much time on 25ms clock or trigger.

I’ve posted a tweaked firmware on this thread…

…as far as I can tell it’s pretty bomb proof with audio rate inputs into the triggers. The Teletype stops being responsive and the scripts don’t necessarily work as expected. But as soon as you back off into LFO rates, everything starts behaving again. (And I’ve tested sending i2c to Ansible under those conditions too.)

2 Likes
#252

AFAIK the Just Type stuff is the same as it was in earlier firmware versions. All the existing OPs are still there.

If you didn’t know, the code required in the Teletype codebase to make Just Type work is trivial and doesn’t do much apart from send messages to Just Friends do things. All the big things happen on the Just Friends.

1 Like
#254

Hi @sam, i was out this wknd, so late reply.

Re: doc formatting. Echoing @Leverkusen, I think the tables in the pdf aren’t the most stunning visually, but they seem fully functional.

I’m unsure of the formatting abilities of Pandoc, but it feels (as you mentioned in another comment) that left aligned tables might be a simple fix for the pdf. Additionally, I’d be curious about additional thinner horizontal lines between rows. I think this is part of what is making html tables a bit more quickly legible (for me)

All of this said, it seems more about getting a doc together which holds all of this info, and both seem to be doing a good job at that. If I’m following you correctly, we could then pull the vital info into a design program to make a more easily formatted cheat sheet.

I’d still be interested in helping w/ the docs and cheat sheet

#255

You can write your own Latex template, though some of the table stuff is hard coded. It’s a job for someone that really knows their Latex (or is willing to learn), and is willing to commit to keeping it working. As far as I’m concerned, if someone volunteers to do it, then there opinion matters of above all else (so if your mission is Comic Sans everywhere, now is the time to pipe up).

I could probably do it, but there is only so much time…

Basically yes. The content is separate from the design. For now I think concentrating on getting the content sorted is most important. I’ll try and open up a thread today or tomorrow, I need to get a discussion going on the audio rate trigger issues first though.

I will admit that the way Pandoc works, by having a default that’s really easy to use, but allowing for custom templates with all the extra effort entailed, really appeals. It makes it easy for me to punt most of the design stuff. My experience is that if open up the discussion too much on design it will generate too much feedback and comment, and then there is a danger of nothing happening. I’d rather deliver something imperfect.

1 Like
#256

I agree, and I think the docs you posted last communicate all the pertinent info clearly. So unless we find that Latex guru who loves comic sans :wink:, the current incarnation seems to work nicely

1 Like
#257

I’ve fixed this now. The fix will be in beta 9.

2 Likes