#124

Hah. Good guess by me then!

Let me know if it happens again, I think the issue was that the debounce algorithm is not super sophisticated. Param can jump between 2 values it the knob is just so (I have just seen this with my own eyes!) and the ADC is picking up a bit of noise.

#125

Just an FYI, that script uses the variables A-D, those variables are not reset to 1-4 when a scene changes. At a minimum the I script should reset them back to 1-4. But better would be to use the numbers 1-4 instead (I believe newer teletypes have switched to labelling the triggers 1-4 on the front panel.)

On my list of “nice ops to implement if I get the time” is an INIT.VARS op to reset all the variables back to their power on state.

Anyway, it sounds like there is an issue with the scene rather than an issue with the beta, from what I recall @tehn told me they were transcribed by hand. If you still think there is an issue with the beta, one of us is going to need to deconstruct that scene and try and concoct a minimised version (like we did with the i2c).

#126

The corrected scene is running but on the tracker page I see artefacts of position markers not disappearing when the next position is reached - so that you have moments with to position markers in one column. Or sometimes no position marker.

#127

i concur with the changes and the use of -fno-common

the redeclaration of tcTicks and tcOverflow is erroneous. i see it in the aleph codebase. guessing some kind of leftover kludge from a profiling session or attempt to add CPU usage reporting to bees.

1 Like
#128

@sam - did you have a chance to try adding protection to ticksRemain overflow? been thinking more about whether there is an issue with timers becoming corrupted, and one thing that caught my attention was the fact that timer interrupts are not disabled when process_timers is called.

this can lead to it being called while it’s already executing, if one of the timer callbacks takes too long. if this happens after ticksRemain was decremented but before it gets reset to ticks it will overflow.

@tehn @zebra - is there a reason timer interrupts are not disabled in process_timers? or is it not needed in the interrupt handler?

either way checking against overflow wouldn’t hurt i think…

1 Like
#129

process_timers is called from here:

AFAIK, timers are implicitly masked when the interrupt is called.

I haven’t done the ticksRemain experiment yet, though I’ve written some code to print over serial if it happens.

One thing that did happen was using timer_remove to remove all the timers caused issues. My guess is that there is an edge case with removing the last timer, probably something to do with the linked list algorithm. It’s a bit hard to debug without a JTAG or similar though. For now I’m just using timers_clear.

1 Like
#130

doing further reading seems to confirm this as well.

the edge case you describe is not possible though, is it? there are always at least those timers that check the knob value etc.

1 Like
#131

I’ve had to remove all the timers while USB memory stick writing is taking place, otherwise the event queue overflows almost immediately.

The trigger interrupts should also be disabled, but I haven’t got there yet.

#132

ah i see. might be easier (and potentially useful for some future applications) to add a global flag that would make process_timers do nothing when enabled? or add it to event_post so it wouldn’t accept new events when enabled. would be also good to support different priority levels here so you could still process certain events, for screen refresh, for instance.

1 Like
#133

Yeah, interrupts are disabled in ISRs by default.

I remember an edge case bug in timer list that got fixed for aleph a while back

2 Likes
#134

Ta. I’ll have a look and see what differences I can find.

Found this from here, will copy and use that instead of removing and adding the timers.

void pause_timers (void) {
  cpu_irq_disable_level(APP_TC_IRQ_PRIORITY);
}

void start_timers (void) {
  cpu_irq_enable_level(APP_TC_IRQ_PRIORITY);
}
#135

Yeah, exactly in aleph we put application timers on their own priority level for just this reason

1 Like
#136

It does not support Trilogy Meadowphysics remote by now, does it? At least I cannot get it to respond.

1 Like
#137

Are you sure you’re using the Trilogy commands and not the Ansible ones?

Ansilbe commands are:

  • MP.PRE
  • MP.RES
  • MP.OFF
  • MP.SCALE
  • MP.PERIOD

Medowphysics are:

  • MP.PRESET
  • MP.RESET
  • MP.SYNC
  • MP.MUTE
  • MP.UNMUTE
  • MP.FREEZE
  • MP.UNFREEZE
  • MP.STOP
#138

Yes, I am using L 1 8: MP.FREEZE I

The other commands do not work either here, so they should?

Of course the cable could have gone loose inside the case but checking this is very tedious - I am happy that I eventually got them all in with the interconnections. So it would be great if someone else could try it first…

1 Like
#139

I got another weird one. I was using the script I posted at > teletype : code exchange for about an hour without issue.

I switched scenes to 4Track, and TR.PULSE was broken. When I switched scenes, all four TR outputs stayed lit. I had to manually do TR.TOG to turn them off. However, upon receiving a PULSE, the TR stayed lit and would not turn off on its own without another TR.TOG.

I checked TR.TIME for all four outputs in Live mode, and they were all set to 100.

1 Like
#140

My MP is in my main case, and I won’t be able to remove it till the weekend. If anyone else that’s running the 2.0 beta wanted to test that would be great. One thing you could do @Leverkusen is try downgrading to 1.4.0 and see if it works with that?

@trickyflemming hopefully that’s something straightforward. Sounds like the pulse countdowns are getting confused on scene change.

Bug reporters… first of all thanks for the reports. If you want to make my life a bit easier, can you try and always upload and attach the scene text whenever you report a new bug. Even if you think it’s online already, please download it from your teletype again.

Also…

  1. Please report the full firmware version as reported in the front screen when you power up.
  2. Check bugs twice, including a power cycle between them (it’s okay to still report it if you think there is a bug, but you cant easily recreate it).
  3. If you have a bit of extra time, can you try and make the smallest example of the bug possible.
  4. If you really have some extra time. Can you try firmware 1.4 and see if that has the same bug too.
1 Like
#141

I downgraded to 1.4 and MP commands worked, then reinstalled 2.0 beta 5 (wich is actually called beta 4 in the OP) and it still works now. A bit strange since I tried it quite a lot yesterday but also good.

1 Like
#142

Okay, best to be on the watch to see if it happens again. Bugs like that are the worst to fix…

And I’ve sorted the first post out.

Next beta looks like it will be out over the coming May Day weekend. We’ve got the builders in at the moment, which is always far more disruptive than you imagine…

1 Like
#143

At the moment, the code remembers if you’re in live mode or in pattern mode and saves that to flash so that when you power up again it comes up in the same mode.

Does anyone find that particularly useful? Would anyone be sad if I removed it?