Open Wavetable standard idea.

[trynsta]

Is your feature request related to a problem? Please describe! I think it might be useful to implement some kind of standardization for WT. I described my idea below.

Describe the solution you'd like:

I’ve got an idea for a portable format which could store wavetables. It should be an open standard with his own git repository with documentation. This standard should be under license which allows using it also in proprietary software (MIT? Creative Commons Zero?).

Pros:

• Wavetables will be portable between different synthesizers/programs.
• WT could be easily copied and pasted in various synths/WT editors.
• It will be a workaround for Surge's current lack of a MSEG-like WT editor.
• Wav could be converted into an editable wavetable and we would be able to extract a specific frame.
• We could create scripts with various operations on wavefroms e.g. distortions, filters or randomizers. Even a specific file format could be invented for these scripts. Surge might apply these scripts non-destructively (just like a layer in photoshop).

Cons/ issues:

• I think different synths support different "amount of frames" (Vital has from 0 to 256). Maybe there should be an option to specify this as JSON name/value (eg.: { "frame_rate": 256 })

How it could look in JSON:

{
    "global_wavetable_phase": 0,
    "FFTs": {
        "FFT_1": {
            "fft_number": 1,
            "fft_value": 20,
            "fft_phase": 180
            },
        "FFT_2": {
            "fft_number": 4,
            "fft_value": 20,
            "fft_phase": 180
        }
    }
}

Description:

• global_wavetable_phase - global wavetable phase (dc) offset. Maybe there should be also a phase offset for a single frame?
• FFT{nr} - FFT counter
• fft_number - FFT harmonic value
• fft_value - "volume"/ amount of this FFT. (here: number from 0 to 100)
• fft_phase - phase value <-180; 180>

To reduce file space we can use JSON arrays (first value is fft_number, then fft_value and fft_phase):

{
    "Global_phase": 0,
    "FFTs": {
            "FFT_1": [1, 20, 180],
            "FFT_2": [4, 20, 180]
        }
    }
}

---

That was an example of a single-frame wavetable. This format should be able to store multiple wavetables with various interpolation types between them. This standard should contain at least all interpolation types from the Vital synthesizer. There also should be at least two types of wavetables: FFT based (just like "Wave source" in Vital) and those indicated by points and curves between them (like "Line source" in Vital). Example:

{
    "Wavetables": {
        "Wavetable_1": {
            "Wavetable_type": "FFT",
            "Interpolation_type": "Spectral blend",
            "Interpolation_value": null,
            "Keyframe_x_position": 0,
            "FFTs": {
                    "FFT_1": [1, 20, 180],
                    "FFT_2": [4, 20, 180]
                },
        },
        "Wavetable_2": {
            "Wavetable_type": "FFT",
            "Interpolation_type": "Exponential",
            "Interpolation_value": -0.4,
            "Keyframe_x_position": 0.3,
            "FFTs": {
                    "FFT_1": [1, 20, 180],
                    "FFT_2": [4, 20, 180]
                },
        },
        "Wavetable_3": {
            "Wavetable_type": "Line source",
            "Keyframe_x_position": 1.0,
            "grid_scale": [5, 5],
            "Points": {
                "Point_1": {
                    "point_nr": 1,
                    "position_x": 1,
                    "position_y": 3,
                    "curve_type": "linear",
                    "curve_type_value": null
                },
                "Point_2": {
                    "point_nr": 2,
                    "position_x": 3,
                    "position_y": 5,
                    "curve_type": "linear",
                    "curve_type_value": null
                },
                "Point_3": {
                    "point_nr": 3,
                    "position_x": 3,
                    "position_y": 1,
                    "curve_type": "linear",
                    "curve_type_value": null
                },
                "Point_4": {
                    "point_nr": 4,
                    "position_x": 5,
                    "position_y": 3,
                    "curve_type": null,
                    "curve_type_value": null
                }
            }
        }
    }
}

• "Wavetable_type" is a JSON name which gets one of two values: "FFT" or "Line source" (or maybe more eg.: "wav source").
• "FFT" means that a wavetable is defined by FFT cycles, values and phases.
• "Line source" means that a wavetable is defined by a position of points and curves between them. In the example above, "Wavetable_3" is a saw wave.

If the value of "Wavetable_type" is "Line source," then:

• "grid_scale" [x_value, y_value] - (see Vital's "Line source")
• "point_nr" - number of point.
• "position_x" - x position of the point on the grid. For example { "position_x": 2 } means that it's the second place on x axis on "grid_scale".
• "position_y" - y position of the point on the grid. It might be counted from bottom or from the center (eg. if { "grid_scale": [5,2] } then "position_y" is a value betweeen -2 and 2)

• "curve_type" - interpolation type between this and the next point (eg. "linear", "exponential" etc.).

• "curve_type_value" – the amount of curvature.

• "Interpolation_type" – specifies the interpolation type between the current and the next keyframe.

• "Keyframe_x_position" - specifies a position of a keyframe on the timeline. (Maybe values between 0 and 256?)

• "Interpolation_value" – the amount of curvature.

Other parameters which might be useful:

• "Normalize_table" - normalize the whole wavetable. (boolean value)
• "Normalize_table_single" - normalize a single frame. (boolean value)
• "Remove_dc" - remove dc offset from all frames.

I think that even if Surge currently doesn't support all functions mentioned above, this standard should have a wide variety of parameters so that it supports a wide range of software. Also, if Surge gets one of these futures, we don't need to change the specification.

[mkruselj]

I think majority of the wavetable world seems to have taken the Serum method as de-facto standard, more or less. The other end is u-he's UHM format, but this one has some closed source bits (certain interpolation algos etc).

My personal opinion is that this is a lot of work, I'm not sure if we really want to maintain this, it's not really a standard if we don't get anyone else on board (and why would Serum, Vital, u-he etc. do this when they already did the work their own way?). And xkcd 927...

[trynsta]

Yeah I am not sure if other plugins would adopt it but anyways including some type of WT in text format would make WT in Surge more flexible.

[baconpaul]

We had a draft and partly coded lua wavetable generator we never finished - I kinda concluded we would need too much dsp code to make it useful

I think the project you are suggesting - which is a good but ambitious one - is a little dsl to control an engine which renders frames. That as a standalone c++ library could then be included in surge but also in python and others. But it’s a big project!