#89

sure. output expander is easy to test this way (i’d already hacked it in).

eager to see the specification and explore a custom operator to speak with multiple expanders. also, i’m very curious about your preferred implementation for pulling data in so I can build out the input expander functionality.

thanks!

b

#90

Here we go then… let me try to summarises what changes I’ve made, and what’s left to do.

  • The ‘pure’ algorithm code now resides in the src directory, while all code related to the module is in module. Hopefully this will allow main.c to be broken up into smaller files and for it to be obvious what those files concern. There are definitely things in main.c which really belong in src, things like inserting and deleting lines from a script, which currently make quite intrusive modifications of the arrays, rather than calling a higher level function like e.g. tele_script_insert.

  • The algorithm state is now represented by 3 structs, scene_state_t, exec_state_t and command_state_t, see state.h for details. The only static variable left in the algorithm code is a static scene_state in teletype.c, at some point soon that will be removed and all the functions will expect a scene_state_t as the first argument (the ops already do).

  • Ops have now been broken out into separate topical files. This is to keep like minded code together and make it easier to see ways to reduce code duplication. A good future example of this will be when I (or someone else) creates PN.* versions of all the P.* ops.

  • Scripts are now executed using run_script and run_command which take care of creating a valid exec_state_t (process is still there doing the actual business). This means that the behaviour of IF, ELSE, and ELIF have changed subtly. But on the plus side it should be trivial to add a STOP op to halt the current script.

The big things left to do are…

  1. Get a grip on main.c
  2. Get rid of the static scene_state
  3. Rewriting the parser to not use strcmp (probably via ragel)
  4. Build a better user documentation system

To the best of my knowledge everything still works properly, but I haven’t been able to test it a lot. Given how much has changed I find it hard to imagine that some bugs haven’t slipped in.

The code itself is still a WIP, but I’m probably not going to have much time to work on it for the next month. So it seems like a good idea to get it merged in now. Any questions please ask either here or on the issue.

Just a quick thought on the i2c stuff, I’ve never really used it before and I know very little about embedded programming outside the teletype codebase, but…

I’d say it’s important to over engineer the protocol, given how many different modules (and alt firmwares) will be using it, it’s going to be very difficult if we need to continually update them every time it changes. Even more important, if we do need to change in a breaking way, there needs to be a way for those messages to be rejected by devices running older codebases. It would be terrible if someone was to buy a new meadowphysics, connect the II bus and then have their teletype constantly crash due to protocol incompatibilities.

3 Likes
#91

doing a big review today of this! looks amazing. thank you so much. it’ll take me a bit to fully wrap my brain around what you’ve done here.

re: i2c, @zebra and i are definitely accounting for very broad use cases. we’ll deal with firmware updates to keep other things up to date and deal with message breakage.

1 Like
#92

thank you for this huge effort! will be reviewing the PR / commenting sporadically this week.

re: i2c - agreed on over engineering it and accounting for potential future use cases. would be great to have the ability to pass different number of parameters for different commands, and to be able to pass an array of values as well [such as pattern data].

i think back compatibility shouldn’t be a huge issue? since all the existing firmwares could be updated prior to that, and then when folks update their teletype it’s easy to update all the modules at the same time? but perhaps the updated protocol could start with a byte that is not currently reserved for anything so any modules running the old firmware could just ignore the new II commands [assuming they can deal with more data being sent].

1 Like
#93

I’m about for the next fews days if anyone does have any Qs. After that response times might be a bit slow (till late June).

The sketchiest bit of the code is the most recent, the script array getters and setters, basically it’s unfinished, eventually it will be replaced with more semantic functions (e.g. tele_script_insert), but replacing the direct array access with functions seemed like a useful stepping stone when I was refactoring.

On the i2c front, I’m guessing that @zebra has had some experience with this via the e bit of the Buchla 200e system? That’s i2c based too isn’t it? Practical experience trumps theoretical knowledge…

#94

the 200e has a lot of i2c. we’ve been discussing it.

i’m wading through the PR and haven’t come up with questions yet, though i have much more to cover.

1 Like
#95

started looking into https://github.com/monome/teletype/issues/16 [key behavior: repeat on hold] somewhat selfishly wanting to specifically add support for holding backspace while editing, and right now it’s implemented separately for each supported key in handler_KeyTimer.

it’d be trivial to add it for backspace only, but thinking it might be good to refactor it to support any key hold by extracting key processing into a separate function and then calling it from both handler_KeyTimer and handler_HidTimer, so in essence the latter will imitate a key press when appropriate. any concerns / objections for such change?

#96

made the change as described: https://github.com/monome/teletype/compare/master...scanner-darkly:dev
did a quick test and everything seems to be working okay. will do a pull request after i test it a bit more.

3 Likes
#97

thank you for breaking out process_keypress as i was going to do that myself!

#98

going to refactor it a bit, remove global variables for the modification keys and add a parameter for specifying when it’s a held key as in some cases repeated key should be ignored (like saving a scene, for instance).

realized makefile for clang-format is Mac specific, is there a way to write in a way that would autodetect the OS and run a different command on Windows?

#99

https://github.com/monome/teletype/pull/44

