API design for SonicPi granular synth

grain_synth_design.md

Thinking about a design for a granular synth in SonicPi.

Proposed name - warp_sample

• based on sample - i.e. takes a symbol or path to sample
• takes a :rate param which is 1 by default. Default behaviour is to play a granulated version of the sample at normal speed
• as rate is reduced (to say 0.5) the sample takes twice as long but because it's a granular synth the pitch will stay the same
• unlike sample, a rate of 0 will just play grains around a :pointer position.

Arguments

sample_name_or_path, :symbol_or_string

Suggested params

from sample

{:rate => 1, :attack => 0, :release => 0.0, :start => 0, :finish => 1, :pan => 0, :pan_slide => 0, :amp => 1, :amp_slide => 0},

from Warp1 Synthdef - https://github.com/overtone/overtone/blob/master/src/overtone/sc/machinery/ugen/metadata/grain.clj#L120

{:name "Warp1"
    :args [
           {:name "freq-scale"
            :default 1
            :doc "the amount of frequency shift. 1.0 is normal, 0.5 is
                  one octave down, 2.0 is one octave up. Negative values
                  play the soundfile backwards." }

           {:name "window-size"
            :default 0.1
            :doc "the size of each grain window."}

           {:name "envbufnum"
            :default -1
            :doc "the buffer number containing a singal to use for the
                  grain envelope. -1 uses a built-in Hanning envelope." }

           {:name "overlaps"
            :default 8
            :doc "the number of overlaping windows."}

           {:name "window-rand-ratio"
            :default 0.0
            :doc "the amount of randomness to the windowing function.
                  Must be between 0 (no randomness) to 1.0 (probably to
                  random actually)"}

           {:name "interp"
            :default 1
            :doc "the interpolation method used for pitchshifting
                  grains. 1 = no interpolation. 2 = linear. 4 = cubic
                  interpolation (more computationally intensive)." }]

Thoughts on the above

• freq-scale could take some sort of semitone/midi number type shift instead of a float ratio
• envbufnum is probably safe to leave out as a param. I can't see a good reason to offer anything other than Hanning here.
• when rate is 0 the sound would in theory carry on forever which is at odds with most of the rest of SonicPi. Not sure what to suggest - perhaps a max\_time\_cutoff param?

In terms of actually using it in SonicPi, I think it would open up a lot of possibilities including

• pitch shifted samples
• sounds and textures of granular synthesis
• building blocks of autotune and similar effects etc.
• lots more that I can't think of!

to clarify a little :rate for warp_sample would mean "the rate at which the pointer moves from the start to the finish" rather than the :rate in the sample method.

Sounds great. I just played around with some prototypes just now. I think this would need a bit more work before I'm happy to put it in Sonic Pi. I'm therefore thinking it should be in v3.0 given the amount of stuff I need to do in the next couple of weeks...