#189

Meaning no other modules were connected to the bus? Ansible is not wired to pull up the I2C lines, so I would kind of expect this to freeze – the lines are always low, so the bus always looks busy. A backpack, TXb, or Teletype, or just a dirt simple DIY bus board like this one needs to be part of the I2C network to supply power to the bus, but so far it’s seemed totally fine to me to have multiple leaders (Teletype and Ansible) sharing the bus.

1 Like
#190

Ahhh of course, forgot about the backpack deal… & I thought I was doing it right to remove all other variables :upside_down_face:

#191

Thank you for all of the Ansible love! It is awesome, awesome, awesome. And yet somehow, it still continues to be awesome in spite of that.

I took the latest beta for a quick spin. Testing with ER-301 as a follower - did 3 tracks. Couple of things I noticed (may well be user error at this point).

The global octave shifts in the follower config - the ER-301 seemed to still be transposed up a bit even though I had the leftmost button selected. Choosing a button further to the right shifted it up by add’l octaves, but I could never get it down to it’s base frequency.

There seemed to be a little bit of weirdness on the duration page. Really long durations seemed to somehow fire double triggers? Not sure if this is i2c related. Will try to test it with a patch cable.

To the right of the mutes on the follower configuration - I have no idea what to make of it. I was scared to touch it. :slight_smile:

Again, thanks so much for the time and effort on this. Great additions to an already excellent firmware. I’m sure I’ll find uses for all the new features.

3 Likes
#192

Thanks so much for beta testing!

Oops, this calculation was wrong. Fixed in the top post (664a192), along with playhead highlighting on the probability view from the Kria feature request thread.

Super weird, did you get a chance to test this out without Ansible involved? And do you recall if anything else was going on with I2C?

Yeah, mainly I wanted there to be a way to reassign follower addresses if you have a bunch of stuff on the bus, and while I was at it thought you should be able to send other stuff (say, TO.OSC.WAVE i x messages instead of the default TO.CV i x). It’s probably a little too easy to bump it and break stuff as-is, if I ever get started on writing a preset customization browser app I would probably just put some decent interface for it there. Also using an entire column of a 128 as bit toggles for a whole byte just delights me, though I’m realizing while typing this that I2C addresses are only 7 bits.

1 Like
#193

Yay! Thanks so much. That was fast! :slight_smile:

#194

Awesome, thank you very much! The playhead highlighting will be a great feature.

I just had another go, and I think I see what’s happening. The duration page is doing what’s expected with CV - producing a longer gate as you pull down the vertical slider corresponding to that step, or increase the horizontal master slider at the top for all notes.

Over i2c to the ER-301 SC.TR units, I think it is calculating the gate length correctly. But instead of actually increasing the gate length, it appears to be sending a short trigger at gate on, and another short trigger at gate off. When the gate length is very short, they are likely so close together that it’s not really noticeable (don’t hear a separate note as long as there’s an EG). As you increase the gate length, a trigger at the beginning and end of what was intended to be one continuous gate results in hearing it fire twice (two short notes where one long one is expected.)

Hopefully that makes sense. In front end teletype op speak, I guess setting the duration would be the same as sending SC.TR.TIME x y. I don’t know what that looks like in i2c code. But it doesn’t seem to be doing that, maybe?

Note this testing is still on the beta version prior to 664a192; I haven’t grabbed that one yet.

#195

Oh, gosh, jeepers, heck, this is exactly right – I was sending SC.TR.P messages instead of SC.TR to set the gate state. Should be fixed in 78d49d8. Are the slew controls working okay with the Kria glide settings?

1 Like
#196

That was fast! Thanks! :slight_smile:

I’m going to give a longer answer than yes or no.

They are working. The slew doesn’t sound identical to what would be produced on the CV out. This is the same thing that happens with Teletype CV vs i2c to SC.CV unit. The actual slew time between notes is (typically) less with the i2c variant. It’s fresh in my mind right now because it’s a recent topic on the O|D forum.

Per Brian of O|D: “The slew time on the ER-301 determines how long it takes to make a full-scale change (0 to 1, or in volts, 0V to 10V)”

So I think both Teletype and Ansible are doing constant time portamento over CV. When the slew rate is set on the ER-301 Unit with SC.CV.SLEW, I think it is setting a constant rate portamento. So the smaller the distance between the current and previous note, the less the perceived slew amount.

I just tested and while adding slew with i2c is working, it does not sound the same as if you are driving pitch with a patch cable. Same is true of Teletype.

1 Like
#197

Oh interesting! SC.CV.SLEW just passes through the value passed to it onto the I2C bus, which in analogy with CV.SLEW I would guess is supposed to set slew time in milliseconds between the current CV output and the target CV value when setting CV i x. I’m not sure how this would translate to the way ER-301 is processing these commands, since I think it would have to rescale the slew value with every CV change to get the same behavior as from CV.SLEW. I’ll have to snoop around some of the discussion on the O|D forum, sadly I have no experience with the ER-301 beyond eyeing them covetously.

#198

fwiw, i concur:

(when you set a new value, an update step size is calculated based on the current value, such that the new value will be reached in the time specified by the “slew” parameter.)

so the word “slew” is potentially misleading since it would tend to imply a fixed slope. (of course we use it in an even more misleading way on aleph and norns, referring to 1-pole smoothing… oh well)

2 Likes
#199

Suddenly I feel the need for a CV.PORTAMENTO Teletype alias.

