Keep the comments coming…

Just to give you some insight, in general I try to keep my commits as small as possible, really you’re just watching my process in action. I don’t really have time to get in the ‘zone’ these days, so it tends to be lots of small atomic changes. That way, when I get distracted it’s easy to pick things up again. If we were being more proper I’d squash / reorder them when I finish, but I’m not sure it’s worth the effort.

1 Like

Before I sort out variables and arrays, I’d like to get the prototypes for tele_op_t.get and tele_op_t.set sorted. The intention is that those functions will not have access to any global variables, and instead access everything via the arguments passed in.

I think I’m going to go with

void (*get)(const void *data, tele_global_state_t *g, tele_exec_state_t *e, tele_command_state_t *c);

(if you’ve got alternate names for the structs shout out, I generally prefer verbose names when the scope is large)

I’ve gone with 3 different structs to illustrate the different types of states we have, and so that (via the NOTUSED macro) we can document what state an op manipulates.

  • tele_global_state_t will (eventually) contain:
  • scripts
  • timeline
  • variables & arrays
  • patterns
  • delays
  • mutes
  • the S stack
  • tele_exec_state_t is designed to hold the ‘execution context’ for a series of commands (e.g. a script):
  • IF / ELSE condition (and thus stop the status of condition leaking)
  • commands executed (see this ticket)
  • tele_command_state_t will contain:
  • the stack

It’s possible that we might want to eventual split tele_global_state_t into 2 types, that which is saved with the scene and that which is not to make scene management easier.

I’d consider merging tele_exec_state_t and tele_command_state_t if there is a strong demand, but my gut says not to.

In case it’s not obvious, I’m not actually planning on doing all of this now! Only the variables and arrays (and maybe the stack), but I’m trying to get the foundations in place to do it over time.


One more question, what is the PRESET variable for? It doesn’t appear to have any special use, other than being an undocumented variable. Can I just delete it?

1 Like

I’ve got the variables X, Y and Z converted into ops via the magic of the offsetof macro…

@tehn, are you happy for me to keep plodding along with this at my own pace? In which case I might rewrite how some of the variables work as I convert them to ops. Otherwise, I can leave that for later and get a PR in sooner.

3 Likes

sorry to interject but what does this mean?

Do you mean as a user? Or for code hackers?

this might not be implemented? when written, the given preset is loaded. when read, it returns the current preset


all looks good so far! i’d say continue on!

1 Like

It is, it’s just called SCENE isn’t it?

I’ll delete PRESET, I’m guessing it’s a bit of confusion regarding user and coding nomenclature. Speaking of which, I might rename some of the MOD stuff in the code to PRE.

ack. correct. i’m confusing myself as well.

1 Like

primarily as a user

sorry i shouldve clarified that…i could follow sone of the other changes happening but this seems different

There shouldn’t be any difference at all. The only potential change might be if some bug was fixed that you’d been (accidentally) relying on.

It’s really a technical change to (hopefully) make the code simpler. At the moment internally the teletype has variables, arrays, ops, keys and mods (aka pre). The plan is to just replace all of them with ops and mods. Basically the ops are gaining the ability to optionally behave like variables.

ok cool

the implications of this are huge, right? shouldn’t that allow new functions along with backwards compatibility current scenes?

1 Like

I think it’s more that it will be a lot easier to implement new functionality. I’ve got some ideas for things like a STOP op (i.e. stop the current script), we could even have a GOTO op!

2 Likes

haha, but but I’ve been told to ignore GOTO forever! :yum:

sorry, we really shouldn’t be interrupting you …

1 Like

If you look in the V2 thread at how the timeline stuff will look, it really will be getting close to

10 PRINT "HELLO"
20 GOTO 10
1 Like

Right then… no more arrays and no more variables!

I’ve tested it on hardware a little bit (my modular is transitioning to a new case, hence me having lots of time to work on code). All seems good, wouldn’t mind someone else having a go though.

