• jameslo

    @60hz Sorry, but all I have for you are questions :(. Do you know beforehand the complete set of possible IDs? I'm assuming from your description and example that each ID may go in and out of range, so when you say you want the closest one, do you mean the closest one that's still in range? And I gather from your example that an ID is in-range when you've received an OSC message from it within the last 100 ms, is that right?

    posted in technical issues read more
  • jameslo

    @raynovich technically, yours is a polynomial function. It would be an exponential function if the input was used as the exponent of some constant, like {mtof].

    I've only used Hann windows in 2 circumstances: as an FFT windowing function, and for granular synthesis. In the FFT case, the Hann window allows you to overlap each window by a factor of 4 so there are no discontinuities in the inverse transform. In granular synthesis, I've noticed that the Hann window injects fewer harmonics of the looping frequency so that the tone of the wavetable comes through more. I think there's a mathematical explanation of how that works in that same Miller Puckette book.

    I'm sure there are other uses I don't know about, maybe someone more knowledgeable can chime in.

    posted in technical issues read more
  • jameslo

    @raynovich If it sounds good, why not? BTW, the multiplication by 3 and division by 9 cancel each other out, so you're just squaring the output of [vline~].

    Here's Miller Puckette on the subject of "quartic curves" (raising to the 4th power) and how they're an OK approximation of decibel curves.

    posted in technical issues read more
  • jameslo

    @patricio.tics @whale-av I wonder if the backslash isn't being passed? I recently learned that backslash is an escape character--try using two.

    posted in technical issues read more
  • jameslo

    I found a link to the [wintablet] external in this topic (third to last reply) and it works beautifully with my Wacom Intuos S but only in the 32 bit version of Pd. If I'd rather it be working in the 64 bit version of Pd, what are my options? Is it just a matter of recompiling it for 64 bit, or is it not that simple? Has someone done it already? Should I just give up and run the 32 bit version when I want tablet input and send OSC to the 64 bit process?

    posted in technical issues read more
  • jameslo

    @lead I'm not sure what you're looking for, can you give us some numeric examples? If you simply want to reduce the precision of a float to some number of decimal places, you could do it this way:
    Annotation 2020-08-05 074524.png

    posted in technical issues read more
  • jameslo

    @dazar_uy Try [declare -lib iemlib] or put iemlib in the list of libs to load at startup (File->Preferences->Startup)

    posted in technical issues read more
  • jameslo

    @Nicolas-Danet RE [block~ 32 2], in my testing I've found that overlapped windowing is broken WRT Hann windowing (used in FFT) if you don't choose a block size that is >= the overlap factor * the oversampling factor * 64, so my concern is that you've just documented (and copied into Spaghettis) some undocumented/unspecified Pd behavior. Maybe there are some other applications of overlap that depend on this behavior, but I'm not aware of any. In the following example, you can verify that the output of [pd 4xoverlapBlockSubpatch] is messed up in a unique way for each subpatch block size less than 256 = 4 * 1 * 64. It doesn't matter what the enclosing patch's block size is. All the other subpatch block sizes >= 256 work and produce the same output. I've only tested 4 as the overlap factor because that's the only one I know how to use with Fourier resynthesis.
    Annotation 2020-07-17 101800.png overlap blocks3.pd<= ignore poor choice of patch name

    posted in tutorials read more
  • jameslo

    @Nicolas-Danet Hey Nicolas, your description of [block~ 128 2] doesn't match my understanding (maybe because I misunderstood your description :)). Look at this test:
    Annotation 2020-07-17 090939.png overlap blocks 128 2.pd
    On the input side we are in agreement, it's a sliding window. On the output side, my understanding is that the sliding windows are just summed at a 64 sample offsets. This is hard to describe in words, so I aligned the tables in the subpatch to suggest how they are summed. As far as I know, there is no vector reversal. What do you think?

    Edit: Oh wait, our outputs are the same at the 64 block level (A+A' B+B' C+C'....) so I'm probably reading-comprehension challenged, but I still wonder why you describe it in terms of vector reversal. The vector is definitely not reversed at the sample level.

    posted in tutorials read more

Internal error.

Oops! Looks like something went wrong!