#186

Thanks for the confirmation - I ordered the v1 of the v2 busboard and will try it out.

:+1:

1 Like
#187

I tried the new bus board with the pull pup resistors but it does not solve the issues I have.

Instead teletype does weird things now as hanging outputs (not the ones connected to i2c but its own CV and trigger outs) and display errors.

I am not sure which firmware I should use now with the bus board. Official is 1.4.0 but there seem to be different 1.4.1 versions around.

Can someone point me to a teletype firmware that is supposed to be the one that works with the new bus board?

#188

the bus board is certainly not causing new issues. it’s likely just revealing other issues now that the i2c is working on the electrical level.

i’m sidetracked with a few other priorities before i’ll be able to check back into the state of TT.

1 Like
#189

(continuing the discussion from [another thread][thread])

[thread]: Ii bus board, v2, with pullups)

Looks like we’ve got another i2c bug that needs fixing, as discovered by @trickyflemming, I think @Leverkusen has also confirmed it too.

Minimal failing example:

Scripts 1 through 8 are empty.

#I
M 50
M.ACT 1

#M
TO.TR.PULSE 1

Connect a fast trigger to input 1. The M script just needs to send a packet out over i2c, so it could also talk to Ansible or a non-existent module.

I’ve posted some theories on the [other thread][thread], but let me repeat them here:

Tagging: @tehn @scanner_darkly @bpcmusic, I’m not set up for debugging i2c…

2 Likes
#190

Quick question: is it any i2c command in the M that will cause the problem? In other words, would TR.PULSE 5 also cause the problem (with no Ansible)? Accurate, @trickyflemming?

#191

@trickyflemming tried the following scenarios out for us

  1. Pulse TXo
#M
TO.TR.PULSE 1
  1. Pulse non-existant TXo
#M
TO.TR.PULSE 9
  1. Pulse Ansible
#M
TR.PULSE 5

All 3 fail with a trigger connected to input 1, and work if there is no trigger.

I don’t know if he explicitly tried a non-existent Ansible output. Or even one of the older II commands. Would be worth a quick go if someone has the time.

1 Like
#192

@tehn @sam @bpcmusic

I can confirm the minimal failing script. It runs for over 30 minutes and crashed after 1 minute twice when a trigger gets patched in.

I sometimes experience little hickups in the script when I switch from live to edit mode and back. Also are the hickups on saving scenes expected normal behaviour? Probably yes as the other modules show them too.

Cannot say anything about the regularity of the display glitches yet. Of course when I had the new bus board freshly built in I tried a lot of i2c stuff with M and triggered scripts. They are a bit harder to find though as you have to change the display view for getting them - not just start a script and wait for the crash while doing something else.

2 Likes
#193

just a quick note to say - i’ll be traveling for the next 4 weeks, so unfortunately won’t be able to help until i’m back (traveling super light, so no monome gear with me).

from the description does sound it could be a new bug…

#194

@tehn @sam @trickyflemming @Leverkusen

Ran the script for over an hour with triggers patched. Totally stable for me. Even added corresponding trigger pulses on the TT’s triggers for the script and turned on the TX’s pulse divider to make it more complicated. Solid.

Sigh. Kinda wish it would have locked up - at least things would be consistent.

I have 4 TXo, 2 TXi and 1 Ansible connected to the Teletype.

#195

Poop.

I’ll make some time to try it over the weekend.

#196

I should point out that I’m running 1.4.1. Video was at M 250 - ramped it to M 10 this morning and let it go for five minutes. Keeps on chuggin.

#197

I am carefully following all the threads devoted to these issues, as someone who has all the modules, and hopes to add the expander…

I have experienced locking up issues with ES and WW before, so much so that I sort of have given up on trying to use TT in conjunction with the trilogy. @tehn was extremely patient and generous with his help, including shipping alternate modules and even cases!!!

But, I am hoping that this all gets sorted out, and some stability is found/regained.

Something that I was frequently suspecting to be a factor, is the electrical stability/context for the monome modules in these configurations. Are you guys considering the power context for the tests? In terms of for example: is the user case maxed out, or on the edge of available power? Grounding issues and potential affects of other modules in the case?..

Anyway: am grateful you guys are going strong on this, and wishing you all the sweet taste of victory which comes with overcoming mysterious problems!

4 Likes
#198

Hm, firstly I am very thankful for your contribution! While I feel a bit irritated that these issues seem to be known and discussed in disguise to an extend that people stopped using the i2c features whereas they still got promoted and further developed in the open it is somehow relieving to see that there are actually more people experiencing this and the discussion gets more open.

I love the monome system and really hope we can figure out a solution. Since the promised land of complex remote control was the deciding reason for me to get into all this and replace all my former sequencing/clocking/CV control modules I would happily contribute all I can to the process of exploration and debugging to eventually get the ecosystem running stable and reliable. I can’t imagine playing live with it atm which is a shame cause I would love to!

Regarding the power context:

I tried teletype, ansible, earthsea, meadowphysics, switch and a grid in two different cases, one with a linear Doepfer PSU2, one with a Make Noise distro board and the external PSU they sell with their systems. None of both have been stable with i2c and I got lockups and periodical earthsea slowdowns. I even took out all other modules form both cases with no success. I don’t know much about general electricity contexts but I’ve read it is pretty stable in germany - as you might think everything is statutorily regulated over here. For convenience and safety I run everything in my studio from a furman PS-8RII power sequencer.

