#403

Since mine is not, it should be possible to compare sources and get a hint at what might be causing this…

#404

holy crap it’s been 2 months since that post where we got jnobles notes :dizzy_face:

I’ve tried the mod back then (rather quickly that is), failed due to said different base and never got to look into it again due to some (non-)exciting work circumstances. my tt is even still in a broken state :see_no_evil:

@a773 thanks for picking this up! do you have a fork on github?

sounds like a weird bug… buffer overflow somewhere? this coming from someone still standing on the sideline, with non-existent C experience besides some IPC hello world. but I’d love to learn from it.

1 Like
#405

Putting it out in the hope others will look at it and chime in and hopefully improve. So any feedback welcome!

I’m not gonna maintain source or hex-files, so you need to be able to compile your own firmware + apply a patch…

2 Likes
#406

Very nice thank you very much!!
Never diff’d to a file. Crazy helpful in this situation!

#407

Has there been any discussion of having arc drive teletype directly?

For example something like Cycles running which correlates the 4 triggers to tr inputs 1-4, and the 4 cv values to variables A-D…

2 Likes
#408

This gets drawn here. ss_get_mute(ss, idx) returns ss->variables.mutes[idx], but mutes only has a length of TRIGGER_INPUTS, which is 8. So for script index >= 8, this is an out of bounds array access, and will return whatever’s in nearby memory. I’m guessing this is maybe working by accident in the official firmware because struct padding means the next bytes are always 0, but this is a bug waiting to happen if more members get added to the scene_variables_t. Currently I think this has no effect, but should get fixed. (edit: PR)

From your diff, this line should keep the bounds check as s <= TT_SCRIPT_8 because script polarity only makes sense for the scripts with associated input triggers, and this potentially could also try to do an out of bound array access.

3 Likes
#409

Is there any work or thoughts on creating a method for the TT to send Crow asl info? It would be great to hijack the crow’s ability to create smooth sine LFO’s with the TT’s flexibility of live programming…

4 Likes
#410

An OP to control crow LFOs would be really awesome! It sounds like a fun project for learning about firmware hacking, but I imagine there would have to be some editing in both crow and teletype libraries? This was definitely the main reason I got a crow; hope we can make it happen soon!

1 Like
#411

If I want to know the parity (even/odd) of the value y I use % y 2 , is there any other ways to do the same?

Thanks.

#412

& y 1

or

BGET y 0

2 Likes
#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