6.0.4 SDK, question about dsp64, inconsistency in doc

    Mar 01 2012 | 8:02 am
    in the doc, it's said:
    ... Max 6 objects implement a "dsp64" method. .... One notable difference is that the signals are not passed to the dsp64 method. This is to allow for the signal that is used to change dynamically at runtime. However, the relevant info (samplerate, number of signals connected, etc) is passed in.
    If signal can change dynamically, how the count can be given in advance? I don't see anything about dsp64 on "anatomy of a MSP object."

    • Mar 01 2012 | 12:29 pm
      There's no inconsistency...
      Remember that the perform routine is called once every signal vector.
      So, what I understand from that sentence is that the variables numins and numouts could be different each time the perform routine is called (therefore changing dynamically as audio is piped in). That's great because it allows developers to dynamically configure an MSP object with a variable number of inputs and/or outputs and have that information immediately available to process samples accordingly. It all happens under the hood without requiring developers to manage it themselves. (which was a bit of a pain in Max 5)
      Hope this clears things up a bit.
      - Luigi
    • Mar 02 2012 | 9:10 pm
      I think it is a little ambiguous... @Luigi is correct about the runtime flexibility in the perform method. However, the idea of checking to see which connections are actually connected is still something that you do in the dsp method as mentioned by @Chris.
      When you change the connections (patch cords) to an object it will trigger a dsp chain re-compile. So you will always be notified in the dsp method. If you need this information then it is still appropriate to handle it in the dsp method as in Max 5.
      The number of ins and outs can still be convenient in other circumstances though, and may simplify the writing of some Max externals that have a variable number of inlets or outlets (e.g. tapout~).
      Hope this helps,
    • Mar 10 2012 | 7:42 pm
      Thanks, that's clear. That's a good information which could be added to the documentation...