Sure, no problem. I also don’t want to derail this thread as it is hard for me to predict when things will be finished etc. so I can always move it to separate topic if it will help reducing noise in the thread a little.

1 Like

Is it possible to include some way to select between two w/ ? It would be nice to have teletype send synth ops to one w/ in my case, and delay ops to another. Like how two ansibles can be on the same bus and app specific ops don’t interfere with the other…Or is this the case already? App specific opps wont crash two w/ running separate apps?

if W/ are in separate modes it should work already - each W/ mode has separate i2c address so you should be able to control one tape, one synth and one delay at once

1 Like

One thing worth mentioning is in tape mode @Galapagoose mentioned in the video, is the timestamp command in Crow. Placing cues is done in absolute seconds. So for a tape which is hours long, it would be huge numbers, which wouldn’t be compatible with Teletype. W/ is also expecting 32 bit numbers and Teletype apparently uses 16 bit ones. So not sure cues can be added via Teletype, only by Crow.

@mlogger: So setting it from teletype should be fine. I have made in beta firmware for timestamp operator W/T.T to accept one argument (seconds) and set subseconds as zero. But I will fix it so it will accept two args: seconds and subseconds. But as Galapagoose mentioned retrieving that data will require some consideration.
I have created separate topic for W/ 2.0 integration to not interfere with other work underway already (MIDI integration etc.): Teletype and W/ 2.0 integration

4 Likes

Scale & Chord Quantizer Beta Firmware
Add QT.S and QT.SC OPs for quantizing semitones to a given scale, or to a given chord in a scale. Reference the N.S OP for scale selections.

QT.S input root scale
Input semitones, returns nearest semitone from within given scale.

QT.SC input root scale degrees voices
Input semitones, returns nearest semitone from within given scale degree. voices from 1 to 7 sets how many notes in the chord: 2 is a third, 3 is a triad, 4 is a seventh, etc. degree is indexed from 0.

(EDIT: removed old build, see below for latest experimental f/w)

WIP: VN X OP for volts-to-note, equivalent to / X N 1 but saves 3 characters :laughing:

7 Likes

This makes me wonder about the possibility of user-defined scales (in binary, with the LSB as the root note).

For instance, QT.DEF 9 161 sets scale 9 to the mask 0000 1010 0001, which would be the root + 4th + 5th.

Yeah I think it would be possible. I think I’d want to start by adapting the current OPs to accept scales which don’t have 7 tones, and to accommodate non-12tet schemes. Probably I’m not currently interested enough to dive into that but if I get bored with the intervals possible with my new OPs I might take a swing :slight_smile:

Maybe the more immediately interesting problem is binary-to-dec conversion, etc, for storing masks. I also have stored numbers in different places within a single number (my favorite Euclidean scene stores fill, length and rotation like “FFLLR” e.g. “5081” is 5 of 8 beats, rotated by 1 beat) so the whole number storage / extraction thing could yield some scripting efficiency, personally.

2 Likes

Instead of saving the scale definitions, how about an OP QT.B input root mask where mask is a 12-bit number?

1 Like

That seems a lot simpler :slight_smile:

Bitwise Scale Quantizer Beta Firmware - Untested

QT.B input root mask
Input semitones and a 12-bit note mask where LSB = root, returns nearest semitone in scale (corresponding bit set to 1 in scale mask).

VN input
Input volts, receive semitones. Essentially quantizes the input to the N table, so it’s a bit more complex than just / X N 1.

Also includes QT.S and QT.SC from above post.

Edit: (removed bad build, updated below with BITS OPs)

Next up: OPs for getting/setting 4 bits of a number at once.

Someone remind me though, why are BGET and BSET separate OPs? Would we be okay with an equivalent BIT OP for getting/setting based on number of args? Then the 4-bit version of the OP could be BITS.

8 Likes

Okay unless anyone objects I think that the BIT and BITS OPs will work like this:

Set bit Y in number X:
BIT X Y 1
Clear bit Y in number X:
BIT X Y 0
Get bit Y from number X:
BIT X Y

Set 4 lowest bits in X to 1010:
BITS X 1 1010
Set 4 highest bits in X to 0011:
BITS X 4 0011 or just BITS X 4 11 since leading zeroes are discarded
Get 4 second-lowest bits in X:
BITS X 2

EDIT: I just remembered a PRE I thought up while drifting off to sleep last night; DEL.B time bits:... where time is your resolution and bits picks which multiples from 1 * time to 16 * time are triggered. Or should LSB = immediate instead of 1 * time? I think I will also increase delay size to 64 for this build.

Also can someone point me in the direction of a tutorial for syncing my local files back to github and making pull requests? I used git for Windows to clone Teletype but I’ve just been working naively in the Windows directory with no change control or w/e.

1 Like

These all look really useful @desolationjones!

DEL.B is some kind of bouncing ball?

DEL.B is for “bitwise delay” so you can make funky delay patterns, like 1000100010001111 for Blue Monday-esque kick drum :laughing:

We already have DEL.G further upthread for bouncing ball patterns!

2 Likes

you would have to convert the sequence into a decimal number though (using bit ops) since you won’t be able to just enter a string that is not a number within the int32 range.

2 Likes

Yep that’s a given. I think the BITS OP is as close as we can reasonably get. I guess the DEL.B OP could accept just 6 bits and you could put them in “binary”… That feels more accessible but less powerful, especially because we already have all these fun ways of manipulating 16-bit numbers in a bitwise fashion.

Would hexadecimal parsing help? Or would most people just find it confusing?

E.g. DEL.B 100 #888F

A hex to dec OP would be rad. I’m just uncertain about how deep that rabbit hole is because I don’t think any of the other OPs accept alphanumeric input.

yeah it would be a deeper change that needs careful consideration - i’m not familiar with the parsing part of code so not sure how difficult it would be to change.

it wouldn’t be an op (since it would mean adding a special op that interprets parameters differently) but a way to enter numbers using a different format, something like B10101010 or XFF. i think this is a better way, and wouldn’t require creating separate ops that treat decimal numbers as a string representation of binary numbers (which might get confusing).

edit: just tried it out of curiosity and looks like it’s a simple change. before i make a new version - we should probably start merging some of the new stuff into the main branch as we have 6 beta versions at this point! (a good problem to have but it’s going to get messy if we add any more before merging).

5 Likes

Pondering a DIG input digit qty OP for getting these embedded numbers. OTOH I like my hacky modulo + division approach just fine and there’s not a great way to make this OP both set and get.

/ X 1000 (8 chars) vs. DIG X 3 2 (9 chars)
% X 10 (6 chars) vs. DIG X 0 1 (9 chars)
% / X 10 100 (12 chars) vs. DIG X 1 2 (9 chars)
So there is a use for it when you’re pulling out from the middle of a number!