geko

I want to send a list with 2^15 (32768) elements from a fft in Max to a Visual environment (Processing). The data have to be transferred between two adjacent fft frames resp. in less than 672 ms. To achieve this I devide the list in 128 lists of 256 elements with jit.spill and send it via OSC (UDP). But after many trials I find no way to give an appropriate timing to that process:

either the lists are shot out as soon as possible and many of them are lost in the UDP queue or

the timing varys between 1 and 50 ms per list so that the overal time of 672 ms is exceeded and the system is very unstable.

I tried it e.g. with metro, delay and call backs between max and processing via OSC to adjust the timing but without success. It seems that as I delay the timing between two lists the timing in Max is in low priority queue and other events are executed between so that the time difference between sending of two lists is strongly stretched.

Could anyone give me a hint how to adjust timing here that between 2 lists is not more than e.g. 2 - 5 ms?

I work on windows 7 , 64 bit with Max 6. The max patch is very large, many conputations are going on but the system has quite enough heradroom inn performance: less than 25% of CPU power are used.

I want to send a list with 2^15 (32768) elements from a fft in Max to a Visual environment (Processing).  The data have to be transferred between two adjacent fft frames resp. in less than 672 ms. To achieve this I devide the list in 128 lists of 256 elements with jit.spill and send it via OSC (UDP). But after many trials I find no way to give an appropriate timing to that process:
either the lists are shot out as soon as possible and many of them are lost in the UDP queue or
the timing varys between 1  and 50 ms per list so that the overal time of 672 ms is exceeded and the system is very unstable.

I tried it e.g. with metro, delay and call backs between max and processing via OSC to adjust the timing but without success. It seems that as I delay the timing between two lists the timing in Max is in low priority queue and other events are executed between so that the time difference between sending of two lists is strongly stretched.
 Could anyone  give me a hint how to adjust timing here that between 2 lists is not more than e.g. 2 - 5 ms? 

I work on windows 7 , 64 bit with Max 6. The max patch is very large, many conputations are going on but the system has quite enough heradroom inn performance: less than 25% of CPU power are used.


sending-an-array-of-lists-via-osc-udp-with-presise-timing

another trial with pipe: same result. I tried to put the patcher sending the data all to the right in the main patch.

I need a solution. help is very appreciated.

another trial with pipe: same result. I tried to put the patcher sending the data all to the right in the main patch.  

I need a solution. help is very appreciated.


one revision: the time intervall in which I have to send the data is 1486 ms.

maybe. Andreas schlegel has put in his oscP5 library TCP support for sending data to Processing but how can I send data via TCP from Max? Are there externals forn that?

maybe. Andreas schlegel has put in his oscP5 library TCP support for sending data to Processing but  how can I send data via TCP from Max?  Are there externals forn that?


I don't know whether your FFT results are signals or messages but in the case of signals (MSP) you could look into using jit.catch~ in combination with jit.net.send. jit.catch~ translates signals into matrices and jit.net.send sends matrices over TCP.

I have for example been streaming audio between two computers (both running max) using jit.catch~, jit.net.send on one computer and jit.net.receive and jit.release~ on the other.

I don't know whether your FFT results are signals or messages but in the case of signals (MSP) you could look into using jit.catch~ in combination with jit.net.send. jit.catch~ translates signals into matrices and jit.net.send sends matrices over TCP.
I have for example been streaming audio between two computers (both running max) using jit.catch~, jit.net.send on one computer and jit.net.receive and jit.release~ on the other.


You could try Sadam library which has tcp send / receive etc

Thanks Edwin and Audio Source for bringing me to TCP! I have to transmit data from a fft in a jitter matrix to a Processing sketch (simple example for notice based on OSC externals from CNMAT you find as an attachment ). The second attachment is one TCP example from the OSCP5 library representing the receiver which I have to connect to Max.

My problem is that I do not know how to build the path to Processing via TCP.

I would appreciate very much if somebody could give me a simple example patch which communicates between both sides.

Thanks Edwin and Audio Source for bringing me to TCP!  I have to transmit data  from a fft in a jitter matrix  to a Processing sketch (simple example for notice based on OSC externals from CNMAT you find as an attachment ). The second attachment is one TCP example from the OSCP5 library representing the receiver which I have to connect to Max. 

My problem is that I do not know how to build the path to Processing via TCP. 

I would appreciate very much if somebody could give me a simple example patch which communicates between both sides.


Thanks SOURCE AUDIO for the hint. I would like to try the Sadam library. But I cannot download it. The website of the project seems to be offline.

Web page seems to be offline, but download link still works:

http://www.sadam.hu/download/sadamlib.zip

Thanks. The readme gives the following info:

"Also please note that the networking objects do not work on Windows XP. These issues are not related to bugs,

and will not be fixed in the future. The last version of the library with PPC-compatible externals

and with networking on Windows XP is Version 20121030. "

Because I run Max 6 32 bit on my PC it could function if I have the right version of this library.

Thanks. The readme gives the following info:
"Also please note that the networking objects do not work on Windows XP. These issues are not related to bugs,
and will not be fixed in the future. The last version of the library with PPC-compatible externals
and with networking on Windows XP is Version 20121030. "
Because I run Max 6 32 bit on my PC it could function if I have the right version of this library.


unfortunately these externals do not run on windows. I would like to try Version 20121030 of sadam library.

unfortunately these externals do not run on windows.  I would like to try Version 20121030  of sadam library.


How about little puzzle ? What could download link possibly be ?

http://www.sadam.hu/download/sadamlib_20121030.zip

How about little puzzle ? What could download link possibly be ?
just joking, here it is:
http://www.sadam.hu/download/sadamlib_20121030.zip


... puzzling is not my thing, but perhaps I should change:-)

