DX operator, envelope and keyboard tracker
  • I've been working my way through the excellent services of videos on the DX7 that @RobertSyrett posted and though I would put together a DX7 operator. I think this has everything needed. Along the way I created a keyboard tracking module, and a DX7 style envelope generator. Like the original, the operator features a 4 stage constant rate envelope, variable keyboard envelope level tracking (linear and exponential) with an adjustable break and slopes, keyboard rate tracking (linear), coarse and fine frequency ratio, detune and output level. It also has an external feedback input with level adjust, and 3 summed phase modulation inputs.
    The keyboard tracker will scale an input from 1.5 to 0.5 across 8 octaves. The curves above and below the break note can be adjusted for slope and switched from linear to exponential.
    There are two versions of the envelope. One with the keyboard level and rate scaling and one without. Both versions are rate based, not time based. The knob with the clock adjusts the rate for the step so that a higher value is a faster rate. The keyboard rate scaling slows the envelope rates toward the lower octaves and varies from none to 0.5 depending on the setting of the knob. There is an internal trimmer if you wish to adjust the maximum slowdown.
    I've included a demo with 4 operators arranged in two towers. The second modulator has it's output patched for feedback. I made the feedback input external so that you could have more than one modulator in the loop. The feedback input has a unit delay on the input to prevent an automatic one frame feedback delay.
    Screen Shot 2018-04-08 at 4.31.54 PM.png
    2448 x 1966 - 840K
    Screen Shot 2018-04-08 at 4.32.25 PM.png
    2782 x 2110 - 761K
    DXop Demo.audulus
    754K
  • Just for grins I thought I would try a four operator patch with the keyboard set for 16 voice polyphony. It ran on my Mac, but just barely (90% CPU). Eight voice is more manageable at about 50%. I doubt polyphony will be practical on the iPad. I tried to make the operator as efficient as I could, but there are a lot of expression nodes. I may be able to trim some additional fat, but it may have to wait for a more efficient expression.
  • Wonderful! I'm looking forward to making some patches with this!
  • Just few questions:

    1) Why cos instead of sin?

    2) Why multiply the incoming phase modulation value by 2*pi? I've found this over modulates the signal more than the respective DX7 patches.
  • Forgot to mention that the gate is velocity sensitive, so envelope values are proportional to gate height. The DX7 operators have an adjustment for velocity sensitivity, but the UI was already getting pretty busy so I decided that it could be done externally if desired. The same is true of the sync function. I originally had it switched internally but decided to just bring it out as an input to save space. The keyboard envelope level scaling slope dials adjust the left and right ends of the slope with the center of the slope (break note) being at 1 to 1. Halfway on the dial is no slope (no scaling). Rate scaling is disabled with the rate scale knob at 0. Halfway on the detune dial is no detune. The light above the value display is lit when there is no detune.

    10:55 04-08-18 Modified fine ratio dial to quantize at 100ths instead of continuous (to make ratio setting more precise)
    DXop and DXvelope V1.1.audulus
    211K
  • one more question: There seems to be a rate associated with the keyboard scaling, were you able to sort what that was about?
  • Ok, so I mucked about with another DX7 patch, this one was called "violin 3." It sounds reasonably close to the original patch, although some ignoring of what i was reading and using my ears was involved in fine tuning the parameters once the values were dialed in.

    I think the double ratio interface could use a little refining. I was reading the DX7 manual and it indicated that "course" was integers or division of powers of two, "fine" was .0-.99, and "detune" was equivalent to superfine ratio adjustments but didn't specify the degree of resolution. Not that you have to live by the DX7 manual or anything. I would suggest that if you keep the current system where the fine ratio multiplies the course ratio the final product should be displayed somewhere.

    All in all, I'm kind of perplexed as to why this uses so much CPU but very happy with the sound. Thanks again!
    DXop violin 3.audulus
    540K
  • @RobertSyrett, rereading the DX7 manual, I believe you're right about the fine frequency control. The manual copy I have states "FINE adjustment is possible over a range of from 1 to 1.99 times". I took that to mean an additional multiplication, but your interpretation makes much more sense. Since the detune range is unspecified, I arbitrarily made it +/- one semitone. If I read it correctly there are two types of keyboard scaling. The first adjusts the level of the envelope based on the note value in relation to the "break" note and the slope and type (linear or exponential) of the curve at that point. I chose to make the values at either end (+/- 4 octaves from the break) from 0.5 to 1.5 times the unmodified envelope. The second type of scaling adjusts the overall rate for the envelope generator based on the note, with lower note values resulting in a slower rate (or longer envelope duration)
    I made the Coarse and Fine controls additive and quantized the Detune at 100ths. I also updated the demo file.

    I'm working on trying to reduce the CPU load, hopefully without reducing funtionality. In the interim I'm going to make a version without the keyboard tracking to see how much reduction that will give me.
    DXop Demo V1.2.audulus
    754K
    DXop and DXvelope V1.2.audulus
    209K
  • @stschoen It's really interesting to see the parameters that the DX7 engineers thought were of utmost importance. I can't say as I would have thought having so much flexibility in scaling parameters to the pitch would have been important (these do seem to be missing in FM synths not looking to be DX7 patch compatible), but It makes me think there must be cases of modeling specific instruments that it facilitates.

    I think I might need to spend some more time with the keyboard scaling to figure out how to best use it.

    I really love your front panel, by the way, very nicely balanced!
  • I agree regarding the over-the-top keyboard scaling. I suspect that it allows fine tuning of the modulator level so that the harmonic balance changes as pitch varies, but I confess that I'm also somewhat at a loss. Still, I thought I better include it just in case. I can see more utility in the rate scaling for percussive instruments like a piano where you want the decay to be slower on the lower notes. Thanks for the compliment, I was trying to keep the UI as small as practical without sacrificing clarity.
  • Here's a version without the keyboard tracking. It's about 30% less CPU if you don't need the tracking.
    Screen Shot 2018-04-10 at 12.26.55 PM.png
    1510 x 2326 - 566K
    DXop Lite V1.2.audulus
    515K
  • Here is a patch with the DXop lite, this time I was exploring algorithm 16 trying to create the impression of a modulate resonance. Please feel free to play with a keyboard as well, like a lot of these DX7 inspired patches the fun is hearing them as pads.

    Being able to arrange the operators like the diagram does help out a bit with the translation of the concepts from DX7 quite a bit.

    CPU is still pretty high but much improved. I will reconstruct this patch in the algo block later tonight for a comparison.
    Screen Shot 2018-04-10 at 8.18.29 PM.png
    882 x 596 - 120K
    Screen Shot 2018-04-10 at 8.18.43 PM.png
    1436 x 1030 - 432K
    DXop lite Phase Pulse.audulus
    767K
  • Well I recreated the patch using the algo block module, but this time I couldn't use stock ADSRs for the envelopes since 4 out of 6 use an envelope that decays and then swells again (a specialty of the DX7) so I used the DXvelope and it had almost the same exact CPU usage as the DXop version.

    I looked inside the DXvelope to see if there were any approximations and it looks pretty trim! The only thing I noticed is there isn't a light meter on step 2 pf the envelope indicating it is active. So we might be approaching the point at which expressions need to be more efficient before greater CPU reduction occurs or seek out alternative designs without expressions.
    Algo Block Phase Pulse.audulus
    717K
  • Oops, must have accidentally deleted the light. I'm still working on some different approaches to the envelope to see if I can improve it's CPU usage, but so far I haven't come up with anything that make a significant improvement. Here's one with all the lights
    DXvelope V1.1.audulus
    29K
  • It's interesting that since the last Mac update, exchanging expressions for multiply and add nodes no longer seems to increase the CPU efficiency at least on the Mac. I know Taylor made some changes that were intended to improve CPU usage. I have tried a number of different approaches to lowering the CPU usage for the envelope since I think that would make the most difference, but so far everything I've done has only served to make it worse. One peculiar thing I've noticed is if I copy and paste the envelope module and waveform meter, the copy consistently uses more CPU than the original. Weird :). It may be as good as it gets, at least until the next update.
  • What I think is weird is that when I went to put an rgb light on the DXvelope output it quintuples the CPU usage when not connected to anything.
    Screen Shot 2018-04-14 at 10.10.32 PM.png
    135 x 348 - 13K
    Screen Shot 2018-04-14 at 10.11.11 PM.png
    278 x 656 - 37K