Skip to content

Instantly share code, notes, and snippets.

What would you like to do?
API design for SonicPi granular synth

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.


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 -

{: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!

This comment has been minimized.

Copy link
Owner Author

xavriley commented Aug 14, 2014

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.


This comment has been minimized.

Copy link

samaaron commented Aug 14, 2014

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...

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
You can’t perform that action at this time.