#143

Yeah I think there’s only input mutes! Output mutes could be handy for sure. I’ll have to take a look in the code to see if it can be done.

1 Like
#144

suggestions are always welcome!

re: output mutes - makes sense to have these. this would require updating the live UI (and not sure it could be added to the grid control mode, there isn’t really space for another row of mutes).

welcome to lines! some of teletype code was done while listening to absolute time :slight_smile:

#145

I recorded Absolute Time live to DAT in 1994/95 … I was sequencing on an Amiga with OCTAMed tracker , hitting an S1000 and RZ1 … essentially things haven’t changed much! Creating Techno was so advanced at that time, and it still is. I couldn’t have imagined that workflow could get as refined as it has now with projects such as Monome. I am very proud to have been part of the inspiration!

Here is the remaster I re-released in 2015

3 Likes
#146

this would require updating the live UI

I’m currently just pulling the cables out - which is kind of brutal way of updating the live UI - couldn’t it just be an op? TR.M 1 ?

#147

you can already mute triggers with keyboard shortcut CTRL-F.. - this should be exactly the same as pulling cables out. if you want to do it in a script it’s MUTE x y where x is the trigger input (0-based - really ought to be 1-based…) and y should be 1 to mute or 0 to unmute.

edit: it is actually 1-based, the manual is incorrect, i’ll submit an edit.

1 Like
#148

Works as expected as far as I can tell and is really cool! Also neat that you can ultimately increase the progressive delay time by making the numerator higher than the denominator. What does the “G” mean in DEL.G? I just basically tested the bouncing ball and the weird reverse bouncing ball but I imagine there are some other pretty neat use cases for this after it sinks into my brain for a while.

These are working as expected for me. They seem to evaluate in a very immediate way. E.g. putting B1110 on the command line and pressing enter evaluates to 14 as expected. Pressing the up arrow puts 14 on the command line. Is that expected? Just thinking through @desolationjones use case for the DEL.B op (next on my test list) and doing something like

B1000101011110001

If I wanted to make a change the next time I’d need to retype it since it is now replaced with the decimal equivalent.

4 Likes
#149

:bowing_man: My beta above is lagging the official beta by a few commits, so no way currently to use the B and X nomenclature with my OPs yet! My goal this weekend is to rebase the code.

#150

Thanks for testing! The G is for geometric, as the op is producing a geometric sequence of delay times. I had some vague idea to make a corresponding arithmetic sequence version called ‘DEL.A’ which would add or subtract a value for each repetition, but I couldn’t think of any use cases.

#152

Yeah, not sure, nothing strikes me right away but sometimes it takes me a while to come up with ideas for various ops. One thing that crossed my mind with DEL.G (or any of the DEL family of ops) is that they could be pretty interesting with the S.POP op, though I haven’t experimented yet.

That was my understanding. Was just going to load your latest hex and convert outside the box but if you beat me to it with re-basing, even better!

A thought on the immediacy of the X and B representations of numbers. I understand why they work the way they do. Would it be possible to have some keyboard shortcuts, for example ALT+D, X, and B if not already in use, that would function in live and script edit mode?

If your cursor is over a number and you execute the shortcut it could convert the number to the requested representation? Then a commit/enter would still transform it to decimal for storage in the script/pattern/variable. I think that could be really useful for editing purposes.

1 Like
#153

I was looking at the P.NEXT implementation this morning and it got me thinking that it might be useful to set the step size for each pattern instead of always incrementing/decrementing by 1.

I took a stab at implementing get/set P.STEP and PN.STEP ops this morning and it mostly works, although there are some bugs I need to iron out with the wrapping logic for start, end and length.

One bit of weirdness is how it interacts with P.PREV. The step can be positive or negative, and P.NEXT adds the step to the current index, whereas P.PREV subtracts. It feels like there’s some overlap between P.STEP, P.PREV and maybe even P.REV because you reverse a pattern by doing P.STEP -1, switching from P.NEXT to P.PREV or calling P.REV on the pattern.

