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

Great! I’ll check it out as soon as I can! Just in case… have you dealt with the edge cases that tripped up my original haiku code? Specifically, dealing with the situation where the scale doesn’t include the root note, or worse still doesn’t include any notes at all?

#120

Sometimes a line of code (about 32 characters) is not enough. It would be great if a certain symbol i.e. _ can link two lines together.

Just my random thought.

6 Likes
#121

It feels to me like this new (extremely awesome) bitmask based quantizing functionality sits a bit weirdly with the existing N.xxx ops in general. Feels like they can’t really be harmonised without significantly changing their functionality. What’s the precedence for this in TT firmware development? Can existing stuff be radically modified, or is it rather better to do a new N. op that sits better with the QT. stuff?

IMO, what would work really nicely is an N equivalent to QT.B something like
N.??? degree root scale.

Actually, just writing this out made me realise that the order of arguments is also different between the QT. and N. ops. That’s something that could be fixed on the QT. side I guess?

#122

I’m sorry I don’t really follow except about the order of arguments. I’m not sure why the two would be related at all, unless you mean the QT.S and QT.CS (changed for consistency with N.CS) OPs. QT.B is its own thing, but QT.S/CS are actually using the N.S table directly. Can you expand a bit?

And yes, @SimonKirby, those edge cases are considered. Returning null isn’t an option in TT so if you leave your bitmask blank it will quantize to your root/octaves.

While we’re rapping here, a quick poll: should these quantize OPs accept & return N values, or CV values? I think CV values is more consistent with the existing QT OP.