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

Wasn’t sure where the best place to share this might be, but I added a few handy keybindings to Pattern mode that let you quickly enter values from the N table.

0 = 10 is kinda obvious, but I made 1 = 11 semitones because you can already do one semitone with ALT - [ ] and by making it 11, we now have the ability to transpose up or down by any value between 1 and 12 semitones via a single key command.

Here’s a little demo video:

11 Likes
#42

Sounds great! What’s the easiest way to apply your work to my local branch? I like to work with patches, I’m old school like that…

2 Likes
#43 
git remote add discohead https://github.com/discohead/teletype
git pull discohead pattern-mode-key-bindings

If you want patch files git will do this too:

git format-patch origin/master..discohead/pattern-mode-key-bindings

will output one .patch file per commit, or

git format-patch origin/master..discohead/pattern-mode-key-bindings --stdout > onefile.patch

will produce a single .patch file with them concatenated together.

1 Like