#64

Making some good progress and am happily consuming the refactored teletype bits in my max external. Really love the cleanup. Kudos @sam!

A couple of quickies.

I’ve duplicated a few constants from main.c and wonder if there’s any reason they couldn’t be in teletype.h. Namely:

#define MAX_PATTERNS 4
#define MAX_SCENES 8
#define MAX_SCRIPTS 10

#define METRO_SCRIPT 8
#define INIT_SCRIPT 9

#define SCENE_TEXT_LINES 32
#define SCENE_TEXT_CHARS 32

I also snagged

typedef /* const */ struct {
    tele_script_t script[MAX_SCRIPTS];
    tele_pattern_t patterns[MAX_PATTERNS];
    char text[SCENE_TEXT_LINES][SCENE_TEXT_CHARS];
} tele_scene_t;

less the const modifier but I’m not 100% that it’s the right fit. Anyway, pulling it up is food for thought I guess.

More interestingly, I’m snooping on the new global scene_state_t scene_state instance which is REALLY convenient. To do that I removed the static modifier and declared it extern in my source. Obviously, this isn’t a long-term solution but for now, while cheeky, it works a charm. Curious where you’re going with scene_state… Any objection to making it properly accessible?

#65

Would anyone be kind enough to explain to someone like me what’s going on here ? :slight_smile:

1 Like
#66

Ha! Well, I can only speak for myself but I think this about some gorey details of the teletype implementation at the source-code level that @sam has endeavored to clean up. This clean up should make the source (and product) more robust and going forward make adding and modifying new operations easier. A good precursor to @tehn’s teletype V2 excursions. My particular angle, in the spirit of @jasonw22’s monome app preservation efforts, is to explore the possibilities of using the same teletype bits that are designed for hardware in a max application (implemented as a Max external). In an ideal world, we could get max counterparts to all the module firmwares for very little added effort. That’s the theory anyway!

2 Likes
#67

Thanks for the explanation. When we’re talking of a V2, are we talking about new hardware ?

#68

I thinks it just firmware cleaning up the code, fixing hacks, adding new features.

2 Likes
#69

no new hardware (tt expanders aside) but this is the thread about v2

1 Like
#70

Hello all, been busy for the last few weeks. Hoping to get a bit more time for some teletype hacking.

Probably. There is a bunch of stuff in main.c which is part of the teletype algorithm rather than IO handling (which is all it should contain ideally).

I’d like scene_state_t to contain everything that tele_scene_t contains. The eventual plan is that the global variable scene_state will disappear entirely, it’s just there as shim to help with the transition. Then each function in teletype.h will accept a scene_state_t variable as it’s first argument. It will then be up to each implementation to decide how to instantiate this variable. So on the module we might go with a statically allocated global variable (this time in main.c rather than teletype.c), but the unit tests will probably stack allocate a new instance for each test run.

There are a few other things than need moving over too, like script running, currently that’s handled by main.c. Also, a lot of the data access needs to be wrapped in function calls so that we can make changes to the underlying data structure without have to change lots of source code.

The handler_KeyTimer function in main.c needs inverting and breaking up (if anyone wants to volunteer!), currently it’s key code then mode, rather than mode then key code. Also handler_ScreenRefresh needs breaking up too.

And there is still the list I posted above (I’ve started on some of it now though).

Truthfully it’s going to take me a while to do all that, if I ever finish it, so I’m trying to do things in such a way that I can stop and still leave things in a useful state.

2 Likes
#71

So on one level we’re just tidying up and moving bits of source code around. We’re not really adding new features, but hopefully making it easier to add them in the future.

But on another more personal level, I used to be a professional web dev, which I gave up to be a not-so-professional dad. But I really like coding and while being dad is amazing, I also need to exercise my brain, so doing this fills a hole for me. Using the C programming language has been especially fun as it changes very slowly, which is great if you’re doing things very part time (insert rant about Javascript here), to my mind it’s analogous to hardware synths vs. software. Hardware synths never change, what you learn now is always valid.

3 Likes
#72

As someone currently trying to program some web MIDI stuff and associated UI, I couldn’t agree more with the C sentiment (though I’m more of a C++ guy…).

