#451

Ah, good to know! Thanks!

#452

anyone else having problems flashing current 3.1?? (on a first edition teletype)

symptoms:

TT boots and shows its usb-saving screen, and then crashes. no screen, leds TR2+TR3 on, nothing happens…

this is with pre-compiled binaries from the 3.1 release. also tried compiling 3.1 myself with the same result. going back to 3.0, everything seems to be working as expected.

(disconnected a power hungry module in the case, should be plenty of headroom either way)

edit: ha! so after confirming a usb save operation with the button (even without actually inserting a thumb drive), 3.1 works as expected and across power cycles.

(would be happy to test a possible fix, but since it’s no issue after pressing the button…)

#453

do you remember what it said on the screen when it happened? this sounds like the bug fix that we added to prevent teletype from accidentally erasing everything in flash memory. if the part of the code that does that gets called somehow, it should show a warning message and ask you to confirm.

this should never happen during normal operation but it does need to reinitialize flash after installing new firmware, and if you don’t, flash will contain garbage which tt then tries to execute and freezes.

1 Like
#454

omg. thats it! I was so sure it meant for usb saving/recalling on startup :see_no_evil:

but: I don’t understand this feature yet. it also says: “do not press otherwise”, which implies I have a choice. but if I don’t confirm it stays in this limbus state, unless I confirm it on any future startup and the new firmware is flashed. don’t get me wrong, I don’t see much benefit in putting any sweat in this either.

3.0 flashes and boots into normal operation so I was just a bit confused and worried I broke something by flashing it, since I had previously added modifications :sweat_smile:

many thanks!!

1 Like
#455

i agree the message could be clarified - it should explain that you should only need to press the button if you’re seeing the message after flashing a new firmware.

#456

This post got me thinking about some possible ops and mods for doing transformations of a whole pattern at once. Would love to hear other ideas, syntax thoughts, whether these would be worthwhile as ops or are just as easily scripted, other thoughts! Each would of course need P. and PN. variants.

P.SHUF           -- shuffle the cells in a pattern 
P.REV            -- reverse a pattern
P.LROT / P.RROT  -- rotate the pattern cells backward / left or forward / right

Also possibly interesting could be mods providing higher-order functions that let you run some code on each pattern cell, populating I and/or J variables with each pattern element, like a specialized loop mod. For instance, the map and scan (like fold, but keeping the intermediate values) functions:

P.MAP: * I 2     double each cell in the pattern. equivalent:
                 L P.START P.END: P I * P I 2
P.SCAN: + I J    replace the pattern with its cumulative sum. equivalent:
                 L 1 P.L: P I + P - I 1 P I
6 Likes
#457

Love these! MAP is particularly elegant! (Though it immediately makes me wish there were return values for scripts. :wink: ) Syntactically it’s a bit unusual, though. For a line with multiple statements will it just use the last one as the value that the pattern cell gets set to? E.g. P.MAP: $ 1; A to mean “for each cell in the pattern, call script 1 with I set to that cell, then replace the cell with A”.

I suppose it would make sense to have a P.FOR as well? I.e. just like map but without changing the pattern so you could just do something with each cell in a pattern, like: P.FOR: JF.NOTE I V 5 to play a chord on just friends with all the notes in the pattern.

1 Like
#458

Are these thought to work with parameter? Like shuffling only cells 6 to 12 of a pattern. I would very much like it then since I sometimes use different parts of a pattern for different purposes at the same time.

4 Likes
#459

Hm, I had been thinking basically that they would operate between P.START and P.END. Dunno if this would work for you but it sounds like in that case you are maybe accessing cells by their index directly? With P. and PN. variants as well as variants that accept endpoint arguments this could quickly be a lot of new ops. Could only have the ops that have endpoints but then P.SHUF P.START P.END gets kind of verbose.

Good point, I have not implemented any MODs yet on Teletype so I don’t actually know if this idea is possible in the existing framework! Will have to fiddle with it and see what makes sense.

2 Likes
#460

In this respect the imperative style P.FOR might be simpler? Good luck - happy to see you getting into Teletype modding! Your work on ansible is awesome :slight_smile:

2 Likes
#461

Yes, I have to admit that I only use direct access to pattern values via their index. How about START to END function when no parameter is added and index to index functionality when indices for pattern an positions are added?

#462

On the rotate ops, I could see having a parameter for how many steps to rotate. (Also, accepting negative numbers means not needing two different ops.)

