• seb-harmonik.ar

    it seems the seed message to the inlet wasn't added till pd 0.49

    posted in technical issues read more
  • seb-harmonik.ar

    it's not a bug, it's just that messages actually only process every 64 samples at the least. You can get a bang every sample with [metro 1 1 samp] but it should be noted that most pd message objects only interact with each other at 64-sample boundaries, there are some that use the elapsed logical time to get times in between though (like vsnapshot~)
    also this seems like a very inefficient way to do per-sample processing..

    posted in technical issues read more
  • seb-harmonik.ar

    the patch I posted specifically? You can make your own delay line with arrays but if you're using vanilla the actual buffer (array) size has to be a multiple of 64 because that's the rate that [tabwrite~] gets bangs
    and the amount of delay time you can actually use is the array size - audio block size because if it's greater then the writer and the reader will overlap each other.

    posted in technical issues read more
  • seb-harmonik.ar

    yeah, here's some talk about DEFDELVS "Pd internally adds 64 samples to
    the delay time you specify for [delwrite~], so the user will think that buffer
    size = max. delay time."
    This adds 64 to the given write buffer size. At 44100 the given size in samples is 44 and then 108 after DEFDELVS.
    (in sigdelwrite_updatesr called from the dsp methods)

    I don't really know how fexpr~ works or how efficient it is, but it would use less memory probably.. I usually use delwrite~/delread~ but idk why

    posted in technical issues read more
  • seb-harmonik.ar

    I tried making your patch and it worked if the block size was lower than 256

    edit: it's because your write buffer length is less than 256 samples. Increase past 1 ms and it works.
    not sure why it would work with block sizes of 64 & 128 but not with 256 though.. and it seems like it should work anyways..

    edit2: For those curious (I was) after digging around what happens is that it is possible for the writer to write over its starting point in the buffer before the reader has a chance to read those values if the buffer size < the block size. Because the "real" delay time (that is, the starting read point in the circular buffer) is supposed to be < the write buffer size but is also supposed to be >= the block size, the delay is set to the buffer size so when it reads the buffer it starts at the buffer size and reads the buffer circularly until the block finishes.
    In this specific case, because 1 ms is 176 samples, pd rounds the write buffer size up to 240 (for some reason it adds 64 samples). (And snapshot~ takes the last sample in a block)

    posted in technical issues read more
  • seb-harmonik.ar

    the way that numbers are printed is not how they actually are. floating point numbers, represented in base 10, are actually stored in binary. this is true of your original number as well as the 100 you multiply your number with. When the number is displayed after the [* 100], it might not actually be 2038, it is a binary number that is extremely close. You'll notice that if you put 2038 right before the int, it will display correctly because that number is different in binary than 20.38 * 100.

    edit: check this out: https://www.h-schmidt.net/FloatConverter/IEEE754.html
    notice how if you put in 20.38 the value actually stored is 20.3799991607666015625

    posted in technical issues read more
  • seb-harmonik.ar

    maybe if you post your patch we could figure it out.
    Btw just using a hanning window with no overlap is amplitude modulation with a cosine wave, but it does work to time-limit a window so there are fewer artifacts when non-bin frequencies are treated as periodic (like in an fft)

    posted in technical issues read more
  • seb-harmonik.ar

    Because all you are doing is amplitude modulating the signal twice. In the attached picture there is overlap and a different window size. Are you implementing that part? that should cause less of a ring-modulator sound I think

    posted in technical issues read more
  • seb-harmonik.ar

    why don't you use
    [1 (
    |
    [rpole~ 1]
    Screen Shot 2018-07-18 at 11.05.56 PM.png

    posted in technical issues read more

Internal error.

Oops! Looks like something went wrong!