Along the way a few bugs have been fixed (from the changelog):

  • IMP: O.DIR renamed to O.INC, it’s the value by which O is incremented when it is accessed
  • FIX: FLIP won’t interfere with the value of O
  • FIX: the O op now returns it’s set value before updating itself
  • FIX: the DRUNK op now returns it’s set value before updating itself
  • FIX: P.START and P.END were set to 1 when set with too large values, now are set to 63
  • FIX: CV.SLEW is correctly initialised to 1 for all outputs

The teletype.c file is a bit mixed up now that everything is an op. I’m not too fussed by this as my plan is to break the ops out into separate files, e.g. pattern related ops in one file.

@tehn, even though it’s still a bit messy, now is a natural point to do a PR / merge, before I start on the next bits. Yay or nay?


This is a brain dump of the things I’m thinking about working on next:

  • update the mods to use the state types
  • move the stack to command_state_t
  • break the ops into separate files
  • sort out pattern access (no more direct array access?)
  • use ragel to to make the parsing much much faster
  • move the scripts into teletype.c and implement a higher level script runner
  • get rid of the update_* function pointers, I’ll probably replace them with a compile time solution
  • move itoa from libavr32 to the teletype repo
  • fix those annoying rmdir errors on OSX
  • move all the documentation for ops into comments in the src code, and generate a manual from that

Shout out now if there is something you’d like me to work on next…

5 Likes

Wow. So much goodness here!

I’d love to see a PR. I’d be happy and keen to chime in. Do you we want a dedicated dev branch?

A few quickies:

I notice a bunch of tests which is awesome. Are you happy (enough) with greatest?

Could you elaborate on this? I was a little surprised that you weren’t taking advantage of the callbacks in tests but maybe that’s in anticipation of this move?

Ragel looks cool. Have you used it before?

Emphatic :thumbsup: ! Do you have a doc generator in mind?

Nah, too much overhead for such a small project.

Seems okay, it would be nice to write our own macros for testing commands. In particular better generation of failed messages. It was much nicer running tests than having to continually use the simulator or flash to hardware.

They’d be replaced with something equivalent, really there is no point to the current structure unless you plan on replacing the function pointers at runtime. Instead we can switch to normal functions defined in a header, but each target can provide it’s own implementation. The upside is that failing to implement the functions will be a linker error.

Nope! Never done anything like this before.

There’s flex too, but I think it’s more geared towards desktop computer use. Ragel looks to be a better fit for embedded.

No idea, just thinking aloud, something user orientated, maybe a python script. There are a 145 symbols defined in the ops table plus another 7 mods. Most of the stuff I’m doing is scratching my own itch, and I would like to have an up-to-date reference to print out. I think if it’s in the source code it’ll be easier to remember to keep it up to date.

1 Like

I hear you. I don’t like gratuitous branches either. My rationale was just that there are quite a few changes in flight here and wonder if there’s any risk of destabilizing master. Or if it even matters!

Awesome. The messages aren’t great but I’m spoiled.

Right! Function pointers don’t seem like the right choice here. Compile-time validation is a super bonus.

much yay!! happy to merge and test on hardware.

multiple files? what are the sorting classifications?

this is fascinating and i’m curious to see how this works.

will this not require more plumbing to communicate full scripts to main.c for display and usb storage etc etc?

this sounds crazy smart, again curious to see the execution

this makes a ton of sense also to make sure i don’t miss something between revisions of the docs, ack. TT is reaching a scale that requires some automated documentation. i had a weak initial attempt (which i’m sure you saw) but didn’t use it.

I’ll try and get the PR in today or tomorrow. I just want to find a bit of time to look over what I’ve done first.

Grouped by function, so patterns in one, maths functions, queue, input/output, etc. One of the things I found is that there is a lot of code duplication, particularly with input validation code. If we can have smaller files grouped by function it should be a lot easier to spot the duplication.

So am I…

Yes, and that’s a good thing!

2 Likes