3 Likes
#463

Hi there,
do I understand correct: I have updated my teletype to firmware 3.1 (july 7, 2019) from there: https://monome.org/docs/modular/update/
I just tried to DEVICE.FLIP. But the trigger INs wont work anymore. Correct or do I something wrong? I searched about this issue and found at least this "newer" firmware posted here, which fixes this issue right? Im only asking because its curious, that on the monome page is still the version which wont work in DEVICE.FLIP-Mode? So is the here posted firmware the latest and really fixed the trigger IN issue? Any known issues with it compared to the original 3.1 on monome?
Thank you!

#464

Sorry for the confusion, you’re correct that a change I made that went into v3.1.0 (adding the SCRIPT.POL op) causes DEVICE.FLIP to work incorrectly. This is fixed in the newer firmware builds I’ve posted, confusingly, in the first post of the Ansible development thread, because they’re needed for exercising some newer Ansible features and I’m not able to edit this post. It’s been a while, we should probably make a new release. I believe there are a handful of other bug fixes and new ops in the builds in the other thread, I don’t believe it has any new issues.

1 Like
#465

I estimate that Brian don`t replace the file on the monome firmware page for a good reason. On the other side there are for sure a few users who will have the same issue like me, as a lot of like the flipped teletype :slight_smile: anyway, thank you for your short-term support!

#466

From what I can tell this is not really possible with how the Teletype language works. You have get/set ops that take one optional argument but these work a bit differently and I’m not sure if it’s possible for two optional arguments. Reversing or shuffling within a range seems quite useful though, I think separate ops for this makes sense. What would you expect them to be called? I’m thinking like P.REV for “reverse between START and END” and P.RREV for “reverse the specified range”, kinda analogous to RRAND?

Happy to report that this works exactly as you describe!

Thought of another op: P.CYC – fill the pattern by cycling through the values in active pattern length. For instance this can be useful to enter scale notes once and fill the whole 64 cell pattern by repeating the scale.

And another mod idea: PN.ZIP 0 1 3: + I J – fill pattern 3 by combining patterns 0 and 1 cellwise, using I and J to capture the cell values. Really it might make sense for all of these to take an argument for the destination pattern index so you could create transformed copies of patterns rather than overwriting them?

5 Likes
#467

An operator that is a combination of L and DEL would be quite nice so you could use the I variable inside delayed loops. Something like DEL.L x y z. X being time, y = loop-start, z = loop-end.

2 Likes
#468

Wanted to bounce the idea of an ISQRT operator here. I figure SQRT is no bueno because TT is int only.

The c implementation seems small and light enough: http://www.codecodex.com/wiki/Calculate_an_integer_square_root#C

The use case I was thinking of was writing an envelope follower of the IN jack. stuffing the values in an appropriately size stack then RMS’ing the values should do the trick eh? Is this crazy? Should I not be doing something like this on the TT?

#469

I’m a happy user of the teletype, I bought a second-hand TXi and TXo today, so I was checking the manual on those. I saw TXi has a great OP “TI.IN.MAP x y z”

Wouldn’t that be a really nice thing to add to FB as well? Would save a line of code in many cases…
“FB.MAP x y z”

(I did a search for this on the forum, did not find anything, apologies if this has already been suggested)

3 Likes
#470

The idea here is to use RMS to combine rectification and filtering? You could try just using ABS and a linear moving average to achieve this. I think bigger obstacles are going to be the sample rate (limited by how fast you can run a metro) and that the IN jack is unipolar, so for AC signals you would need to play some offset games if you want to capture the negative part of the waveform. For envelope detection it may be that you can get away with the half-wave rectification you’re getting from IN discarding all negative values, though those zeros pull your average down, and sample rate will probably complicate using this for lots of audio input signals.

libavr32 does have some common fixed-point algorithms available, including sqrt, so such an op would be relatively straightforward to add. Interested in thoughts on other possible musical applications.

This works by sending the channel + lower and upper bounds to TXi, which remembers them and rescales ADC values whenever that channel is read. So doing something equivalent for the faderbank would need either firmware support on the faderbank end or to introduce some more complexity and reserved memory for managing this state on the Teletype side. My understanding is that the FADER op is basically device-agnostic by design to allow using other similar devices that let you poll fader values over I2C, so having a single op is a design choice to avoid introducing more behavior to the faderbank I2C interface. Curious to know what the limitations are of rescaling the fader values on the Teletype side.

1 Like