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

#123

Oh, was just going off the argument order for QT.S and QT.CS that was posted above. If they’re now the same as N.S and N.CS, then great!

I guess the wider point that I was getting at is that we have essentially one broad use-case - putting stuff into a musical scale. We then have two slightly different paradigms to get there. You have the binary specification of scales like QT.B or you have the lookup table approach of N.S etc. The binary method seems strictly superior to me, apart from some extra knowledge burden. In the long run, it feels a bit confusing to have these two parallel methods, but maybe that’s just me.

About the N vs CV question - conceptually I feel like it makes more sense to work on N values. The ops fundamentally are working in the semitone domain, and you might want to do further manipulations in that domain before you convert to a CV value for output. I agree that the inconsistency with QT is unfortunate, but that is a general purpose quantizer rather than specifically a musical one, so IMO it’s not such a terrible thing.

1 Like