On 01/12/2016 05:03 PM, Martin Peach wrote:
That error was being generated when new messages were arriving at [unpackOSC] before it had finished with the previous message.
i'm curious how this could possibly happen. even if the data was sent super-fast, once a list of bytes comes out of [udpreceive], Pd will not allow another list to come until the downstream [unpackOSC] signals that it has done it's work (by returning from the stack).
A newer version of [unpackOSC] is in the sourceforge svn repository at http://sourceforge.net/p/pure-data/svn/HEAD/tree/trunk/externals/mrpeach/osc...
which fixed a re-entrancy problem, which is not the same as "fast data" (although re-entrancy happens in zero-logical time).
doing a quick check of the code, the error should be thrown if the OSC-message contained an "invalid" string, e.g. one that contains weirdo characters or is not properly zero-padded.
@richie: would it be possible to get the OSC-message (as byte-list) that generates the error?
something like the output of the following patch:
[udpreceive 7777] (change the port to yours) | [t a a] | | | [print raw] | [unpackOSC] | [print osc]
this will potentially flood the console even more, but just a few lines of output should be sufficient.
gnmdsar IOhannes