1 Like
#73

A few updates then.

Update mods:

Stack moved to command_state_t:


update_* functions removed:


tele_input_state replaced with tele_get_input_state:

@tehn this one confused me a little as there appears to be 2 declarations of input_state[], anyway I’ve removed the global var, and instead the function just returns the state of the input directly. Seems to work fine on the hardware.

Current todo list

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

this makes a ton of sense. are you basically thinking individual functions for each mode? so handler_ScreenRefresh etc are just calling functions based on mode?

1 Like
#75

Yeah basically.

The way I’d rig it would be to have each mode M_LIVE, M_EDIT, etc, have it’s own file with a function to handle the keypress and the the screen refresh. Then have main.c call the appropriate functions based on the current mode.

I’m also thinking that the module code (e.g. main.c) needs to be split out into it’s own directory, like we have for the tests and the simulator.

#76

Another progress update… the ops have now been moved into their own files

https://github.com/samdoshi/teletype/tree/dev/src/ops

They’re still quite messy. At some point soon I’ll work my way through each of the files and format them nicely.

3 Likes
#77

wonderful! i’m buried in arc business but i’m excited to start in on tt v2 very soon. your edits are going to make the experience much smoother!

1 Like
#78

@tehn is the mutes variable in teletype.c redundant? (there is another one in main.c)

I’ve deleted it.

Any idea when you’re going to want to start? I’ll try and make sure things are merged in first.

#79

Pretty decent Saturday of code (thanks to this), I’ve got the pattern data merged into the new scene_state_t struct.

I will say that before starting on anything to do with V2, main.c needs sorting out! Some of the bits of code in there are so deeply nested that you can’t do anything before hitting the 80 char limit. :open_mouth:

Current todo list

  • 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

Next up, it’s either Ragel, or move the script data into scene_state_t.

4 Likes
#80

Looks like this is OPEN SOURCE and IT IS HAPPENING. It’s exciting if tehn’s workload can be lightened and we can still move forward. Maybe it’s scary, too, but if tehn gives sam the go ahead, I guess I second that emotion…

#81

@sam

Fantastic work on the refactoring! Really thoughtfully done. Sincerely appreciated.

Quick question: I’m wondering if you’ve checked in the completed task of “break the ops into separate files”? Or, maybe I don’t quite understand the task as I still see all the ops sitting in teletype.c.

Thanks!!

b

#82

Just a quick reply incase your still awake… it’s on a different branch.

https://github.com/samdoshi/teletype/tree/dev/src/ops

I’ll try and post some more stuff later today so that you can keep your work easily merge-able. (I saw your questions in the V2 thread.)

1 Like
#83

Looking at my diary, I’m going to be a bit too busy to get much more coding done till late June now.

Almost everything I’ve done has been pushed up to the dev branch on my fork.

I’m currently in the process of wrapping access to the script array, but I haven’t finished it yet, and might not get a chance for the next few weeks. Once I’ve done that, I’m at the point of being able to completely separate the algorithm part from the hardware part. Ideally that’s when I’d have put the next PR in. But I’m wondering if it might be better to put a PR in now?

Here is the compare view from GitHub

@bpcmusic regarding i2c, I know that @tehn has been doing some work on enhancing the i2c communication, look at the commits for libavr32. I think it was partly due to another manufacturer’s module adding support for the II bus (and I think I know which one too).

Anyway, here is the ultra quick guide to adding your own ops, assuming that you’re working of my dev branch.

  1. (in case you’re not a git expert) Fork the repo and don’t work on the master branch!
  2. Create a new .c and .h file in src/ops/, maybe expander.c?
  3. Add the .c file to the Makefiles in tests and simulator, and to config.mk in src/
  4. Add the include to src/ops/op.c
  5. Create the ops (perhaps copy the CV, etc ones and adapt)
  6. Add the ops to the table in src/ops/op.c, don’t forget to update the number of ops

If you get stuck with defining an op properly give me a shout (or anything else you need help with). Unfortunately it’s still in a state of flux, so the comments or structuring aren’t the best.

3 Likes