finished key repeat implementation. reformatted earlier code a bit (got rid of global key variables in process_keypress) and also key repeat will now be ignored for writing and reading from flash. key repeat will still work for triggering scripts - thought it might be useful to have it work that way…

also found a couple of minor bugs from @sam’s refactoring, pattern length wasn’t getting properly updated in some cases, and [ and ] didn’t update values when in TRACKER mode, that’s fixed now. also made a change to ENTER behavior when in TRACKER - it extends pattern length when pressed on the last step as before, but now it will also go to the next step regardless of where it’s pressed, not just when on the last step - this seems like a good thing to have.

and discovered a few key combinations i didn’t know about! CTRL and CTRL+SHIFT in TRACKER mode specifically is rad, very handy to be able to set pattern values with the PARAM knob…

5 Likes
#100

thank you for this! and yes good suggestions with the key behavior.

1 Like
#101

Was just working my way through the implementation to support negative voltages for my output expander and found a little inconsistency in the way voltages are handled in the Teletype code. From the web page:

These are typically used with CV output, since CV has a fine granularity (14 bit), full range which is 0-16383.

So V 10 (ten volts) is 16383. V 1 is 1638. N 1 is 137, for a semitone. This way we can use readable (small) numbers and then translate them to CV easily.

But - when I look at “V 10” I’m seeing 16384. A quick peek at the table backing the conversion and you can see the lookup for V 10:

const int table_v[11] = { 0, 1638, 3277, 4915, 6554, 8192, 9830, 11469, 13107, 14746, 16384 };

I bounded it for the operator for the output module, but we might want to take a quick peek at the tables to ensure that the values are proper. Rounded, 16383 spread across the (11) values would be:

const int table_v[11] = { 0, 1638, 3277, 4915, 6553, 8192, 9830, 11468, 13106, 14745, 16383 };

This change also corrects the range for the VV operator as well (as it is based off the V table).

b

1 Like
#102

@scanner_darkly thank you so much for doing this!!
was just going to report a “bug” when pressing ctrl :smile:
forgot about that too!

hex file seems to be half the size of before? can this be true? is that @sam’s magic or will I be hitting a wall because of wrong compilation… so far everything seems to be working.

#103

not sure about the size - looking at the official releases v1.1 is ~597k, v1.2 is ~227k and the latest code built is ~242k, but both 1.1 and 1.2 point to the same checkin in git, so hard to say what was changed. i do seem to remember one of the releases included the default scenes with it, maybe that’s why?

#104

ah yes was comparing with 1.1, maybe the asf diet? or the scenes…

(nevertheless, big cheers to @sam too for helping out so much here and laying the foundation for future developments!)

1 Like
#105

Apologies for posting to this thread, after some internal debate it seemed like the best place.

I’m working on expanding the base teletype code to support the input and output expanders for the Teletype and I’ve ran into an interesting behavior that, while I await my replacement FTDI cable, I was wondering if anyone had any ideas as to what could be going on. It centers around inconsistent behavior with the metronome script vs. the trigger scripts.

Output is working great for me with the straight i2c transmissions (via i2c_master_tx); I’ve been able to blast messages of varying length and everything stays solid with no perceptible timing impact. Whoot!

Input is also working pretty well. I’m able to use a slightly modified version of the i2c_master_rx command to send out a message and retrieve a value. (The modification was to pass the data array into the function so that the value could be extracted.) The remote i2c device gets the command and then returns the value. It is perfect in that regard. I’ve executed these pull commands countless of times from the realtime command line and as scripts running off of triggers. In fact, in a trigger, I can pound it ridiculously fast for as long as I want with any function ordering.

There is one circumstance where I can get the Teletype to lock up 100% of the time. If I add the read command to the metronome script and it is not preceded by and i2c send command, the device will lock. If there is a send command prior, I can run the metronome script for hours or as fast as I want (M 1) without any issue. It is shockingly responsive in that regard. but, if I don’t issue a send command prior to the read command, the thing locks instantly.

This works without fail in a metronome script:

TO.TR.PULSE 1
CV 1 TI.PARAM 1

The first knob of the input expander drives the Teleype’s CV output. Again, I can run that as fast as I want (M 1) without problem. I can even read it four times in a row (there is no caching) and it blazes:

TO.TR.PULSE 1
L 1 4 : CV I TI.PARAM 1

Omit the TO.TR.PULSE 1 and the Teletype freezes - even though it will work from a trigger script.

CV 1 TI.PARAM 1

Switch to the Teletypes param and it works without error.

CV 1 PARAM

Any thoughts offhand about the metronome processing and what could be at work here? I’m scratching my head a bit as the same script executed off of a trigger works. Strange.

–

You can reference my fork here if you are curious beyond the above high-level question:

https://github.com/bpcmusic/teletype/tree/to_operator

b

#106

Hi all, I’m kinda of back now. I’ll try and catchup with what’s been discussed in this thread and (eventually…) get back to code hacking.

Did you get this sorted out? There is definitely a way to do what you’re asking. I can point you in the right direction if you’re still interested?

#107

no, didn’t get a chance to look into it as it’s simple enough to just run clang-format manually. but yeah, should probably fix. doing a quick google search looks like ppl recommend using uname or $(OS)?

#108

This is how the asf Makefile does it:

(this is also the bit that I will need to tweak to stop the rmdir errors on OSX)