3 Likes
#200

My two cents - there are use cases for both flavors of portamento, but constant time portamento would probably be preferable to constant rate portamento in kria, if it’s possible, because:

  • it mirrors what happens when you control pitch with CV, so it is kind of what you’d expect
  • for small semitone intervals, even the max glide/slew setting doesn’t produce a very satisfying amount of portamento - in fact you might not even hear it
  • you don’t really have the flexibility to change it without altering the firmware

For Teletype, I think you can have the best of both worlds because you could script the constant time flavor. I haven’t tested this but something like:

// assume X is desired portamento time in msec
// assume current tracker contains notes in semitones N
J K; K P.NEXT
SC.CV.SLEW * X / 120 ABS - J K 
SC.CV 1 N K; SC.TR.P 1

The caveat here though is I’m not sure the max value you can send to SC.CV.SLEW is. If it’s 32768 then the largest portamento time you could get transitioning by 1 semitone would be 273 msec, which might be less than your target time X.

I hope that one finds its way into your case. I have a feeling you’d quite enjoy it!

#201

what would the correct terminology be rather than slew? about to make the same mistake in crow, so best correct it earlier

#202

I still would love to have a slew setting that is bound to the clock speed. The last time I tried it with the new firmware I felt a bit disappointed that the range is somehow moving between, short, quite short and very short.

How about a percentage of step length?

#203

I really like the current way Teletype is implemented and I don’t see much use for the constant rate portamento as implemented on the 301.

Other than slew, quite a few places refer to it as slide or glide. I personally think slew is just a good.

#204

Which step length did you have in mind? Maybe the master clock period? Or it’s probably possible to calculate the interval between two trigger steps, accounting for time divisions and so on, but then the slew value would need to be re-calculated a couple other places, like when the division changes or a new clock rate is latched.

Probably the easiest to implement idea from the Kria features thread is to give up the top row of the glide page and use it as a time divider for the glide length, in analogy to the top row on the duration page. Any change to how glide duration is determined also needs to consider how backwards-compatibility is achieved for glide values in existing presets.

The SC.CV.SLEW issue is a tricky one. I think it might work to calculate the slew rate in the scale the ER-301 expects and send that before every CV update, but this of course would considerably increase the amount of I2C traffic involved. I don’t really see another way to achieve this behavior from the Teletype/Ansible side and am not familiar enough with the ER-301 to guess what would be involved in implementing it over there. Is it straightforward to implement the desired portamento behavior entirely in ER-301 “userland”? That is, how would you do this if you were patching a sequencer with no portamento control into the ER-301’s CV inputs? It sounded like basically the current implementation for handling SC.CV.SLEW basically just puts another processing block (unit?) in the signal path (chain?) compared to SC.CV, but since the desired behavior depends on the target CV value I’m not sure if that’s more involved.

#205

so i think the problem with “slew” is that it could mean “slew time” or “slew rate” which have different units.

@zebra was smart with softcut and explicitly made parameters say “slew time” whereas in Teletype it’s just “slew” so ambiguous (it’s actually slew time, not rate).

1 Like
#206

[pedantry]

well, AFAIK, in a technical sense, “slew” always means “slew rate” in EE and mechanics and specifically means the slope of something: change per unit of time; e.g. it’s a standard specification for opamps. (you do see “slew time” used occasionally but it is just the reciprocal of slew rate; viz., also defined between fixed reference points.)

in synthesis world it has become common to say “log slew,” so i don’t feel too bad about using it in aleph / norns to mean convergence time of one-pole smoothing filter, even though technically of course this shape doesn’t have a constant slope at all.

AFAIK there isn’t a scientfic standard term for what is implemented in libavr32, which is a linear ramp between values with specified time and with slope dependent on the distance between values. but in a musical / synthesis context, for a short word that indicates the right concept, i might suggest glide time or just glide. since this has no technical meaning you should be safe from EE pedants.

2 Likes
#207

If you wanted to build a patch to take an incoming, quantized CV note sequence and apply a constant time portamento to it, I think it could be done in the UI or Middle layer. The builtin slew unit, like SC.CV, is a constant rate slew.

The targets (e.g. a pitch control) don’t really have a self awareness of their current value. So I think a patch would have to involve at least one sample and hold (to keep track of the current value), an inverting VCA and either a mixer or offset unit to subtract the incoming value from the current one, a rectifier to get the absolute value of that, another VCA to set up the gain structure for the slew rate, and probably a couple of microdelays to make sure the slew gets set before the pitch change. It would be an interesting experiment.

While I think you could build this for an internally generated signal or incoming external CV, I don’t think there’s currently a way for an end user to build this inside of an SC.CV unit other than asking O|D to add that feature to it. An end user can’t really get in between that i2c message and the slew behavior of the unit. As i think about it, I’m not even sure it would make sense to do that. So you are probably right that

I think that might be the only sensible way - if it’s worth doing. The alternative, I suppose is to use CV instead of i2c if you need a constant time portamento.

#208

Good question - I think, as a CV value gets updated with an active trigger, the actual devision of the trigger step length would make sense to me.

I usually don‘t use the gate length page very often, but the downside of this implemenatation would be that you could not have short and long slew times for the same sequence - unless the per step values are chosen from a wide range and the fine tune is than done with the main slider in the top row. But I guess how the gate length page was implemented derived from the same problem of fitting it to different speeds.

1 Like