Ansible, midi, OP-1 and Calibration help

Hey all,

So just got an Ansible and plug my OP-1 straight into it and got the pitch output plugged into a Mangrove but I get a really high pitch when playing a C2 note, so something is wrong and I’m wondering if I have to and how to calibrate the Ansible.

have any of you experienced that?

Thanks!

What’s the Mangrove frequency knob at, tho?

Pitch quantisation in Euro can still be affected by a number of factors. E.g.:

  • you push a note on a midi device, e.g. C2
  • Ansible converts that to a known voltage that it believes is C2
  • you pipe that into a VCO where it promptly (usually) gets added to the current setting in the pitch/freq knob
  • and so if the pitch is currently at, say, 4V and you put a 2V signal in, you get a 6V pitch out.

So:

  • when you change the note on your OP-1, does the note on the Mangrove change?
  • If so, you just need to tune the Mangrove (which you always need to do to play in pitch) - play a note you know to be a MIDI C2, and adjust the frequency knob on the Mangrove until you hear C2 - using a guitar tuner or Ableton’s tuner or similar. Then, when you play a C3 on the OP-1, you should hear C3.
  • If, by contrast, you’re just getting high pitches regardless of the freq knob, that possibly requires some other approach.

Thanks that’s exactly my issue if I tuned the mangrove to play a c2 the pitch knob on the mangrove would be nearly fully down and then I I can’t get any lower if let’s say I want to play in the c0 c2 range!

As if the ansible’s output was way higher that what a normal midi C2 would require. Not sure if it makes sense

Yep, that makes sense. Sorry for stating the obvious, then!

Next question: what allocation mode is the Ansible in?

thanks infovore! It is in style 2: mono, it is not a massive let down but I thought that maybe there would be a way to calibrate the ansible but I can’t find anything in the docs about it.

You shouldn’t have to calibrate the Ansibile, I don’t think. It’s more likely that the Mangrove’s volts/octave needs to be calibrated.

When I first got my Ansible and tried MIDI, I had the same problem. I had to switch to the lowest octave that my keyboard could play and then tune my oscillator to a very low note. Then I could octave up through the range and play different notes.

If the lights stay lit the same color/brightness, then something else is wrong - it’s more likely then that your MIDI controller is trying to pull too much power (had a similar thing happen with Earthsea but the latest code fixed it).

Thanks Johny, yes that’s pretty much what I’m doing too, no worries then

The current MIDI pitch mapping on ansible/earthsea is C0 == 0V which results in widest range possible for pitch output. It has been suggested that it would be more convenient if the 0V mark corresponded to a much higher MIDI note (say C2 or C3).

Hitting the down octave button on the OP-1 should help.

Looking forward I’m hoping to allow one to set an offset via teletype and then store it as part of the config. This would allow people to tune the pitch output to their liking (but sacrificing range in the process).

2 Likes

that makes sense, thanks for the clarification!

Just to follow up the next release version of the ansible firmware will have the ability to set the MIDI note to CV offset via teletype and store it as part of the default config.

1 Like

Oh, that’s great. However, without Teletype, is the only other way to alter the MIDI note to CV offset to go into the source code, change it, compile and flash the module? If that’s a yes, then might someone be into offering up a fork with the changes?

It looks like this table is a key player, but I wouldn’t know what to do with it.

@fourhexagons - I think that it would be possible by changing this line:

Just have to figure out the value for C2 or C3 and change the offset? I haven’t done much with the code, but I have the development toolchain set up, so I could give it a shot this week.

1 Like

@Jonny – Jonny B is on it like a hawk! Thank you.

…the pitch_offset value is integral to the pitch bend implementation. There are several places in the code where pitch_offset is manipulated.

The II commands are actually changing an offset value associated with the dac abstraction in libavr32. This is the function which it manipulating that value:

IIRC it assumes a 12bit shift value as computed by the teletype operators such as N and V.

I’d love to give you a quick solution but I’m two beers in at this point so I’d best stay away from code for a bit :wink:

Thanks for the feedback - I tried it and it didn’t seem to have an effect anyways with the default when I plugged my midi keyboard in.

@fourhexagons - looks more complicated than I thought! :sweat_smile:

Thanks for trying, @Jonny

Oh wow, I hadn’t realized who I was asking earlier, @ngwese. I see your contributions now, in fact, I see the other contributors, too. Please excuse my indirect way of asking. I’m new here and apparently bumbling around a bit.

No problem at all.

The thought of implementing a non-teletype way to change some of these lower level configuration parameters did come up. In the end I didn’t identify an implementation (via MIDI) which seem sufficiently general. My fear was that everyone had different controllers with different capabilities with regard to sending sysex or cc values or nrpn values…

Suggestions are always welcome.

Thanks for understanding.

Regarding MIDI implementation, it sounds like you’re talking about actually using MIDI to make the change. That’s cool and I hadn’t even considered such a thing. I would expect that sysex or nrpn are too esoteric, but that MIDI note and CC values would be a better choice as they’re something that nearly every controller can output.

But then again, why not just use the Grid/Arc to make the changes? I say this not really understanding what’s involved in coding such a thing.

As for the reason why an offset for controllers like the OP-1 is preferred, I’ll explain my use case. I like to use the OP-1’s internal sounds with my modular, primarily patched into modules like Clouds and Morphagene. But I also like to patch the OP-1 into a USB to CV converter to be able to control modules in my case either with the keyboard, or using something like the OP-1’s Tombola ‘sequencer’. Because the OP-1 outputs MIDI all the time, I’m able to mix together the sound produced by the OP-1 along with the sound produced by the modular (controlled via MIDI) and it’s just easiest if the octaves match up. Of course, I could always use some sort of precision adder to bring the CV up to match that of the OP-1 audio out, but as it often is with modular, the fewer modules/less hp one needs for a task, the better.

2 Likes

The CC value route probably makes the most sense in the long run and it has the benefit of being the most simple to implement! The biggest question would be picking which CC values control what parameters.

Using the grid/arc to configure the midi mode would be difficult. Ansible’s design (UI design in particular) is to be multi-modal, when a specific USB device is plugged in the module switches to a different application (in a manner of speaking) - there is no awareness of/communication between each application. The midi/arp application is selected by plugging in a usb midi device, the levels/cycles application selected by plugging in an arc, etc. An intuitive UI design which leverages multiple USB devices to configure the MIDI mode(s) would be difficult to achieve since it works against the core switching nature of the module.