6.0.4 SDK, question about dsp64, inconsistency in doc

Mar 1, 2012 at 8:02am

6.0.4 SDK, question about dsp64, inconsistency in doc

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 1, 2012 at 12:29pm

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 2, 2012 at 9:10pm

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 at 7:42pm

Thanks, that’s clear. That’s a good information which could be added to the documentation…


You must be logged in to reply to this topic.