fixing transposition latency with premade modules

    Apr 15 2012 | 12:08 pm
    My professor created sound modules for the class, which have been helpfull, however the transposition effect on the wav player seems to generate a significant amount of latency between loops. I've searched the topic but am not sure about a solution that would be compatible with the components I am using. My patch is extremely large and somewhat complex at this point and to do it over without his components would take more time than I have left.
    Might anyone have any suggestions on what I can do to lessen or optimally eliminate this latency?
    Here is one player I could use without built in transposition, and below it the other with integrated transposition:
    not integrated:
    I have until Thursday to figure this out, and I am not sure that my professor has the time, so any help would be greatly appreciated!

    • Apr 15 2012 | 12:59 pm
      the not integrated module you are using is based on sfplay~, which reads files directly from disk, and is not a good tool if you want to use transposition. The integrated one revolves around groove~, at its deep core. Groove~ reads a soundfile in a buffer~ which means it is great for many things involving sound treatment :)
      Basically to change the pitch you change the play rate of groove~. It seems that this module lets you keep the same amount of time in a loop, whatever the play rate, hence if you play your sound faster you'll experience momentary silences, and if you go slower it somehow doubles the overall time of one loop iteration, and has half of it muted. If you don't want those silences, you will either have shorter and shorter soundsamples when you're playing your sample faster, or you need to use other, more complicated method like granularization. You could also just modify the module so that a negative sample rate doesn't induce sound pausing, but going higher pitch will always give you silence. Or alternatively, you could have it so that whatever the transposition, it fills the same amount of time, it would be a little more complicated, you need to figure out what's happening inside this module.
      In the case you want the first solution, i think you should better replace this module by a groove~ or the x.player abstraction and build your own whole thing, which won't be useless as you will finally understand what's going on :)