• solipp

    @whale-av said:

    It could be tested to see whether its control rate message inlet will take (in msecs) small enough float values to make that happen.

    here is a test patch vline-test.pd. vline~ accepts messages at any time with sub-sample accuracy. This is also documented in the help-file.

    @lacuna said:

    [metro 1 1 samp]  

    How could I have known that? The helpfile doesn't mention this. (Offtopic: actually the whole forum is full of pd-vocabular-questions)

    It is documented in the metro-helpfile since pd-0.48 i guess. But i agree, there is not much redundant information in pd's helpfiles, to put it mildly ;)

    But you can „use“ the metro counts every 64 samples only, don't you?

    yes, except you use it with vline~ (see test-patch)

    When should I use [block~ 1 1 1] and when shouldn't I?

    whenever you need delay~ times smaller than 64 samples.

    posted in technical issues read more
  • solipp

    on second thought, it doesn't make much sense to me.. I think you know, but, to increase the frequency resolution you just set a higher blocksize in the fft-subpatch, time resolution is your samplerate.
    So, zero-padding to reduce latency? for a high-res spectrum display, or.. what do you want to do with your patch? I'm curious!

    posted in technical issues read more
  • solipp

    aha, so its about low latency fft? if you have a working patch, please share it!

    posted in technical issues read more
  • solipp

    there is no need for zero-padding if you want to increase the frequency resolution in a fft-subpatch (block~), or do i get something wrong?

    posted in technical issues read more
  • solipp

    my "audiolab" abstraction library is now available on deken. You'll need Pd-0.50 or later to run this.
    Please report any bugs on github: https://github.com/solipd/AudioLab

    here is a picture to draw you in (:

    posted in news read more
  • 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.

    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


    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

    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.


    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

Internal error.

Oops! Looks like something went wrong!