John Gibson

I'm trying to send sound across the network between two jit.buffer~ objects. If I set both buffer lengths to 5000 msec, everything is fine. If I set them to 6000 msec, I get this error message from the receiving jit.buffer~:

which I assume refers to the width of the single dimension I'm using for my mono buffers.

Is this a known limitation of jit.buffer~? If so, is it documented somewhere? Or might I have some other problem?

I found one reference to this error message in a four-year-old post here, but there was no followup about this issue.

jit-buffer-length-limitation

Not sure about a limit, but can you wrap into multiple lines and send as 2D?

Thanks, seejayjames. I hadn't thought of doing that. Seems a little cumbersome, but better than having it fail! The only trouble is that jit.buffer~ treats multiple lines as separate chans, so there would be even more futzing around to support multiple chans with the wrapping idea. I wonder what the limit on the length of a matrix is ... I would hope unsigned int32 or better, but I can see that this would rarely be needed for video processing.

Out of curiosity, if you send one big jit.buffer~ to another without going over the network, does it give you the same error? Wondering if it's something about sending over the network.

At the receiving end I would use jit.submatrix to grab the rows first, then pass to jit.buffer~ (and maybe use one jit.buffer~ per channel). This way you can decide how to load and unload the data, and whether certain rows go to certain channels or all to the same channel.

You could also have a [prepend] at the sending point, and change it to 1, 2, 3, 4 etc., then use [route 1 2 3 4] at the receiving end to separate out where your matrix data ends up. So everything can go through one networking object, but get routed around at the destination easily.

Out of curiosity, if you send one big jit.buffer~ to another without going over the network, does it give you the same error? Wondering if it's something about sending over the network. 

You could also have a [prepend] at the sending point, and change it to 1, 2, 3, 4 etc., then use [route 1 2 3 4] at the receiving end to separate out where your matrix data ends up. So everything can go through one networking object, but get routed around at the destination easily.


jit.buffer~ length limitation?