DX (Demand XFade) ugens are built upon DemandEnvGen and PanAz and can hence use their dynamic control options. Their user interface and underlying ugen structure is almost identical, due to multichannel expansion they are capable of triggering complex signal flows. As demand rate sequencing can be performed fast, DX ugens can, beneath their functionality as signal distribution controllers in the medium or large time-scale, be used as genuin synthesis tools in the area of microsound, e.g. for fast switching between sources as well as different processings of them. DXEnvFan and DXEnvFanOut give specific options as they can be used as multichannel envelopes and triggers at the same time. This e.g. enables server-side granulation techniques for arbitrary sound sources that are difficult to handle with granulation ugens alone, such es effect sequencing per grain and others. A related application, not necessarily in a granular time-scale, is crossfaded playback from different buffer positions. Finally DX fanning ugens allow server-side definition of spatial movements by crossfading between non-adjacent channels respectively buses.
NOTE: As interface and conventions of DX ugens are nearly identical, I didn't double examples for all features. It's recommended to start with the DX suite overview and go through the help file examples in this order:
DXMix -
DXMixIn -
DXEnvFan -
DXEnvFanOut -
DXFan -
DXFanOut. Some general conventions are treated in detail in the following examples: fades and steps in
DXMix, Ex.2 – width and offset arguments in
DXMix, Ex.3 – multichannel expansion in
DXMix, Ex.6 – crossfade types in
DXEnvFan, Ex.1.
NOTE: PanAz.ar's args pos and orientation were scaled wrongly in SC versions up to 3.8. DX ugens neutralize this bug by inverse scaling, so it should actually work the same with SC versions before 3.9 with the exception of examples with modulatable width (disabled in earlier versions). I didn't encounter differences in any other test examples, however I'd rather recommend a SC version from 3.9 onwards, if you have the choice.
NOTE: Depending on the multichannel sizes it might be necessary to increase server resources, i.e. the number of interconnect buffers (e.g. s.options.numWireBufs = 256; s.reboot). See
DXMix, Ex.8 and
DXEnvFan, Ex.2,
DXEnvFan, Ex.4 for aspects of CPU demand.
NOTE: In my tests timing was exact up to one sample. So when used for granulation DX ugens avoid the inevitable inccuracies of language-based triggering in realtime. However care has to be taken: fade and step times must be larger than the duration of a control cycle. With default values sampleRate = 44100 Hz and blockSize = 64, this equals ca. 0.00145 sec. If you go below, the fade mechanism is messed up and you get jumps and clicks. Accordingly with fadeModes 3 and 4 you have to ensure that the remaining 'real' stepTime, which is calculated by stepTime minus fadeTime, is larger than this threshold. But as a workaround you can always lower the blocksize. See
DXFan, Ex.4 for aspects of granulation with high trigger rates / short grain durations.
NOTE: The current implementation is bound to counting with Dseries and – inherent to 32 bit floats – the integer accuracy limit of 2 ** 24 - 1 = 16777215. This can be an issue with setups that are using extreme short durations for hours.
Thanks to Wouter Snoei for his PlayBufCF class. It gave me a lot of inspiration for DX ugens – although in the end the implementation with PanAz and DemandEnvGen is quite different. Thanks also to Till Bovermann for ironing out a longstanding bug in PanAz.
Extension