• ddw_music

    Ahh... as often happens: Post the question, and then find the object.

    [pix_rectangle] will at least handle rectangular shapes (enough for what I want to play with now).

    hjh

    posted in pixel# read more
  • ddw_music

    I see there are various ways to use one image as a mask for another.

    But I'd like to construct a mask of a rectangular shape with an arbitrary position and size within the pix. I suppose I could handle arbitrary position by loading an image file with the rectangle, and [pix_roll]-ing it (twice, once for each dimension), but that wouldn't help with size.

    It seems like there should be some pix object to fill a pix region with a color or pattern. But, I can't find it.

    Thanks,
    hjh

    posted in pixel# read more
  • ddw_music

    I know I can rotate an image by [rotate] or [rotateXYZ] before [pix_texture].

    But I was playing with pix_lumaoffset and I would love for it to work at an angle (currently it's only vertical). This could be done by rotating the pix as a pix, applying the effect, and rotating back.

    But it seems there's no pix_ object for rotating?

    How would one do this?

    hjh

    posted in pixel# read more
  • ddw_music

    As I understand it, there is no way for any app to guarantee the port from which messages are sent. If the desired outgoing port is busy, the app has only two ways to handle it: choose a different port (which may conflict with the receiver's expectation), or exit with error.

    So, AFAICS, the receiving app must be capable of handling multiple possible source ports.

    In SuperCollider, upon startup it tries to get port 57120 for UDP send and receive. If this fails, it tries 57121 and so on until it finds an open port. From that point forward, messages sent to SC should be addressed to that port, and messages sent from SC will come from the same port number. This at least is deterministic: you can ask it NetAddr.langPort and be sure messages will come from here (but you can't be 100% sure this will be the same on every startup, as it's possible to have multiple sclang processes running at the same time, and they can't all use the same port).

    IMO this is easier to manage than Pd's "choose a random outgoing port" -- I have no idea why so many apps do it that way. It's a pain. At least SC's way, you can anticipate a range of ports that are likely to be used.

    In any case, I don't think it will work to write the server app to filter messages on one and only one port number. You'll probably at least need some handshaking logic for the server to read the port number.

    hjh

    posted in technical issues read more
  • ddw_music

    @Balwyn said:

    this should work

    I was never able to get $0 to work in a [pd ......] subpatch, only in an abstraction... is that right, or did I miss something?

    hjh

    posted in technical issues read more
  • ddw_music

    Because $f1 is already floating point, you gain nothing by multiplying by 1000000. That might be useful in the integer domain, but floating point numbers "shift" their full precision based on the magnitude, so it's a wasted operation.

    Then, dividing by 1000000 is the same as multiplying by 0.000001. These are convenient numbers in decimal, but they are repeating fractions in binary floating point (like 1/7 = 0.142847142847...) so... you thought multiplying and dividing would give you extra precision but in fact, you've just introduced extra rounding error. This probably explains why it never reaches 1. (This is a very common misconception with floating point numbers. We tend to assume that a finite decimal should also be a finite float, but computer floats are binary. Any rational number where the denominator's prime factors are 2 and 5 will be finite in decimal, but a factor of 5 in the denominator will create an infinitely repeating binary representation, so 0.1 decimal is 1.1001100110011... x 2^(-4) in binary -- it's no more precise than 0.3333 in decimal or binary.)

    hjh

    posted in technical issues read more
  • ddw_music

    It looks and sounds like PD is falling behind in audio processing because you're asking it to fill the entire table with 12 harmonics for every single update coming from any slider.

    You might also try to reduce the number of updates. Sliders are (probably) firing dozens of messages per second. In Max I'd have used [speedlim] to lower the rate of messages. Maybe cyclone has that...? I didn't look. Or hack something up with a delay and a spigot.

    hjh

    posted in technical issues read more
  • ddw_music

    @whale-av said:

    @jameslo It's not a rounding error........ it is drifting for some reason.

    https://github.com/pure-data/pure-data/blob/d07e6efbaef57442d11ca6a83810187256db6292/src/d_osc.c#L95

    ... seems to show that phasor~ is integrating floating point values.

    These floating point values necessarily have some inaccuracy. So their integration will have some inaccuracy, which will accumulate.

    If the result of adding 1/44100 to itself 44100 times is not exactly 1.0, over time this would manifest as drift.

    That is, rounding error can be drift. ...?

    hjh

    posted in technical issues read more
  • ddw_music

    @jameslo OK, I skipped over that. Must be some roundoff error, then (particularly if phasor~ is adding a phase increment for every sample). I don't have a solid explanation.

    hjh

    posted in technical issues read more

Internal error.

Oops! Looks like something went wrong!