• lacuna

    @jameslo The bug is the delaylines~ not having 1 sample delay.
    I am not entirely sure why, but you read them at 0ms, - arguments are in ms not samples and there is the importance of the execution order with delays~, and s~ r~, you can read about in audio.examples/G05.execution.order.pd
    But this would lead to a DSP-loop here.

    However, I use tabsend~ tabreceive~ and 1 sample arrays, as this is how to do feedback-loops with 1 sample delay.
    I created the sending subpatches first, the receiving ones afterwards, - not sure if this is important for the execution order in this case, too?

    posted in technical issues read more
  • lacuna

    help > find externals
    And please read how to deal with externals in the manual: help > manual > chapter 4 externals
    To be sure, delete the zexy folder in /extra before reinstalling it with Deken

    (Also, I'd recommend to download the latest version of PD Vanilla from here https://puredata.info/downloads
    or there http://msp.ucsd.edu/software.html
    instead of using possibly outdated repositories (i.e. Synaptics). But this is unrelated to your question. )

    posted in technical issues read more
  • lacuna

    @pharaoh-sean After installing Zexy via Deken,

    try adding zexy to File > Preferences > Libraries

    or add
    [declare -lib zexy]
    in your patch.

    In File > Preferences > Searchpaths should be PD's /extra folder, and the library should be inside of that folder, of course.

    similiar thread here:

    posted in technical issues read more
  • lacuna

    @adammccaffrey you can find the error message in the sources:

    the patch is resizing the cloned arrays
    here it uses >4Gb of ram

    operating system? 32 / 64 bit?
    PD-version? 32 /64 bit?

    posted in patch~ read more
  • lacuna

    @adammccaffrey probably running out of memory.
    How much Random Access Memory does your machine have?

    posted in patch~ read more
  • lacuna

    @cfry No, the quote posted by @ddw_music is related to PD's scheduler and the basic difference between update-rates of control versus signal~objects.
    You can read about it in PD's manual chapter "scheduling" in the help-menu.

    [noise~] has to calculate 44100 random numbers per second, whether you do anything with those numbers or not. [random] just runs when you ask it to.

    ... and you can poll it every 64 samples only.
    That is why

    There's one case where you might use [noise~] and [samphold~] -- if the random step function is needed in the signal domain and you expect the sample/hold unit to update in the middle of an audio processing block.

    and why [noise~] with the output of [snapshot~] has no advantage over [random].

    When I did a comparison test with just one of each (set to fast rate), the cpu load did not differ much

    You will only feel the difference in huge patches with many [clone]s and or upsampling in the sum with many other things running.

    I am modifying an polyphonic FM synth, which has cloned objects with [phasor~] inside.

    Is the random generated inside of the [clone]?
    If not, something else might cause high CPU-load.

    The cheapest way to get random might not be calculating it in realtime, but reading preset random numbers from a text- or wavefile or an array with phasor~ or [f][+ 1]. But then the random set will loop.

    posted in technical issues read more
  • lacuna

    @whale-av @jameslo
    now [declare -lib iemlib] made it with 1.22 from Deken on Win10
    sorry for the false alarm! and thank you *

    posted in technical issues read more
  • lacuna

    @whale-av does t3_delay-help.pd work on your machine?

    posted in technical issues read more
  • lacuna

    now checked 1.16 from iem site and there is a /lib folder inside the /iemlib folder with iem_t3_lib.dll
    But still doesnt work. And no t3 object .pd files ...

    posted in technical issues read more

Internal error.

Oops! Looks like something went wrong!