The current system is extended with a second ansible/arc and sits in the case with the doepfer psu2 now together with Maths, Optomix, Twiggy and a Verbos line (CO, HO, ATC, multi-envelope). It is fully analogue besides the monome modules and uses about 890 mA max of 1200 mA. I have had two digital modules in that case that could not cope with switched power (which made me build the extra case with linear power) but taking them out made no noticable difference.

@bpcmusic

When I get lockups in minutes with the minimal freeze script I seem to use a faster trigger rate into teletype than on your video. But I had a slightly more complex patch (as described somewhere above) freeze after about 30 - 60 minutes that was very slow in every sense (M and trigger input) too. I assume that the probability of a crash just rises with faster rates.

If there is anything I could try over the easter days I have some time and would do it.

@tehn [quote=“tehn, post:188, topic:5861”]
the bus board is certainly not causing new issues. it’s likely just revealing other issues now that the i2c is working on the electrical level.
[/quote]

Could it be that I made a mistake building the new bus board? I would think it would not work at all then instead of being not much of a difference, right?

:rabbit:

#199

i’d not make assumptions about wider issues-- there are people using these features without issues.

have you been attempting to use the remote commands in a musical context? or have you simply been focussed on testing situations of maximal message throughput-- with the assumption that if the full-on test fails that lesser cases will also fail?

previous issues with ES sync (which laborcamp mentioned) are now fixed-- so i’m confused why you’re bringing it up-- is yours not fixed?

the new bus board puts the i2c lines within spec. it does not break anything. it eliminates a likely problem.

i’ll be able to dig back into this next week.

#200

@tehn

Yes, I mainly attempt to use remote commands in musical contexts. But it is not stable enough as it tends to freeze within 30 - 60 minutes. Seems to be related to the used clock speed but I never use unusual high speeds, even when I am just doing a test since we already came to the point in this thread that this would not make any musical sense. I promise I am not just trying to prove your system wrong!

Regarding the ES sync issues: I bring this up every now and then, then you reply that it is already fixed and I reply that it is not. It looks like this with a steady clock on teletype with actual firmware on both. The slow down is not intentional in this video and it appears periodically about every 4 minutes:

Regarding the new bus board: My point was not that it might have been wrong to build one! My point was if it could be that I did not build it properly so it would not fix the i2c issues but still kind of works as it was before with the unpowered bus board?

#201

Not my favorite question :confused: Yes, I’m trying to use it for music and not finding pathologic failure states (and that’s ignoring the deeper implications of what a “musical context” means in an open-source sequencing environment plus whether these aesthetic and computational boundaries should be defined in the documentation).

The patch that I started with is Teletype Studies #1 with an added Metro script for the TXo. The Metro speed is fast, but slower than its limit and slower than what @bpcmusic demonstrated in his tests.

The patch that we’ve whittled it down to is extremely minimal. Literally one line on a Metro script and nothing else (see @sam’s post above: Teletype Firmware i2c Debugging). It fails when a trigger is received on a blank script slot (really, any script slot, but we at least know it’s not because of an over-complicated script).

1 Like
#202

I just want to underline that my message was not to suggest any sinister dealings or hidden flaws whatsoever. I had a bumpy road, who knows why. It could have been a hundred things.
I was merely conveying my excitement and encouragement for those who are working hard to resolve these problems. For the benefit of all of us.

In terms of “not being alone” when problems emerge: definitely.
There is always something strange happening in my case, which contains many modules from many manufacturers. Sometimes I shake my head in disbelief that it all seems to more or less work together, somehow!

#203

And to that point: you are absolutely not alone.
I see that exact behavior in my system as well.

1 Like
#204

ha, yes i see the ambiguity in the question, apologies. my main interest, which was answered, was about the threshold of failure.

we’re dealing with what should be considered a pretty small processor (66mhz). it’s difficult to define the boundaries given the various ways you could possibly overrun the system. i’ve already made a sort of definition by not allowing the metro clock to go below 10ms. but there are certainly ways to bog the system. there are ways to bog any digital processing system. but unfortunately this takes time to learn-- ie, super long loops, fast metro, all 8 inputs firing scripts with extreme speed, script recursion. it’s much different than the common understanding of “too many plugins in my daw” but i think you’re correct-- we should put together some suggestions for ways to bog your TT (and hence, avoid them)

that said, the issue reported is not related to processing power, luckily. it seems like an interrupt priority issue.

@sam @bpcmusic @scanner_darkly

what do you think about scripts getting executed within the event loop? so metro and trigger inputs would simply queue a script event? it would quantize script execution to a 1ms clock (which i don’t see as a problem), but would certainly prevent any collisions (ie, a trigger firing a script while a metro script is mid-execution, which i think might be possible at this point-- not having looked at the code).

#205

It took me a bit to, hopefully, understand this right and I am very sorry if my above post came across as suspecting sinister dealings or murky affairs. I hope you can excuse that I am not a native english speaker and have to look words up quite a bit when I post something - as it seems not always with success. :hushed:
So maybe the term “in disguise” has a connotation I did not mean to imply.
What I meant was simply that the issues have been discussed on other communication channels than the open forum while I had the feeling that it is not easy to be taken seriously reporting them getting answers like ‘it is already fixed’ or if I even use it in a musical context.