I was recently comparing the sound of my Venom XM-OP (using phase modulation) to the Bogaudio FM-OP.
The XM-OP envelope has a curve control that can produce concave down rise and concave up fall, which is typical of many envelope generators.
The FM-OP has an exponential option instead that causes both the rise and fall to be concave up. In the modular world I think this is most often done with VCAs, not typically with envelope generators themselves.
I have come to the conclusion that the exponential response is very satisfying in the FM-OP, and I cannot directly get that sound with the XM-OP.
I would like to enhance the XM-OP to make the exponential response available. I can think of a few ways to do it.
- Add an “Exponential envelope” module context menu option that directly controls the envelope shape. The exponential shape would be applied after the curve computation. Setting the curve to linear and enabling the exponential option should give results very similar to the FM-OP.
- Variant 1A would be to add a tiny EXP button somewhere in the upper envelope region of the faceplate instead of adding a context menu option.
- Slightly modify option 1 to “Exponential envelope response” that would apply to the Level VCA, XM Depth, and Feedback Depth, but not the envelope output.
- Slightly modify option 2 to “Exponential level response” that would only apply to the Level VCA, but not the XM depth, Feedback depth, or envelope output.
- Expand the options in the ENV tiny buttons above Level, Depth, and Fdbk. Every existing option except Off would have an exponential response variant. I love this flexibility, but I don’t like having so many options. That seems like too many on general principal, and also I think I might run out of easily distinguishable colors - I would need 13!
- Double the number of tiny buttons above Level, Depth, and Fdbk. The existing buttons would stay as they are now, and the 2nd button would apply an exponential response if enabled. I think I can fit in the 2nd button (total of six envelope buttons instead of the current three)
I think my favorite option from a functionality standpoint is option 5. It is probably the most involved from a development standpoint.
A close second from a functionality standpoint is option 1, which would be trivial to implement. Variant 1A would be a bit more to implement, but more convenient to use.
I also like options 2 and 3 since they are trivial to implement. From a functionality standpoint I think they are very close to option 1.
I think I can rule out option 4.
What do others think?
It will probably be a couple months before anything is implemented, perhaps longer before it hits the library.