charly

I would like to get the DSP method of one object executed after the DSP method of another object. The tool to use seems to be Z_PUT_LAST, but after a look on the web I found :

"In fact, Z_PUT_LAST has turned out to be bogus. There is no way to

Does anyone know if it has been fixed, and if there now a way to guarantee the order of execution of the DSP method?

Another question: I am writing an external which needs to do something as soon as the dsp is turned off. Is there any way to tell an external that the DSP has been turned off using an internal max message (equivalent to the DSP method), rather than having to send a message manually to my object each time, after turning off the dsp?

I would like to get the DSP method of one object executed after the DSP method of another object. The tool to use seems to be Z_PUT_LAST, but after a look on the web I found :
"In fact, Z_PUT_LAST has turned out to be bogus. There is no way to
guarantee order of execution."
Does anyone know if it has been fixed, and if there now a way to guarantee the order of execution of the DSP method?

help-on-how-to-use-z_put_last

On Oct 1, 2006, at 7:57 PM, charly wrote:

> I would like to get the DSP method of one object executed after the 

> DSP method of another object. The tool to use seems to be 

> Z_PUT_LAST, but after a look on the web I found :

> "In fact, Z_PUT_LAST has turned out to be bogus. There is no way to

> Does anyone know if it has been fixed, and if there now a way to 

> guarantee the order of execution of the DSP method?

Sorry but as you discovered, this isn't and won't ever be guaranteed. 

You'll need to use some other means of object communication in order 

to achieve this on your own, regardless of the signal compiler's 

order of execution. For example, here are a few ideas:

- use state flags bound to symbols to communicate between objects

- use patchcords to communicate between objects like tapin~/tapout~ 

(or signal patchcords to ensure order and/or communicate frame 

- always operate one signal vector later thus guaranteeing all of the 

previous vector's calculations have been performed

If you provide us a description of why you need this, perhaps we 

> Another question: I am writing an external which needs to do 

> something as soon as the dsp is turned off. Is there any way to 

> tell an external that the DSP has been turned off using an internal 

> max message (equivalent to the DSP method), rather than having to 

> send a message manually to my object each time, after turning off 

addmess((method)foo_dspstate, "dspstate", A_CANT, 0);

        //dsp has been turned off

> I would like to get the DSP method of one object executed after the  
> DSP method of another object. The tool to use seems to be  
> Z_PUT_LAST, but after a look on the web I found :
> "In fact, Z_PUT_LAST has turned out to be bogus. There is no way to
> guarantee order of execution."
> Does anyone know if it has been fixed, and if there now a way to  
> guarantee the order of execution of the DSP method?

Sorry but as you discovered, this isn't and won't ever be guaranteed.  
You'll need to use some other means of object communication in order  
to achieve this on your own, regardless of the signal compiler's  
order of execution. For example, here are a few ideas:

- use patchcords to communicate between objects like tapin~/tapout~  
(or signal patchcords to ensure order and/or communicate frame  
information like fft~/ifft~)

- always operate one signal vector later thus guaranteeing all of the  
previous vector's calculations have been performed

If you provide us a description of why you need this, perhaps we  
could better recommend an approach

> Another question: I am writing an external which needs to do  
> something as soon as the dsp is turned off. Is there any way to  
> tell an external that the DSP has been turned off using an internal  
> max message (equivalent to the DSP method), rather than having to  
> send a message manually to my object each time, after turning off  
> the dsp?

...
addmess((method)foo_dspstate, "dspstate", A_CANT, 0);
...

void foo_dspstate(t_send *x, long n)
{
	if (n) {
		//dsp has been turned on
	} else {
		//dsp has been turned off
	}
}

I’ll describe what I am trying to do, hoping for some advices (thanks to those who will have the courage to read it entirely).

I am currently working on writing tcpsend~/tcpreceive~ externals, to send and receive audio between 2 computers running maxMSP, via TCP.

Currently, the tcpsend~ sends all its input vectors as a big TCP packet in the perform method. The tcpreceive~ has 2 threads: one to receive the packets and write them in a circular buffer, the other (the MSP audio thread) to read the circular buffer and copy into output vectors in the perform method. The circular buffer enables to avoid glitches that would occur if one packet was a bit late, by introducing latency between sender and receiver.

I still have 2 issues: one is the initial synchronisation of tcpsend~ and tcpreceive~, the other is ensuring that they stay in sync "forever".

1) The initial sync of tcpsend~/tcpreceive~ is done via a “handshake” in dsp methods of both objects. So the dsp methods doesn’t return till the handshake is done, or a timeout occurs. I wanted to use Z_PUT_LAST to ensure this method still works with multiple tcpsend~/tcpreceive~ objects and more than 2 computers. Now I need to find a way to press only one button to tell all the objects (on different computers) to begin to write or read in their respective circular buffers, at “the same audio time”, i.e. the next audio buffer processed by maxMSP. I am afraid that if I use MIDI or udpsend to pass a message across computers, they would be out of sync of a few audio buffers, except if Scheduler in Audio Interrupt is turned on maybe. So I am not sure how to do that. Any advice?

2) To ensure constant synchronisation (the circular buffer is never totally full or empty), perform methods have to be called every “n” second, with the same “n” for sender and receiver. I assume that “n” is always equal to (signal vector size)/(sampling rate) due to real-time input/output constraint. But on Windows XP, mme and directsound drivers have settings for signal vector size, sampling rate, but also “latency”, which is a bit confusing. So if I really wanna be sure that each audio buffer is processed every “n” second on all computers, can I use crappy sound cards and mme drivers with the same “latency” setting (apparently not), or do I need to have proper sound cards with ASIO drivers, or maybe even synchronized sound cards via word clock?

Sorry for this really long question, and thanks a lot for any help,

I am currently working on writing tcpsend~/tcpreceive~ externals, to send and receive audio between 2 computers running maxMSP, via TCP.
Currently, the tcpsend~ sends all its input vectors as a big TCP packet in the perform method. The tcpreceive~ has 2 threads: one to receive the packets and write them in a circular buffer, the other (the MSP audio thread) to read the circular buffer and copy into output vectors in the perform method. The circular buffer enables to avoid glitches that would occur if one packet was a bit late, by introducing latency between sender and receiver.

help on how to use Z_PUT_LAST