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

#29

Hi @Greg, I agree that the system should not lock up ever. It’s never going to work at audio rate, but it should never completely lock up. Especially if all you need do is accidental run your LFO too fast.

I’ve yanked a Dr Octature out of my main case to bring over to my development mini case and have been able to recreate some of the effects you’ve been seeing.

I’m wondering if you’d consider trying a few things out to help me make sure what you’re seeing is what I’m seeing?

Could you try the script here on 2.0b8 again. When the Teletype locks up, can you disconnect all the cables and check to see if that makes the keyboard and screen responsive again. If not, can you then unplug and reconnect the keyboard, and see if that helps. For now, don’t worry about the TR/CV outputs misbehaving.

#30

I just tried this with the same effect - trigger ans CV outs are still working as the scripts suggest but no keyboard control.

Removing the cables has no effect, reconnecting the cable neither. Pressing the front panel button freezes tt then totally.

#31

Yes I also seen a variety of outcomes. Sometimes disconnecting the cables fixes things, sometimes disconnecting the keyboard fixes things, sometimes it’s just borked.

But I’ve got the serial port connected, and I’ve seen a few interesting things. Will investigate…

#32

I did a more elaborate trial and could not replicate this behaviour. I measured the trigger output A (with Logic’s param EQ Analyzer spectogram :wink:) and it worked up to frequency beneath 2k. I cranked it up to ultrasonic then and lost the keyboard but got it again when I went down into the normal audio range.

The script more or less worked over the whole audio range. The screen got very glitchy and I got audio pops when I typed the keyboard to see if it still there but there was an almost steady tone.

Also it did not really work with a sine wave as mentioned above, sounded crappy and did not give constant trigger LED flashing. But pulse was great untill deep into the audio range. I’ll try some wavetables now…:slight_smile:

#33

@Leverkusen and @Greg

Could you try running this firmware for me please? It’s basically 2.0b8 with a slight tweak to the event code. Please give it all the grief you can.

(deleted)

(and @Leverkusen thanks once again for all the testing and feedback you give :heart:)

edit, please try this version instead: teletype.zip (179.3 KB)

They’re basically the same, but this is closer to the actual change I would make.

Testing notes: instead of unplugging cables, try slowing your trigger input down

1 Like
Teletype 2.0 beta (release candidate 2 released 13th July 2017)
Teletype 2.0 beta (release candidate 2 released 13th July 2017)
#34

This is as much grief as I can give right now (actually it hurts a bit to to watch this):

1:
X MOD ADD X Y 60
CV 1 N X

2:
Y P.NEXT

Plus an eight step pattern and a 1000Hz pulse wave going into trigger input 1:
CV 1 goes to a LPG then…no oscillator used apart from teletype…:smiling_imp:

When I crank the oscillator up I loose keyboard control, the screen gets messy or tt freezes - everything is back when the oscillator is turned down again.

:grinning:

3 Likes
#35

My teletype is freezing up with the latest beta as well.

I have a simple ‘tuning’ patch.

M:
L 1 4: TR.PULSE I
I:
M 200
L 1 4: CV I N 12

keyboard and screen still work, but the all the jacks freeze up after about 30 minutes…

#36

Brill, this is also what I’ve seen with the tweaked firmware.

You could always try the zip file posted above. In theory the bug that’s been causing the audio rate issues is probably affecting a lot of other things too. I’m trying to think it through a bit more, but basically every time ‘something’ happens there is a tiny chance that part of the Teletype get’s corrupted. When running the triggers at audio rate that will manifest itself much much sooner. But it may also explain why there are issues with longer running scripts too.

I need to start winding down for bed time now. Tomorrow I’ll completely hijack this thread and call together a conclave of the coders to discuss the tiny change I need to make to libavr32. If anyone else would like to try the firmware in this post and report back that would be incredibly helpful.

5 Likes
#37

CONCLAVE OF CODERS.

That sounds really geeky, but also really mysterious and cool.

2 Likes
#38

Conclave Assemble!

@tehn @zebra @scanner_darkly @ngwese @bpcmusic

A bit of background. If you run audio rate triggers above a certain frequency into the Teletype, it becomes unresponsive and may crash. If it doesn’t crash and you back off the rate, one of the following will happen:

  • everything goes back to normal
  • back to normal, but the keyboard needs an unplug and reconnect to start working again
  • back to normal, but the CV and triggers get stuck

