• solipp

    pushed an update to deken (v 0.3).

    changes since the last version:

    new objects:
    pp.fft-freeze~ - a spectral freezer based on I08.pvoc.reverb.pd

    pp.ladder~ - a "moog" 4th order ladder filter. I made this on out of curiosity about the "zero delay filter" design. I wouldn't recommend to use it though since we have [bob~] and cpu usage is pretty high! (except if you need a fast modulating resonant hp or bp filter for whatever reason).

    pp.echo~ - an "analog" tape delay-ish delay echo effect.

    pp.xycurve - draws a xy-bezier curve and reads from it. Useful for all kinds of musical gestures..

    Many bugfixes and smaller changes. Be aware that some object might behave a little bit differently to the last version!

    posted in news read more
  • solipp

    @Gabriel-Lecup check out [pd~]!

    also, you should optimize your system for audio if you haven't:
    https://wiki.linuxaudio.org/wiki/system_configuration
    Now this is a little bit off topic, you don't have to follow all the steps from the link above, but I highly recommend to install rtirq-init (https://github.com/rncbc/rtirq ) and indicator-cpufreq (http://manpages.ubuntu.com/manpages/focal/man1/indicator-cpufreq.1.html)

    posted in technical issues read more
  • solipp

    @whale-av well, sort of... it is nowhere documented that you can mess up a working patch with two concatenated delay lines simply because you give one of the delwrites~ a new argument.

    posted in technical issues read more
  • solipp

    @jameslo ohoh, you stumbled across something here...

    first, @lacuna is not exactly right, the delay lines give you one sample delay as expected since the blocksize in the subpatch is 1.

    so what is wrong with the patch?
    here is an example:
    working.pd
    not_working.pd
    spot the difference....... right, there is none!
    The only difference between these two patches is that i created the "delwrite~/delread~ phase2Delay" after "phase1Delay" in the working example. (And i assume you created the "phase1Delay" after "phase2Delay" in the patch you shared)
    Pd sorts the dsp processing of the delay lines in the order of creation. You can do the execution order thing to get it right:
    execorder.pd
    ..but you should complain about this in the pd-mailing list because this strange behavior of pd is not properly documented anywhere it seems.

    by the way, the working patch generates some very nice psychedelic mandalas when you feed it with an impulse generator : )

    mandala.png

    posted in technical issues read more
  • solipp

    @jameslo delwrite~, delread~ is quite sufficient.

    posted in technical issues read more
  • solipp

    @JamesWN offline rendering is possible with pd if you use the -batch flag.

    here is an example patch:
    batchexample.zip
    it will render 20sec of 440hz sine tone to a "osc440.wav" file. run it with

    pd -batch batchexample.pd
    

    in your console.

    if you want to study the patch be quick and delete the connection to the "pd quit;" message or it will quit pd after 20 sec...

    posted in technical issues read more
  • solipp

    @4ZZ4 no sane real programmer would ever use pd...

    posted in abstract~ read more
  • solipp

    @liamorourke these are vanilla only (;

    posted in news read more
  • solipp

    @jameslo true. Or more like "You got me! i have this little extra sample for you. Please don't ask again!" :)

    posted in technical issues read more
  • solipp

    @jameslo there are some hints in the helpfile. fexpr~ can not look back one sample if the blocksize/vectorsize is only one sample. To look back one sample it needs a block size of at least two samples.
    By the way, there is no reason to use block~ with fexpr~ (except if you want to look back more then 64 samples).

    posted in technical issues read more

Internal error.

Oops! Looks like something went wrong!