#99

I have this recurring dream of being able to trigger TT scripts from Crow, which would require TT to be able to act as an i2c follower. Norns + Crow + TT could then control four voices of CV+gate+other (velocity, expression, whatever), with TT as a kind of auxiliary live-coded manipulator of events generated by Norns (or by a standalone Crow script).

I swear this has come up before and wasn’t immediately declared impossible, but I’m having trouble finding that conversation. Is there i2c follower code in Multipass that could potentially be rolled into TT by a mortal like myself?

1 Like
#100

I think Trent mentioned some crow features which would let it respond to I2C queries. IMHO that is a much better choice than getting into the multi-leader quagmire. You could hypothetically use a fast metro to query crow and run scripts as crow dictates.

#101

you don’t need multipass for this - it’s fairly simple to configure teletype to work as a follower (and shouldn’t cause any issues if you’re just planning to only use it as a follower).

replace this line: https://github.com/monome/teletype/blob/main/module/main.c#L987

with init_i2c_follower(0x31); process_ii = &tt_process_ii;

(0x31 is er-301, you can use er-301 crow functions, or change address to something else and modify crow code)

and add this:

static void tt_process_ii(uint8_t *data, uint8_t l) {
    if (l != 3) return;
    if (data[0] || !data[2]) return;
    if (data[1] > 9) return;
    run_script(&scene_state, data[1]);
}

data[0] should be 0 (gate message for er-301)
data[1] is the gate index, 0-based
data[2] is the gate state (1 == on, 0 == off)

didn’t test it so bugs/compilation errors are possible

1 Like
#102

You’re amazing. Thank you so much, that got me 99.9% of the way there. The hardest part was finding some unused connectors to make an i2c cable with.

For now, I’m using command 5 (trigger pulse) instead of the gate set command – command 0 wasn’t working for me, possibly because Crow seems to send the gate/trigger state as 16 bits, but I haven’t investigated that very deeply yet.

So much for me to explore now that you’ve demystified this step for me. Thanks again.

2 Likes
#103

I’m a bit behind with all these brilliant suggestions, but I just wanted to chime in with strong support for this approach, where any op can take a decimal or binary (or hex) number, and have a format for writing binary or hex for convenience, rather than have an op interpret a decimal number as if it were binary.

When I coded my bit-based quantiser haiku, I quickly got used to referring to specific scales or chords using their decimal number, which I could type quickly in to a variable to change things up on the fly, and which could be stored in the tracker for scale changes etc etc. It would be nice if I could also type them using the B notation, but also nice not to be forced to (and of course, there’s the problem already of them being too long in some cases - for my quantiser I needed 11 bits for a scale). Also, I’d like to be able to use standard math and bitwise operations on binary to manipulate the numbers passed into the ops which presumably wouldn’t be possible if they were expecting a decimal number that was pretending to be binary.

2 Likes
#104

ok, let’s consolidate outstanding features.

MIDI IN ops - this still needs work, i will rebase on the latest once we merge other features

DEL.G op - pull request merged

disting EX integration - i need to add documentation, will submit a pull request this week

W/ integration - @karol - looks like still in dev, once we post a new consolidated beta will you be able to rebase your build on that?

Scale quantizer OPs, bit-masked delays and quantizer - @desolationjones are you ready to make a pull request? i can help if anything is not clear about the process.

binary / hex format for number - will submit a pull request this week.

9 Likes
#105

I will get the docs squared up tonight. Then is this the right order of operations?

  1. Fork Teletype, then clone to local
  2. Apply my changes locally
  3. Run tests and format
  4. Push my changes to my Github repo
  5. Submit a pull request to Teletype
2 Likes
#106

yep, that’s it. the only other thing is to make sure simulator also builds without errors.
for documentation also update docs/whats_new.md and changelog.md, and add to module/help_mode.c

1 Like
#107

Strong agreement. I will mention that the “decimal-as-binary” OPs in question had ONLY the function of making that conversion and that they were the only such OPs.

The DEL.B and QT.B OPs accept normal, signed 16-bit integers for the masks (though QT.B only uses the lowest 12 bits). In fact, QT.B is directly inspired by your haiku (with additional thanks to @starthief for the memory jogger) :smiley: Please give it a try!

1 Like
#108

Are there any plans currently to get the JF2 ops up and running, or is that a more involved / lower-priority operation?

1 Like
#109

There’s some discussion over here:

The JF changes are definitely on the collective radar. I think we are trying to get all other loose ends tied up first!

4 Likes
#110

Ah! Thought I was up to date on that thread. Thanks!

Y’all got a lot of fun stuff cooking :fire::fire::fire:

1 Like
#111

Sure, I will rebase - no problem, please don’t delay anything just because of me.

2 Likes
#112

Thanks to everyone contributing to pull together the loose strings of the next version of TT firmware.

1 Like
#113

that’s why i suggested to rebase - it sounds like your feature is still in active development? if it is, the plan is to incorporate features that can be considered “stable” at this point, release that as the new “official” beta, then rebase features that are still in active development on that (this way they include all the latest complete stuff).

1 Like
#114

So I have this QT.SC input root scale degree chord OP indexing degree from 0, but that feels vaguely wrong. Scale degrees start at I, right? But the N.C and N.CS OPs already index degree from 0. Thoughts?

Also, I am a bit stuck because I can’t seem to push changes to my repo. So far I managed to set monome/teletype as upstream, then merge locally.

#115

do you get an error when you push?

#116 
$ git merge upstream/master
Already up to date.

$ git remote -v
origin  https://desolationjones:********@github.com/desolationjones/teletype (fetch)
origin  https://desolationjones:********@github.com/desolationjones/teletype (push)
upstream        https://github.com/monome/teletype (fetch)
upstream        https://github.com/monome/teletype (push)

Is there just a “push” command?

#117

you need to commit your changes before you push them: https://git-scm.com/book/en/v2/Git-Basics-Recording-Changes-to-the-Repository

1 Like
#118

seems like an uncomonly clear case for 1-based indexing. <omit rant about how 1-based is often correct>

1 Like