• solipp

    hi there, made an abstraction based on B.16.long-varispeed.pd. It should fit all your needs, variable speed and reverse playback, no artifacts with very long soundfiles as far as my humble ears can tell. and it comes with a nice little gui.. sfplayer-gui.png sfplayer.zip
    also on github: https://github.com/solipd/AudioLab
    you'll need pd-0.49 or higher to run it.
    cheers

    posted in technical issues read more
  • solipp

    sorry i'm late to the party.. if someone is interested in a vanilla solution, try this abstraction: spat8.zip

    spat8-gui.png

    you can adjust the speaker positions to fit your setup, in the GUI you'll have to switch to edit mode to drag them around. Two signals x and y determine the position of the sound source in a cartesian plane. This is called distance based amplitude panning (dbab), i guess..

    The abstraction is part of my "AudioLab" library: https://github.com/solipd/AudioLab

    edit: needs pd-0.49 or higher!

    posted in technical issues read more
  • solipp

    @yannseznec said:

    I guess I still see a downside in terms of needing to trigger the line~ envelopes using a (non-signal rate) bang, but is that not really an issue in practice?

    Why? Usually you won't change any parameters while a single grain is playing. So instead of sampling a signal with [samphold~] you can just keep everything in the control domain and save some cpu.
    If you want to trigger your grains with sample accuracy use [vline~] instead of [line~].

    posted in patch~ read more
  • solipp

    @yannseznec
    one benefit of using line~ instead of phasor~ is that it allows you to trigger the grains rhythmically or to have gaps between the grains. Also, with line~ you don't have to use a workaround like threshold~

    "similarly, I assumed that using a signal rate method for offsetting the table playback would be better practice than using the right inlet on tabread4~"

    not in this case. you'll get some distortion at the end of a longer table (more than 32k samples) It's documented in B15-tabread4~-onset.pd

    You should not get clicks with [switch~] when you do the windowing of your grains right.

    cheers!

    posted in patch~ read more
  • solipp

    Hey @yannseznec,

    i had a quick look at your patch. I have a few suggestions:
    why don't you use line~ instead of phasor~?
    Using threshold~ to trigger new events will definitely cause a some problems, especially when the grains are played at a fast rate!
    Use switch~ to turn dsp of when the grains are not played and save some cpu!
    And use the right inlet of tabread4~ to onset into table instead of adding to the signal. (see help ->browser->Pure Data/Audio Examples/B15-tabread4~-onset)

    I have a granular sampler "pp.grainer~" in my repo if you want to have a look at it. Shared the link a while ago here https://forum.pdpatchrepo.info/topic/11906/audiolab

    posted in patch~ read more
  • solipp

    @weightless that's why you don't get a result from the outlet. Like initbang, savestate sends the list "before" the abstraction is created/connected in the parent patch.

    posted in abstract~ read more
  • solipp

    @weightless interesting... it seems that initbang sneaked into pd-vanilla, at least you could use savestate in the same way: savestate_as_initbang.zip

    posted in abstract~ read more
  • solipp

    @weightless sorry, i got it wrong. Of course it's meant to be copied into the abstraction... I should study the helpfiles more carefully before i post.. :blush:

    posted in abstract~ read more
  • solipp

    @weightless i don't get it. The whole point of having an object like [savestate] is that you don't have to create abstractions with individual arguments for state saving...

    posted in abstract~ read more
  • solipp

    congrats! ;)

    if you did
    "sudo make install"
    you can savely delete it!

    pd opens when you type "pd" in your terminal

    posted in technical issues read more

Internal error.

Oops! Looks like something went wrong!