Features that would be needed to support an accurate SF2 -> XRNI importer

I’ve been working on my SF2 importer, but it seems I’ve stalled out on account of a number of limitations in Renoise’s XRNI format. It’s so close! What would be needed for an accurate SF2 importer is:

  • Triangle wave LFO modulators - currently the effects LFO supports triangle, but the modulation one does not. Lower priority since the sine doesn’t sound that different, but probably the easiest to implement on this list.
  • Per-note keytracking on a modulator level, without involving any effects chains - something to allow implementing SF2’s keynumToVolEnvDelay and keynumToModEnvDelay. Right now the modulation keytracker is very underpowered, with only a min/max slider and the four operations, which can all be a bit unpredictable.
  • An option for dB-linear volume automation rather than the current volume-linear automation. This can technically be worked around / approximated with the power-curve handles, but it is very inexact.
  • The ability for multiple keyzones to reference the same sample without copying the sample - and for those keyzones to map to different modulation sets. This is huge for SF2, as many popular soundfonts will use a single sample that has different parameters in each zone. Properly importing these kinds of instruments can result in XRNIs that are 50x or 100x the filesize of the original.
  • A pre-delay parameter on AHDSR - this is less used on volume automation as it is on mod / filter automation. SF2 and many other formats (like DLS layer 2) specify a 6-stage envelope - delay, attack, hold, sustain, decay, release.
  • The ability to continue a sample after the loop point on release.

Everything else I think is a question of a bit of math and some modulation plumbing. If there are ways of working around these that I’m not aware of please let me know!

3 Likes