The last 2 issues are ones that seem to crop up repeatedly and even on other modules (e.g. needing to replug the grid on Ansible).

If I change all the IRQ masking in event.c to mask SYS_IRQ_PRIORITY rather than APP_TC_IRQ_PRIORITY, suddenly all the audio rate crashes go away. The system is still unresponsive with audio rate triggers, but as soon as they slow down everything is fine again. No stuck CV or triggers, no issues with the keyboard.

My strong suspicion is that there is some code somewhere that is calling into the event code at SYS_IRQ_PRIORITY, thus bypassing the current mask (I’ve tried looking…). But that the likelihood of it happening simultaneously with another call is very low. This is why the issue manifests itself reliably with audio rate triggers (high event density), and also why we see it when modules have been powered up for a long time.

I propose that we increase the IRQ masking to SYS_IRQ_PRIORITY, while it would be nice to get to the bottom of it, I haven’t the time (or the JTAG) to do it. And even if we did find the offending piece of code, there is an argument to be made that the event handling code is of such critical importance to the well being of the system that it should be masked at the highest level anyway.

However this change is in libavr32 and so will affect all the modules (possibly fixing some bugs in them too!). So before I make the change, I wouldn’t mind some of your collective time to think if there is anything I’ve missed or if I’m being daft in some way.

The diff is as follows:

diff --git a/src/events.c b/src/events.c
index 34bff5a..b5df442 100644
--- a/src/events.c
+++ b/src/events.c
@@ -52,7 +52,7 @@
 // Returns non-zero if an event was available
 u8 event_next( event_t *e ) {
   u8 status;
-  cpu_irq_disable_level(APP_TC_IRQ_PRIORITY);
+  cpu_irq_disable_level(SYS_IRQ_PRIORITY);

   // if pointers are equal, the queue is empty... don't allow idx's to wrap!
   if ( getIdx != putIdx ) {
@@ -66,7 +66,7 @@ u8 event_next( event_t *e ) {
     status = false;
   }

-  cpu_irq_enable_level(APP_TC_IRQ_PRIORITY);
+  cpu_irq_enable_level(SYS_IRQ_PRIORITY);
   return status;
 }

@@ -79,7 +79,7 @@ u8 event_post( event_t *e ) {
    // print_dbg("\r\n posting event, type: ");
    // print_dbg_ulong(e->type);

-  cpu_irq_disable_level(APP_TC_IRQ_PRIORITY);
+  cpu_irq_disable_level(SYS_IRQ_PRIORITY);

   // increment write idx, posbily wrapping
   saveIndex = putIdx;
@@ -93,7 +93,7 @@ u8 event_post( event_t *e ) {
     putIdx = saveIndex;
   }

-  cpu_irq_enable_level(APP_TC_IRQ_PRIORITY);
+  cpu_irq_enable_level(SYS_IRQ_PRIORITY);

   if (!status)
     print_dbg("\r\n event queue full!");

Well the minutiae of interrupts are indeed mysterious, but oh-so very not cool.

3 Likes
#39

how strange…

as far as i can tell, SYS_IRQ_PRIORITY is only used for the PDCA transfer interrupt on aleph. it’s important that this be uninterrupted by event processing. but we can work around that in a different way if/when we really get around to merging the codebases (sorry.)

My strong suspicion is that there is some code somewhere that is calling into the event code at SYS_IRQ_PRIORITY

that would make sense. but i have also failed to spot anything in teletype or libavr32 code (including asf.) neither a usage of SYS_IRQ_PRIORITY, nor anything ridiculous like INTC_register_interrupt(foo, foo, 1). there are some drivers that set their own interrupts, notably USB host. this uses UHD_USB_INT_LEVEL. i guess thats where i would continue looking.

anyways… yeah i don’t see a problem with that for trilogy/TT/ansible. but we really should know what is causing this.

#40

My gut reaction was that it is in the USB code, but it’s not based on any hard evidence. Just some odd interactions between pressing keys and the “event queue full” message displayed over serial.

Yeah we should. I just haven’t got the time at the moment.

I’ll cut a new Teletype 2.0 beta tomorrow or Wednesday with the change in it, in the hopes that more people test the code. (So that I can be sure it really does fix the issues we’ve seen.)

2 Likes