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

The idea here is to use RMS to combine rectification and filtering?

I was taught in school that the RMS of an AC signal will roughly translate to it’s DC value. The intent is to have a CV that roughly tracks an audio signal’s amplitude linearly(or not).

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.

You are right this is definitely a non-optimal solution/use case. The sample rate was something I thought about, hence the “appropriately” size buffer/stack would be pretty important and probably laughably small or you’ll blow your “frame budget” with the RMS arithmetic.

Interested in thoughts on other possible musical applications.

My personal musical application is using the CV signal to control the feedback on a delay. Delay fb signal gets bigger … close a VCA down with an inverted env follower to keep it from oscillating. I’ve been using a “normal” env follower for this but I wanted to see if building an env follower with the TT was even possible, and honestly… the quirkier the env follower the better so I was on board with possible sample rate “steps” showing up in the signal.

I thought about having the “quirky” env follower CV signal as the trigger input on a T&H circuit or having it be the noise source of a T&H. that way the values output have a relationship with the audio signal.

including sqrt, so such an op would be relatively straightforward to add.

right. I figured this wouldn’t be a huge lift at all and wouldn’t have huge impact on the size either. It’d mostly just be a passthrough and also fill out the Maths Ops some more.

#472

You’d still lose out on the IN being unipolar for this though correct? However that would work pretty well if we didn’t drop the negative values coming into the jack.

#473

I’ve just been experimenting with multi-Scene Teletype programs using

SCENE.G x; $ 10

to load a Scene and run its INIT script.

This works fine - and I can use the Grid to pass values between Scenes by encoding them into the Grid state. However, it got me thinking that it would be extremely useful to have a similar op SCENE.P, which would load a Scene without changing the existing Pattern contents. Is this even a possibility with a firmware change?

1 Like
#474

this seems like a useful suggestion - having different scenes being able to work with the same data set could open some interesting possibilities.

the question is - how to combine the 2. what if you want to load a scene while preserving both the grid state and the pattern data? this becomes even more complex if we want to support loading a scene while preserving current variable values.

1 Like
#475

I suppose the simplest solution would be:
SCENE - loads Scene with nothing preserved.
SCENE.G - loads Scene with Grid, Patterns, Variables preserved. (Or some other suffix). If Variables or Pattern values are defined in the Scene being loaded, they would write over those being passed - so it shouldn’t affect a Scene that is not meant to be loaded this way - or am I missing something?

#476

@polycorn I added FADER.SCALE x y z, FADER.CAL.MIN x, FADER.CAL.MAX x and equivalent FB aliases. Essentially mimics the behavior of the same OPs for PARAM and IN.

My PR was merged so should be in v3.2 when it’s released: https://github.com/monome/teletype/pull/198

6 Likes
#477

this will happen regardless of how you load a scene. the SCENE.# variations are just to bypass loading grid state or pattern data from flash.

what i meant was - sometimes you want to load a scene without initializing grid data, so you use SCENE.G. sometimes you want pattern data to be preserved, so you use SCENE.P. what if you want both to be preserved? then we either need SCENE.GP or SCENE.PG op or some new op where you can specify what to initialize.

maybe something like:

SCENE.# scene var pattern grid

where var, pattern and grid parameters are set to 1 if you want to initialize them, 0 otherwise.

2 Likes
#478

Awesome! That will save me a precious line here and there! Thank you (all?) so much for working on this thing. Cheers! Poly

1 Like