#2

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.
#3

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

#4

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

Next question: what allocation mode is the Ansible in?

#5

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.

#6

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).

#7

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

#8

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

that makes sense, thanks for the clarification!

#10

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

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.

#12

@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
#13

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

#14

…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:

#15

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:

#16

Thanks for trying, @Jonny

#17

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.

#18

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.

#19

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

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.

#21

Okay, right. Thanks for the explanation.

Question: Does connecting any MIDI device then default to the MIDI application? That is, am I correct in assuming that Ansible does not differentiate between different MIDI devices? Just three options: Grid, Arc, MIDI.

I ask because if the user connects a keyboard with no knobs, then they’d be hard pressed to output any CCs.

But I’m assuming that it’s just Grid, Arc, MIDI, and so the user could connect a device with knobs, configure the MIDI settings and then connect a keyboard without knobs and be ready to rock.

In that case, CC sounds great. I’m no MIDI expert, but perhaps one of these groups of ‘undefined CCs’ could be a good start:

  • 20-31
  • 85-90
  • 102-119

How many might be required to get the job done? I could imagine just one CC for note to CV offset, but it sounds like you have a few more config params up your sleeve.

I wonder if the way Os organizes CCs in Expert Sleepers FH-1 might be helpful. But that chart doesn’t tell the entire story. In the manual you can see that he has some other fancy things happening with high-resolution CCs (that share data between pairs of CCs, I think) along with arpeggiator control and other stuff. Long story short, it looks like all CCs are used somehow, somewhere.