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

Yes, that’s what I was trying to say - it happens regardless. I hadn’t considered that there are initialized states to grid and pattern (ie a Scene assumes all Pattern values are zero). But I think we are on the same page, I’m just not explaining my thinking very well on very little sleep.

I like this solultion, 3 parameters to the alternative SCENE op, Grid Pattern Var set to 0 or 1.

The only problem with that is some folk may be using SCENE.G already? Is it too messy to have SCENE, SCENE.G and SCENE.X 1 1 1 all existing?

(Apologies for not using the code styling, I can’t for the life of me remember how to do it!).

I do hope there is a way it can be introduced. Having a Grid layout from which you can trigger entire Scenes is pretty powerful as is, but if Variables and Pattern data persisted too, I can imagine some very sophisticated setups would be possible!

1 Like
#480

yeah sorry, what i said wasn’t correct - SCENE.G and variations would be to bypass loading grid state or pattern data from flash (not initialize them with default values as i previously said).

i think it makes sense to have different variations of the op, in addition to SCENE.G, particularly SCENE.P being a useful op.

1 Like
#481

No problem - I read it as bypassing initializing grid and bypassing loading the new scene’s pattern data.

I suppose SCENE.G, SCENE.P, SCENE.V, SCENE.GPV, SCENE.GP, SCENE.GV, SCENE.PV would cover all possibilities… Could there be a use-case for passing the Metro state independently? Or any other variable?

The advantage of using SCENE.X Grid Pattern Var would be that you could do something like SCENE.X 1 RND 1 1 to randomly decide whether to keep the current Pattern data or not! :crazy_face:

#482

oh i see what you mean. i would limit it to SCENE.G, SCENE.P, SCENE.V and SCENE.# (might need a better name for this one).

i don’t think metro state/rate is changed when you load a different scene?

1 Like
#483

Ah, where SCENE.# is the op with the three parameters? Perfect!

You’re right. I was trying to think if there was a special variable that one might want to persist without every other variable being passed to the new Scene. An edge-case.

Coming at it from the opposite angle, would it be technically possible to grab some kinds of data from a Scene without loading it? For example, to get the value of PN 0 6 from Scene 14.

#484

yeah, it would be technically possible. i don’t know whether reading/writing individual values is a good idea (as flash does have some limit on number of reads/writes), but loading/saving full pattern banks could be useful.

2 Likes
#485

Hi, I’m feeling a bit lost. Could someone point me in the right direction for the latest teletype beta? The one posted at the top of the page (E27F640) sounds like it’s pre 3.1.0 and I recall reading somewhere that there is a beta that fixes the help screen lines wrapping around and allows triggering of the metro script.
Is there a central database of all the betas by date?

#486

I’ve just added the latest builds to this post, which seemed like the best option for a one-stop-shop. A new Teletype release should be out soon.

No, but the edit history of the above thread can maybe sort of act like this if other firmware devs and I update it.

3 Likes
#487

Thank you for that! Now I can get back to music making :smile:

#488

i’ve also updated the links in the firmware guide to point to the latest release threads.

1 Like
#489

Not many talked about ops for w/, please allow me have some suggestions that I’m not sure that could be possible or not.

Currently there is a WS.REC X for controlling the record behavior, but in absolute manner, -1, 0 & 1. I am wondering if it can be something like WS.THAT X or WS.RECV X while X is a -5 to +5 voltage value to make it like sending a voltage to THAT (or THIS) by an invisible patch cord. Or even a CV.WS (14 bit) op so that it can be integrated most of the Hardware ops to w/.

2 Likes