skeji

I understand the event scheduler interval as the rate at which events are popped off the event queue and executed. I think this is what is referred to as Control-Rate (vs Audio-Rate). I'm curious about what assumptions we can make about the execution time of a sequence of objects and messages (i.e. a network of max objects) once they are triggered by these events (assuming they don't generate a new event to enqueue). Do they always/sometimes/never complete before the next interval? How can you know?

Possible clarification- I'm assuming *most* interconnected max objects aren't generating new events for the scheduler. I imagine each event as a trigger for a new instance of a controlled sequence of actions.

I know the hi and low priority queues introduce some complications to this picture, but the manual refers to events as the fundamental unit of execution. So, I know the rate at which the scheduler is servicing these events but nothing about how long they might take to execute. Presumably, some take longer than others but is that all I can assume?

I understand the event scheduler interval as the rate at which events are popped off the event queue and executed.  I think this is what is referred to as Control-Rate (vs Audio-Rate).  I'm curious about what assumptions we can make about the execution time of a sequence of objects and messages (i.e. a network of max objects) once they are triggered by these events (assuming they don't generate a new event to enqueue).  Do they always/sometimes/never complete before the next interval?   How can you know?

Possible clarification- I'm assuming *most* interconnected max objects aren't generating new events for the scheduler.  I imagine each event as a trigger for a new instance of a controlled sequence of actions.

I know the hi and low priority queues introduce some complications to this picture, but the manual refers to events as the fundamental unit of execution.  So, I know the rate at which the scheduler is servicing these events but nothing about how long they might take to execute.  Presumably, some take longer than others but is that all I can assume?


event-scheduler-interval-vs-execution-time

You've got it essentially right. There are way too many factors involved to give a single general answer: type of object(s) involved, other applications running, OS, processor speed, etc., etc. You can make up any of a variety of tests to find out whatever you need to know about execution time (of a particular type of event chain on a particular computer yada yada). E.g., 

If you don't mind me getting greedy, I have a follow-up: Do you think a plugin could state its latency in absolute terms (e.g. 2 ms) in order for it to be properly latency-compensated by a DAW? My sense is 'no', for all the reasons you mentioned above and I would guess a DAW needs to do some diagnostics on a plugin to determine its latency for that particular system. However, for latency-compensation in a M4L device, I think the official instruction is to specify some absolute latency, like 2ms, in one of the patcher attributes. Any ideas what's up with that?

If you don't mind me getting greedy, I have a follow-up:  Do you think a plugin could state its latency in absolute terms (e.g. 2 ms) in order for it to be properly latency-compensated by a DAW?  My sense is 'no', for all the reasons you mentioned above and I would guess a DAW needs to do some diagnostics on a plugin to determine its latency for that particular system.  However, for latency-compensation in a M4L device, I think the official instruction is to specify some absolute latency, like 2ms, in one of the patcher attributes.  Any ideas what's up with that?

Now you're talking about latency in the audio realm (MSP and/or Max for Live). That depends primarily on the buffer and vector settings of the program (I/O vector and signal vector in MSP). What that means in milliseconds depends on the audio sampling rate. In Live the signal vector (the number of samples Live processes internally at a time) is set at 64. If the sampling rate is 44,100 Hz, that equals 1.45 ms. If the sampling rate is 48,000, that equals 1.33 ms. But in Live you generally don't need to concern yourself with that signal vector latency because the application already takes it into account. (For how to deal with other types of latency like audio driver latency and I/O buffer latency, see the Live manual.) Usually the only time your plug-in will introduce greater latency than that is if you're doing something in the frequency domain such as FFT and IFFT that inherently requires a certain delay before it can give results. In both the Max event realm and the MSP audio realm, it's possible to make a patch so computationally demanding that Max can't keep up, but I suggest not worrying about that till it happens. [I hope I'm understanding your question correctly and not just telling you lots of stuff you already know.]

Now you're talking about latency in the audio realm (MSP and/or Max for Live). That depends primarily on the buffer and vector settings of the program (I/O vector and signal vector in MSP). What that means in milliseconds depends on the audio sampling rate. In Live the signal vector (the number of samples Live processes internally at a time) is set at 64. If the sampling rate is 44,100 Hz, that equals 1.45 ms. If the sampling rate is 48,000, that equals 1.33 ms. But in Live you generally don't need to concern  yourself with that signal vector latency because the application already takes it into account. (For how to deal with other types of latency like audio driver latency and I/O buffer latency, see the Live manual.) Usually the only time your plug-in will introduce greater latency than that is if you're doing something in the frequency domain such as FFT and IFFT that inherently requires a certain delay before it can give results. In both the Max event realm and the MSP audio realm, it's possible to make a patch so computationally demanding that Max can't keep up, but I suggest not worrying about that till it happens. [I hope I'm understanding your question correctly and not just telling you lots of stuff you already know.]


I think I'm hung up on 'intentional' latency (e.g. I deliberately window the signal) vs 'computational-overhead' latency (e.g. too much division, inefficient/multipass algorithm, etc.). I can set some expectations about the former (based on vector size, sr, etc... just like you said), but the latter is kindofa mysterious boogieman. I'm anticipating some of my potential projects may be terrorized by said boogieman... hence my questions. =)

I think I'm hung up on 'intentional' latency (e.g. I deliberately window the signal) vs 'computational-overhead' latency (e.g. too much division, inefficient/multipass algorithm, etc.).  I can set some expectations about the former (based on vector size, sr, etc... just like you said), but the latter is kindofa mysterious boogieman.  I'm anticipating some of my potential projects may be terrorized by said boogieman... hence my questions. =)


Event Scheduler Interval vs Execution Time