How to fill ofBuffer with array of bytes


#1

I am looking in to the option of sending a OSC blob to an Arduino.
For it to work I will need to fill a ofBuffer with a bunch of bytes (number between 0 - 8).

I am stuck on the simple set of filling the ofBuffer with those numbers.

Ideally in the end the buffer would contain {0,3,5,1,7,9,4,2, and so on}

so I can use oscMsg.addBlobArg(ofBuffer)

thanks for any advice.


#2

Hi Stephan,

I wonder what you are trying to do?! If the purpose of this task is to be as efficient as possible when communication with the Arduino, I am not sure if OSC in general is the right way to go.

Anyway, here we go:

// the numbers you wanna send (between -127 – +127 in case of char)
char a = 5;
char b = 127;

// one way is using a dynamic std::string
ofBuffer buffer;
string s;

s.push_back(a);
s.push_back(b);
buffer.set(s);

// another, most probably more efficient one, using a char array 
ofBuffer buffer2;
char c[2] = { a, b };
buffer2.set(c, sizeof(c) * sizeof(c[0]));

But that leads to the question why not just send a string?


#3

By the way, if anybody wonders how to get a integer back from a string respectively an array of chars:

string s;
for (int i=0; i < 10; i++) {
    s.push_back( (char) i );
}

// won't print anything in the console as Ascii codes 0-31 are reserved 'control characters'
cout << "nothing visible:" << s << endl;

// you need to cast to integer if you wanna get a 'number' back
cout << "numbers 0 – 9: ";
for(char & c : s) {
    cout << (int) c; // to get a number, cast to int!
    cout << " ";
}
cout << endl;

#4

Danke für deine Antwort.

I have a small very custom screen that can accept 6 different states per pixel. 1022 pixels in total. But each group of 18 pixels is one OSC client. I have about 60 of these clients.

Since ofBuffer/blob is used to send images between OSC clients I thought it might be better/faster/more efficient to use the blob sending function.
When sending a blob to all clients at the same time it must be more effect than having to loop through each client separately no?

It’s true my blob is just a 1D array but each element only needs to be a byte not an int or string. This would make it less data to transfer, no? Even better/smaller would be to send 6 bools per pixel.

what do you think?
Gruss,
Stephan.


#5

When sending a blob to all clients at the same time it must be more effect than having to loop through each client separately no?

Good question. I’ve never used OSC together with the Arduino so I don’t know the ins and outs. But in general there are several aspects to it:

  • framerate you are sending with
  • baudRate of the serial sender/client
  • size of the data you are sending
  • overhead of the osc protocol
  • serial buffer size of the AtMega you are using
  • clock speed the AtMega is running with

I certainly would first try the OSC multicasting method and then offset on the reading side.

It’s true my blob is just a 1D array but each element only needs to be a byte not an int or string. This would make it less data to transfer, no?

Keep in mind that an (unsigned) char is one byte. And a std::string is basically a series of chars + one termination character.

Even better/smaller would be to send 6 bools per pixel

3 bits (2^3) would be enough to encode 6 different states per pixel.

That said, I would start with sending a string via OSC multicast and just offset (by 18) on every client. If you then experience performance problems I would further optimize and try to crank more then one pixel into one char or even use a light compression algorithm (but I really don’t think that’s needed).


#6

Hmm,

I just did the math. The Arduino’s maximum serial transmission rate is 115200 baud which equals 14400 bytes/s. I don’t know how much overhead OSC brings with but for simplicity let’s just assume there is none, then 14400 bytes/s / 1022 bytes (one for every pixel) would result in something like 14 fps. Depending on the display you have this might be sufficient … or not :wink:


#7

certainly fast enough for what we need.
it’s for this new artwork where the pixels are actually mp3 audio players.