Software Overview: Max for Cats' Bengal


    While not the most recent release by Max for Cats, Bengal is one of the most intriguing synths available in the Live environment. It extends the patching metaphor that exists in other Max for Cats' releases, but situates it within the context of FM synthesis. How does that work? Well, it takes the common paradigms of FM synthesis (standard generator routings, dedicated modulations and limited extensibility) and flips them, giving the user the freedom to patch as necessary. You still get helpful preset functionality, but you are free to experiment wildly with modulation functions and signal re-routing in a way that was impossible on Your Father’s DX7.
    At a very basic level, Bengal is quite similar to the Operator FM synth: 4 operator, dual filtered and utility-packed, this is an FM synth that will feel familiar if you’ve worked with Operator, a DX-100 or a Reface DX. But each section of the synth takes the basic ideas from its predecessors and refines them in a way that is a sound designer’s dream. The Oscillators are a good example: all the basic controls are there, but you also find a unique user-drawn harmonics front-end, and a dedicated, loopable ADSR envelope that makes it easy to tweak each generator’s sound. Even the smallest details are perfect; for example, when you change algorithms, little pointers change their position on the oscillator level controls so you know where that generator’s output is headed.
    The pack of utilities provided also make for a highly-detailed and enjoyable experience. Lag, scaling and math processing is built-in, as is a nice X-Y controller. There is also a stack of effects processors, including delay, reverb and chorus effects, and both a ‘Krush’ compressor and end-of-chain limiter to keep the otherwise insane FM klank from bursting your eardrums. But maybe the most effective utility function is the centrally located ‘scope’ module, which provides a clear oscilloscope, phase meter or spectral display to helps you understand what you are doing as you develop a patch.
    And I use the word “patch” seriously, because the key programming element of this device is the semi-modular patch bay dominating the bottom of the editor’s UI.
    Bengal, like Pallas, echoes the kind of semi-modular patching that was common in the mid-70’s with systems like the Arp 2600, Electrocomp 101 or Roland System 100. While the module count is preset, the routing is not - and you get to patch, cross-modulate and process both audio and control signals just like you would with vintage hardware.
    When doing sound design, you often want more feedback than you can get from a menu/knob combination for modulation source/destination selection. This interface is both visual and visceral, and I feel a lot more connected to the patch than with typical interfaces. The presets provided with Bengal are great examples of the sonic landscape that is available, but there is much more available to the savvy sound designer. I found myself cranking out stinging zaps, hollow bells and rolling drones in no time, and the constant availability of the scope meant that I always felt connected (both sonically and visually) to the sound I was creating. Great fun, but also great musical results.
    Bengal has quickly become my first-call synth for both effect-y and clean-FM sounds, but it also has become a playground where I spend my fun time. It’s clean, easy to understand and easy to use for experimentation. The whole package shows a maturity in instrument design that we are coming to expect from Max for Cats, and is worth the time that you will want to give it.

    • Oct 27 2017 | 4:06 pm
      Not to mention innovative use of Max to show the patch cords!
    • Oct 31 2017 | 7:58 pm
      Yeah - I'm really curious how they do that in a runtime context!
    • Oct 31 2017 | 8:24 pm
      I dug into the patch at one point, and figured out how it was done, but it escapes me now - some Javascript wizardy maybe? But it was super slick, that's what I do remember...
    • Oct 31 2017 | 9:54 pm
      There must be a better way...
    • Oct 31 2017 | 10:12 pm
      A better way? I prefer to praise the MfC folks for the way they've found. It's extraordinary.
    • Oct 31 2017 | 11:06 pm
      I meant a better way than the one I posted, I wasn't criticizing their approach ;-) Anyway, here's a better way than my last attempt.
    • Nov 01 2017 | 1:59 pm
      Nice, but these don't allow you to create new patch cord connections between the objects while the patch is locked?
    • Nov 01 2017 | 6:39 pm
      @Dan Nigrin, I think that could be accomplished pretty easily with thispatcher scripting and defining areas that represent which object to connect to. The initial drag could be accomplished by dragging an invisible object (like a ubutton with highlight set to transparent) around with a patch cord attached, then once dropped, a different patch cable attaches to the target object. I tried to use hover object to get the name of the object you're dropping onto, but it doesn't seem to work when the mouse button is held down dragging the invisible object. So you might have to either keep a set of valid 'drop' areas and test against them, or you could iterate the distance formula over your target drop points and see which of them is closest. Maybe there's an even better trick I'm not thinking of, like using getattr or something to get positions of objects and an automated fashion.
    • Nov 01 2017 | 7:26 pm
      Thanks Pedro - here's something I came up with based on your patch, though it still needs some work to become anything useful. You can drag from a source object to connect it to a destination object if it has a scripting name, and click the destination object (if it is a control) to disconnect it from the source object.