#21

Ah I see what he’s getting at. Glad to see that there’s some interest in this command. I think there’s certainly some unexplored potential with the delay command. I do want to make sure my basic idea doesn’t fail horribly before exploring more complex interactions, but please do keep the discussion going.

Here’s a list of ideas, although maybe another thread for this would be good if there’s enough interest. Please speak up if any of these are redundant to already existing commands, or if my logic is faulty.

  1. Chain delay with base time:
    Allow for a base delay time in ms, so for example a base of 1000ms and an increment of 250ms would create delays at 1000ms, 1250ms, 1500ms, etc.

  2. Looping delays:
    Basically a periodic task the delay recreates itself each time it’s executed, so for example specifying a delay loop of 500ms would periodically execute the post command every 500ms. I think this might be doable already with existing commands, but this would probably be easier to manage as it’s own command.

#22

At some point you might ask a mod to change the thread title, but I don’t think you need a new thread.

Your “chain delay with base time” idea is cool; it could be simulated with a delayed call of another script containing a chain delay.

The “looping delay” function is basically just the existing METRO script function. By design, TT only has one M script and I’d argue that it should remain that way. There are some clever methods around this by using delayed self-referential script calls (with initial calls from I). Keep in mind that M has a lot of helpful functions already, e.g. start/stop, a dedicated period variable, keyboard shortcuts, etc. Not to say that you shouldn’t tinker with this! Could lead to other useful discoveries.

If I had one minor suggestion at this point, DEL.CHN x y: ... is a pretty long PRE command. Maybe consider something like XDEL x y: ...?

#23

Good points on the M metro script I’ll put that idea on the back burner for now.

I was planning on coming up with a better name XDEL is perfect!

#24

sorry for being unspecific. what I meant was, if you execute something like
Z 100; DEL.CHN Z 10: ADD X
will the value of Z be copied in? or is it possible to modify Z and thus change the delay time mid-term?

just to be clear: I wasn’t requesting anything, just genuinely curious. my C is rather limited, let alone my non-existent knowledge of the TT code base. awesome that you’re exploring it!

it seems I need to consider my words better as a non-native english speaker, pretty baffled it was interpreted that way. sorry for that.

#25

Z would be passed by value, so no it would not be possible to change the delay time mid-term. Interesting thought though.

#26

thanks for clarifying!

if you someday feel like sharing the OP, would love to give it a go.
(no pressure from me please!! :hear_no_evil: ahh I’m worried to say anything now. please ignore me)

#27

Sorry!

I didn’t mean to scare anyone. I was just concerned that there would be a lot of discussion about potential DEL OPs before @alphacactus had even got his test code running.

2 Likes
#28

Just finished and compiled the code. Upload was successful, and the command appears to be functioning properly. Command format is as follows:

XDEL x y: ...

Currently have x as delay time and y as the number of delays to queue. Unsure if there was already functionality for clock multiplication(please share if so), but this does the trick:

XDEL DIV M 4 4: TR.P 1

Trigger 1 is pulsed 4 times at spaced intervals for each execution of the Metronome script. It is of course limited by the size of the delay queue.

3 Likes
#29

Quick question re: Teletype firmware dev: how do you do performance testing? I’ve made a minor adjustment to keyboard polling to the current build for myself (Mechanical keyboard for teletype?) and I am curious how one would test the performance impact of a change like this.

#30

@sliderule added profiling, to use it you need to add a define for TELETYPE_PROFILE in main.c (the value doesn’t matter). it uses printf to print the results though, so this will require soldering the FTDI header on the back.

alternatively you could probably hack something and have it output some info on the live screen or something like that.

1 Like
#31

i think it’s fine when they are simply passed into some other function, if there is some other logic in there i try to give them more descriptive names (and this way you don’t have to add a comment explaining what the variable means)

#32

on the topic of additional temp variables. similar to scene state, would a base+offset access for temp variables be desired for execute states?

#33

not sure what you’re referring to?

#34

scene state variables(global variables) are created and accessed using their offset from the scene state base address calculated with the offsetof macro from stddef.h.

I simply uses arrow access.

#35

not familiar with that part of code, i’ll have to check what’s the purpose of it. i think it’s related to this?

which only applies to global vars.

#36

ya I’ve never seen anything like it before which is why I inquired. not sure if it’s because the scene state struct has so many members, or just because there’s more than one simple variable unlike execute state. I suppose it saves code space too.

#37

i think it’s just to avoid having to create separate functions for each variable

1 Like
#38

Yep. It’s just cheating to save lots and lots of (error prone) typing. It also keeps the code size down.

edit:

Just in-case, the warning is about something else. @sliderule put it in, it might be about how the live variable display works.

2 Likes
#39

cool really good to know. I guess the question stands though, would this be desired for additional temporary variables in the execute state?

#40

regarding the idea of sine cv out. if my understanding of how CV.SLEW functions is correct, then instead of adding a delta on each step in the cvTimer_callback, you could instead call the sine LUT function.

potential hurdles to overcome with this approach:

  • convert the step into an angle to pass into fix16_sin_parabola
  • convert the return value of fix16_sin_parabola into a voltage
1 Like