#59 Remove erroneous error message for [receive~]

puredata (65)
Jamie Bullock

If a [receive~]/[r~] object is instantiated without arguments, and DSP is turned on the following error message is displayed to the console:

error: receive~ : no matching send

If this is genuinely an error, it should be caught when the object is instantiated, regardless of whether DSP is on. Also, if it is an error to have 'no matching send', then the error should also be printed when an invalid receive symbol is provided as an argument.

However, it seems to me, that it is not an error - since the receive symbol for receive~ is settable via a message. It seems that it should be valid to instantiate r~ without arguments, and set the receive symbol via a message at some later point. I therefore request that the error message is removed from the sources.


  • Logged In: YES
    Originator: NO


    imho, [r~] should output a warning/error everytime it's communication constraint is violated:

    send~/receive~ communication is by definition a 1-to-n communication: while "n" is variable (0..inf), "1" is fixed and MUST be 1.
    if we have a [r~] with no matching send, the "1" is 0, and therefore an error (as pd correctly bails out)

    since the communication does not take place before the audio-engine is turned on, there is no way for [r~] to check whether the communication is truely 1-to-n beforehand.

    you can redirect the [r~] with the "set" message _after_ instantiation: e.g. an [r~] with an invalid receive-name can become an [r~] with a valid receive-name at runtime (and vice versa).
    therefore, [r~] should bail out as soon as communication with an "illegal" [s~] is requested, which happens exactly when DSP is turned ON and the number of [s~] associated with [r~] is !=1

    this is exactly what Pd does.

    (btw, pd does print an error when you provide an invalid [receive~] symbol)



Cancel   Add attachments