Over in code exchange I saw a line that made me think SCALE needs a short alias: Y QT RSH PRM 7 10. I get what the line is doing, converting the param knob into multiples of 10 between 0 - 100 for use as a probability. I’ve wanted to scale the param knob to 1-100, but have run into space issues, Y QT SCALE 0 16383 0 100 PRM 10 is (in my opinion) a clearer line, especially if you’re not entirely comfortable with bit shifting, plus the original solution could return numbers as high as 120.
Don’t mean to rabbit hole on the specific solution, but - wanted to open a discussion for OPS that could use shorter aliases. SCALE is one I like a bunch but I end up having to work around because it’s a lot of characters.
That line of code looks really familiar! ;D
I did in fact have to avoid SCALE because I’d have too many numeric characters to type.
This did force me to get more comfortable with RSH/LSH, fwiw, and that has been useful. But even that line of code didn’t get me exactly what I wanted - I just said “f_ck it, close enough” after a while of screwing around.
SCALE definitely seems like one that could benefit from an alias, simply because often you may have larger numbers to type in, especially if scaling IN or PARAM. Then again, maybe there’s a better solution for scaling IN/PARAM to 0-10 range or something like that. I figured I must have been overlooking something that would be obvious in hindsight, but I just wasn’t connecting the dots.
For example, I re-read some of the TT studies and noticed this: CV 1 QT PARAM V 1
That quantizes to whole volts. I wonder if some combination of using the built-in tables (like V or VV) would be better for the same solution? Or maybe another voltage table for scaling PRM or INs to 0-10 range specifically? Scaling 16383 and numbers that large is where you really start burning up characters (SCALE -> SC only would save 3 characters).
I don’t know what it takes to add tables, but - agreed for a few reasons. I’ve been messing around trying to fix the just intonation op over on Github, which looks like it needs a big table. More tables seems like a solid idea (says someone who knows very very little about how difficult that would be to implement.)
good thread! i’d like to request again adding $ as an alias for SCRIPT (i might just go ahead and add it in my grid branch).
for scale i think SCL might be easier to remember. @sliderule is also adding PARAM.SCALE and IN.SCALE ops in (Teletype) 2.2 Release which might be a better workaround specifically for PARAM and IN.
in this vein, WRP for WRAP?
i often do it like this: X SCALE 0 V 10 0 100 PRM. V is very useful as a way to shorten scripts.
Yeah I think $ for SCRIPT is a big win, not only is that 5 characters saved, but it’s pretty often you might have some specific conditional (high character count) and you need to put the actions in another script. I’ve definitely had cases where SCRIPT x ended up being too many characters.
Although SCL would be my suggestion too, I don’t know if the -2 character different outweighs the lower readability. Either just for people new to the platform, or even when coming back to script after some time (depends how often you use SCALE I suppose). For example, I still like using PARAM unless I have to use PRM just because it’s easier for me to read/understand.
I would definitely suggest that the IN/PARAM SCALE be SCL, though. At least with PARAM.SCL, even if you can’t remember whats SCL is exactly, you get a hint that it’s an operation on PARAM. And if you’ll be able to do PRM.SCL that’s also a significant character count savings.
Nice! I also just tried DIV PRM V 1 and that gives me 0-9, which is actually what I was originally trying to get. Although I’m seeing that SCALE is more useful as it will allow me another thing I was trying to do, invert the response of PARAM, like for tempo (faster going CW). i.e. SCALE 0 V 10 100 0 PRM
I must say really I like MAP, as being used by the expanders. It also embraces the offset and is shorter.
Then again, a change would break previous scenes, so I guess it makes more sense to stick to scale.
+1 for $
edit: another idea, MAP as alias for SCALE. would be too confusing I guess.
What do you mean by the offset ?
I love MAP, it’s 3 letters, and commonly used in other languages. i could see as a replacement for SCALE. Older scenes would be quite easily fixed.
I also give my vote for $.
I mean, scaling is by definition enlarge or shrink, whereas mapping has a source and destination (as our op does) and therefore in the 2D realm possibly introduces an offset to the (start of the) source range.
does this makes sense? sorry, I’m terrible at explaining
edit: I guess it’s just my interpretation, as it’s SCALE and not scaling.
