#413

For goofs:

- y << >> y 1 1
! + 1 >> << y 15 15
3 Likes
#414

I’m running a sefl build firmware, pulled from git on 2019-12-03. I noticed that the label “2” of script 2 is greyed out (like when it’s muted) although it’s not muted.

Visual glitch, would be nice to have fixed, hoping there’s not something deeper going wrong…

#415

I can’t reproduce this with the current source from master. A patch was merged on December 7th to address some array bounds checking that was not causing any problems in release firmware, but could cause an issue if you have modified the scene_variables_t struct without this bounds check – discussed up-thread here.

Can you pull and see if the issue persists? If so I’d need to see a diff of any changes between your build and upstream (just pushing your fork to GitHub is fine), or if you have not modified the code then some steps to reproduce: is the issue present immediately after flashing the firmware? Or after some other action? Do you get a mute indicator for script 2 when in LIVE mode?

#416

The code is unmodified. But I’ll try with a clean clone and report back. Thanks!

#417

What about something like:

AD a b
ADSR a b c d

AD 10 500 (Attack/Decay with 10ms attack and 500ms decay time)
ADSR 10 25 1000 25 (Attack Decay Sustain Release, where each digit establishes the duration of the corresponding envelope segment)

:innocent:

5 Likes
#418

Maybe CV.AD / CV.ADSR?

And:

CV.LFO a b c

cycle time in ms, min CV value, max CV value

And to get into fancier territory:

CV.EOC a where a = script# – called at end of envelope or LFO cycles.

7 Likes
#419

Perhaps the dearth of TXos has us wishing its capabilities upon Teletype :laughing:

3 Likes
#420

God, I would love a simple LFO command and ADSR command. Do you have a go to method currently for creating an LFO? I haven’t had the time to sit down and really bang out a good, regularly usable method (I just got my teletype right when responsibilities got SUPER intense).

Is it easiest to use the ELSEIF command?

1 Like
#421

The simplest AD envelope is probably to set, for instance, CV.SLEW 1 500 and then do in script 1:

CV 1 V 5
DEL 500: CV 1 V 0

To loop the envelope you can add DEL 1000: SCRIPT 1 so that the script is re-triggered when it reaches its end (or TR.P 1 and self-patch trigger output 1 to input 1 instead of calling the script directly - you can do lots of more complex things by involving another module like Maths as a delay line for triggers).

I imagine this is probably the easiest way to implement something like CV.AD or CV.ADSR, is for these to be convenience ops that use up some of your 8 delay slots. Dunno if that sounds sufficiently agreeable.

3 Likes
#422

These seem like reasonable answers to the query. With the potential of some more TXi and TXo’s coming to market soon enough, it would be great to have a simple script op to create and edit LFO and movement. Then being able to stack a few under a script that cycle on their own or repeat on their own would be great.

I guess maybe they could be put in the stack?

There could also be a potential for a shadow script that is run regularly to have something along the lines of elseif ops that can send the LFO up or down depending on the value compared to the desired height. I don’t know how creating teletype functions and operators work from a development perspective, but if they need to go SOMEWHERE, similar to the DEL.R or DEL.X, maybe they could be stacked in the delay area.

1 Like
#423

Yeah, probably a simpler way to get an LFO is

CV 1 V * 5 FLIP

in your metro script. Recompute target values here however you like (possibly depending on reading the current value of CV 1) and adjust your metro timing and CV.SLEW to taste.

Having more “background” stuff competing for event loop time seems a bit risky I guess, may be possible, may start to cause timing issues or other quirks, and raises some implementation questions I don’t have immediate answers for. Existing TXo ops or eventual ops for calling to Crow scripts seem like a good solution for autonomous CV looping outside the parameters of what’s already possible with scripting and CV.SLEW.

Scripting an ADSR that reacts to a gate seems like a fun exercise now that scripts can react to both rising and falling edges by setting $.POL.

5 Likes
#424

Wait, what ?
I need to read the doc again, I didn’t think that feature existed (nice surprise)…

2 Likes
#425

Ok, I’m not able to reproduce the problem with the old firmware. Pulled a fresh copy from git and updated my patch for 12 scripts to work with current diff (2019-12-20).

I’m running the 12-scripts firmware for now, to test for stability.

Questions:

  1. My patched firmware shows as “DIRTY” when booing the teletype. How do I (cleanly) remove the DIRTY-part, preferably with a unique ID (is that a checksum?)?
  2. Is there a way to display the current CPU-usage of the teletype? It would be nice to know if I’m near the limit, both with hacked and original firmware…
#426

It is a Git commit hash, so a unique ID indicating a specific point in Git history. This is useful versioning information for troubleshooting because it allows you to determine the exact version of source code that’s being used. “dirty” means that there are uncommitted changes to Git-tracked files, if you want this to go away you would have to commit your changes before compiling. I wouldn’t worry about it while developing but it can be useful to make sure this is correct before distributing firmware builds (something I am personally not great about remembering to do).

Hm, no, but the CPU usage is probably basically constant – Teletype works by busy-waiting for events to process from an event queue. Events generally get posted by interrupts: if events take a long time to process, new events will have to wait their turn; if this happens often enough then the queue might get full and events start getting dropped.

If you are just adding new scripts this by itself does not probably have much event timing impact, but if you have 12 scripts filled to the brim instead of 8 that’s potentially more events getting posted. A first concern is probably running out of device memory, which gets reported whenever you compile with this sorta thing:

   text    data     bss     dec     hex filename
0x1a482  0x18a4 0x3a278  352158   55f9e ansible.elf

I believe the limit is 512KiB (hex 0x80000, dec 524288) but the build will fail if you go over.

1 Like
#427

Thanks for your reply!

OK, I see. So I should even think about putting things like “% T 16” of “P 63” into a variable and reusing that variable over making the call serveral times? I’m only asking from a CPU usage point of view here… I’m thinking there must (and also feel like) be a difference on how much computation a line is doing, especially when there’s a lot of it…

Another question: I sometimes have trouble initialising TR:TIME in I script. It seems that sometimes (when the I is busy) I doesn’t get called on load. But it gets called every time when running I “by hand” (pressing F10). Did you ever notice something like this? What is the difference between calling it by hand and it being run when the scene is loaded (in the teletype FW code, I mean)?

#428

Just as a point of reference, I’m seeing something like 4ms of cycle time for a very complex 12-script scene that handles a lot of Telex input/output ops (2 of each), a grid, and other things besides.

2 Likes
#429

That should be all right :thinking:

#430

Not sure if this is applicable to your scenario, but I recall having some issues a while back with some things not being initialized properly. My solution was to us a DEL for that particular part of the script. Something like 200ms or whatever. Just enough so other things had the chance to get going. Really don’t remember what was my specific use case: whether it had to do with TO modules or what.

And just chiming in to suggest a little delay action as a test.

#431

Thanks for the suggestion! However a lot of my Initialization contains loops, and you can’t delay a loop…

Also I figure, that since I works every time it’s run by hand, there must be some improvement possible in the code, so we don’t have to jump through hoops…

#432

If you have space: put the loops into another script, then run that, delayed from INIT.