... puzzling is not my thing, but perhaps I should change:-)
 thanks!


You are welcome, please let us know if You were successful with TCP .

My initial thought was that because of splitting the original list into chunks

and sending them via UDP could scrummble them at the receiving side,

You are welcome, please let us know  if You were successful with TCP .
My initial thought was that because of splitting the original list into chunks
and sending them via UDP could scrummble them at the receiving side,
and that is what TCP does better.


Concerning udpsend and udpreceive: have a look at the size tab of the help patches. You'll need to set the maxpacketsize because the default value is too small for the size of the packages that you want to send. The maxpacketsize value is expressed in bytes. If I'm not mistaken floats are by default sent as single precision over OSC which means four bytes per float value. In case of double precision floating point it would be 8 bytes per float value. Furthermore the OSC header (OSC Type Tag String) will take some bytes too.

This means that sending a package with 32768 elements takes 32768 * 4 bytes = 131072 bytes for the data and, just to be sure, I would add 40000 bytes more to the maxpacketsize setting so that there is plenty of space for the header as well.

http://opensoundcontrol.org/spec-1_0-examples

Concerning udpsend and udpreceive: have a look at the size tab of the help patches. You'll need to set the maxpacketsize because the default value is too small for the size of the packages that you want to send. The maxpacketsize value is expressed in bytes. If I'm not mistaken floats are by default sent as single precision over OSC which means four bytes per float value. In case of double precision floating point it would be 8 bytes per float value. Furthermore the OSC header (OSC Type Tag String) will take some bytes too.
This means that  sending a package with 32768 elements takes 32768 * 4 bytes = 131072 bytes for the data and, just to be sure, I would add 40000 bytes more to the maxpacketsize setting so that there is plenty of space for the header as well.
http://opensoundcontrol.org/spec-1_0
http://opensoundcontrol.org/spec-1_0-examples


now after some time, many trials with UDP and some with TCP externals in Max my experience is that neither the mentioned UDP nor TCP externals can do this data transfer. Reason imho is the max massage, which is not designed for this amount of data (32768 floating point elements in about 1,5 sec is not so far away from a signal in 44.1 KHz).

now after some time, many  trials with UDP and some with TCP externals in Max my experience is that neither the mentioned UDP nor TCP externals can do this data transfer. Reason imho is the max massage, which is not designed for this amount of data (32768 floating point elements in about 1,5 sec is not so far away from a signal in 44.1 KHz).


This is a pitty that data transfer between IDEs is so difficult if it is more than just small lists or a few values.

a solution maybe would be an UDP or TCP based Object which takes a jitter matrix as input?

This is a pitty that data transfer between IDEs is so difficult if it is more than just small lists or a few values.
a solution maybe would be an UDP or TCP based Object which takes a jitter matrix as input?


- Dividing your list up doesn't seem like such a good idea to me. That will just add extra overhead for each message.

- TCP is similarly adding a round-trip overhead that you shouldn't need if you're sending data to localhost.

- I would use CNMAT's o.dot objects to format your messages as OSC. They all should be one bundle, to ensure atomicity

- I would use udpsend in CNMAT compatibility mode: eg [udpsend 127.0.0.1 55555 CNMAT]

- I probably would tweak the maxpacketsize and perhaps maxqueuesize of udpsend.

Yes, you're trying to push a great deal of data. Although not unreasonable by contemporary standards, it's much more than imagined when OSC was written.

Do you have some kind of test patch? Also, I understand you've put a lot of time into this and it might very well be impossible. It might be wise to look for different ways of satisfying your artistic need.

- Dividing your list up doesn't seem like such a good idea to me. That will just add extra overhead for each message.
- TCP is similarly adding a round-trip overhead that you shouldn't need if you're sending data to localhost.
- I would use CNMAT's o.dot objects to format your messages as OSC. They all should be one bundle, to ensure atomicity
- I would use udpsend in CNMAT compatibility mode: eg [udpsend 127.0.0.1 55555 CNMAT]
- I probably would tweak the maxpacketsize and perhaps maxqueuesize of udpsend.

Do you have some kind of test patch? Also, I understand you've put a lot of time into this and it might very well be impossible. It might be wise to look for different ways of satisfying your artistic need.


with UDP I see the problem that the size for one packet is limited ( I think to 64 K). So it is not possible to send a 32768 elements array without dividing it.

1.) putting the audio signal in Processing (the visual envronment) and make there a second similar fft analysis. But my actual audio interface is not right recognized by the system (possibly due to the drivers from behringer). So I suppose for this I need a new audio interface.

https://www.npmjs.com/package/websockets-streaming-audio

https://cycling74.com/tools/ol-wsserver-embedded-websockethttp-webserver-external/#.V_dZ6pN97dQ

http://stackoverflow.com/questions/18900187/processing-how-to-send-data-through-websockets-to-javascript-application

2.) using websockets
to stream audio:
https://www.npmjs.com/package/websockets-streaming-audio
Olli Larkens Objects:
https://cycling74.com/tools/ol-wsserver-embedded-websockethttp-webserver-external/#.V_dZ6pN97dQ
catching data in Processing:
http://stackoverflow.com/questions/18900187/processing-how-to-send-data-through-websockets-to-javascript-application


... I will even see to provide a test patch for this case. But it could become tomorrow. I need to solve this problem soon for an installation next month.

... I will even see to provide a test patch for this case.  But it could become tomorrow. I need to solve this problem soon for an installation next month.


@Mzed it is possible to send a jitter matrix into an odot object which transmits that via OSC?

@Mzed it is possible to send a jitter matrix into an odot object  which transmits that via OSC?
... I will even see to provide a test patch for this case.  But it could become tomorrow. I need to solve this problem soon for an installation next month.


sending an array of lists via OSC with precise timing