• solipp

    @ingox right, it was about them for loops...
    Although, getting lost in details is certainly a good paradigm for teaching/learning pd :)

    posted in tutorials read more
  • solipp

    @ingox yeah, but what if you want to parse more then one variable? Here is an attempt, i think it's dirty but it works:

    posted in tutorials read more
  • solipp

    @apple-like_fruit there are some nice patches in pd's audio examples, namely I01 - I10. (help -> browser -> Pure Data/3.audio.examples/). Miller also gave a lecture about this topic and shares the screen movies on his site: http://msp.ucsd.edu/syllabi/206.18s/index.htm

    there are tons of examples out there, check ELSE and the live electronic tutorial, pd-spectral-toolkit, the fft-.. patches in my abstractions library: https://forum.pdpatchrepo.info/topic/12334/audiolab-is-now-available-on-deken/19

    posted in tutorials read more
  • solipp

    @jaffasplaffa said:

    I tried removing the block~ 1 a while ago, for the reason you mention, that fexpr~ is already processing every sample, but I did not get the same result, So kind of scratched it, but I will look into it again.

    you need the block~ 1 for 1 sample feedback delay in a resonant filter

    I am still beginner with filters, but the reason I used fexpr~ was because of the "processes every sample", so I was kind og thinking this is what I need.

    for the lop~ are you sure that these filters are made in the same way, the lop~ and the karlsen filter?

    yes, they are exactly the same. you can just stack 4 lop~ an feed back the output with one sample delay. or, if you want signal input for cutoff use rpole~ like this:


    rpole is like [fexpr~ $x1 + $x2 * $y1] (see help) with the additional math it is what the fexpr~ in your patch does. same as lop~..

    For the oversampling usually oversampling makes sure that it doesn't blow up at higher frequencies.

    [clip~ 0.0001 0.8] prevents your patch from blowing up.

    posted in patch~ read more
  • solipp

    @jaffasplaffa why fexpr~ for a simple onepole filter.. when your patch already runs with blocksize 1? you can replace [fexpr~] with [lop~] or [rpole~] or some delays + math like in the original code.
    I couldn't resit building the thing following this example: https://www.musicdsp.org/en/latest/Filters/240-karlsen-fast-ladder.html

    !filter gets unstable at higher frequencies

    also, do you notice any difference in sound with oversampling + anti aliasing filter..?
    maybe make it optional and put the anti aliasing filter in a subpatch with [switch~]

    Merry christmas to you too!

    posted in patch~ read more
  • solipp

    @otterly said:

    I've tried [phasor~], [osc~], [noise~] and they don't sound like piano sounds.

    certainly not :) check out Mike Moreno's Instrument patches, there are some great examples for other instruments as well

    posted in Off topic read more
  • solipp

    @tabache seems like you have declared "audiolab" under File -> Preferences -> Startup.
    You only need to do this for single binary libraries, e.g. zexy or GEM. Audiolab is a collection of abstractions. You can point pd to the right directory under File -> Preferences -> Path, or you can just copy the audiolab folder into your projects directory and use [declare -path ./audiolab] in your main patch.
    It should still work with Pd 0.50.2, but in the future I'll incorporate any new features of pd whenever it makes sense.. you should stick with the latest version of pd, there are only benefits.


    posted in news read more
  • solipp

    @Polaris please don't use pd-extended in 2020... In the latest pd "vanilla" there is the option to run pd in batch mode from within pd using the fast-forward message. here is an example: Screenshot_2020-11-02_20-48-25.png
    it fills an 10 sec. array instantly. Of cause all other processes will also be fast forwarded.
    However, if you want to point out what you are planning to do in a wider context, i guess there is a better solution then filling arrays instantly. maybe..

    posted in technical issues read more
  • solipp

    Problem with low pass filter smoothing is that it doesn't reach to the desired value.
    The lower the slew rate, the lower the "resolution" of the output.

    posted in technical issues read more

Internal error.

Oops! Looks like something went wrong!