1 Like
#154

the reason it does that is because the live screen history stores parsed scripts, not the actual text (another side effect of this is - if you provide invalid input, it will not be stored in history).

this unfortunately also extends to editing scripts - it will convert when you enter a line (same if you edit a script and upload it via a usb stick). the fix for this would be to also preserve the number format in addition to its value. doable but quite significant and risky change.

this would also not solve the case of the live screen always displaying results in decimal format. one option would be to try and determine the format based on what numbers were used in a calculation but it gets more complicated if you do something like + XFF B0101. the proper way would be to be able to choose the format you want, and it could apply to both the output and variable display.

this is also a bit complicated - what if you are trying to convert a decimal number to binary and there is not enough space in the line? and this is somewhat covered by the existing functionality, since you can enter a binary/hex, hit enter, then use the history to add the rest of your line.

2 Likes
#155

Linking @csboling’s thoughts here for discussion. The proposal is the MUTE x would mute both external triggers and $ OPs, while $.POL 0 would simply mute external triggers. I like it because $.POL is already exclusively used to define script behavior in reaction to external triggers.

EDIT: Oh! Reading through the code suggests $.POL 0 already works as a trigger mute.

2 Likes
#156

I was experimenting with a local change to N.S, N.C and N.CS where instead of just wrapping back to to zero, the d argument will add will add or subtract octave offsets appropriately. Is anyone else interested in this, or are people attached to the previous behaviour?

1 Like
#157

I can’t seem to find the place in the source that handles “SCENE RECALL” (pushing button, turning knob, pressing button to load scene without keyboard attached), can anyone help me in the right direction?

#158

I think d works great as an octave offset and makes a lot of sense. In fact, that behavior is present in the QT.CS beta where the octave offsets are applied to the output. It’s a bit unique, perhaps, to have your quantizer also offset the result, but I figure it’s a nice treat for people who are playing with out-of-range degree values. The alternative is to cap or wrap the values, I guess, and lose the octave switch functionality.

Anyway, the behavior makes even more sense as part of the N.x OPs.

The other potential change would be 1-indexing degree. I’m still uncertain about this one, mostly because if degree is indexed from 1 then degree = 0 feels more like degree = -1.

1 Like
#159

You’re probably looking at preset_r_mode.c already.
The handler_Front function in main.c gets you into M_PRESET_R mode.

1 Like
#160

Totally agree 1 based indexing makes more sense musically. It’s a breaking change w.r.t. old scripts though, so I think we’d need to be quite sure about it.

degree = 0 is also totally weird, I agree. Maybe 0 should just be a dead-zone, and return the same as degree = 1?

1 Like
#161

I just installed the latest firmware from github, and something is either wrong or has changed with LAST. Here’s my dead simple scene (NB: changing $ to 1 gives same result):

#1
A LAST $

Triggering script 1 (either from trigger jack or by pressing F1), A just counts up, seems like it counts time from last time I was run (pressing F10 to run init confirms this since A starts counting from 0 again).

I suppose something went wrong with the new feature mentioned in the manual:

FIX: LAST SCRIPT in live mode gives time since init script was run
#162

Just reviewed that change and I don’t think it could be causing your issue.

My studio is torn apart right now for renovation so maybe someone else can try to replicate the problem. I’m behind a couple firmware revisions but I was definitely using M LAST 8 in script 8 for tap tempo a couple weeks ago…

Ack, dead zones bug me even more. If you’re modulating these discrete musical parameters using a continuous CV it’s desirable to have a smooth response rather than a lag around 0. How about we go to 1-indexed degrees and just let 0 feel weird? It’s probably an edge case, anyway, because most theory-inclined coders will limit their scale degrees to I thru VII.

#163

Thanks! It would be awesome if someone else could look into it, it’s definitely not working correctly here…

NB: If it matters I pulled the latest (no tags) with:

git clone --recursive --config core.autocrlf=input https://github.com/monome/teletype