For gray values this should work.
On Aug 30, 2011, at 6:56 AM, ronni montoya wrote:
i solved this creating a fuction called send inside AppCore:
void AppCore::send(unsigned char *pixels) {
for(int i = 0; i < array1.size(); i++) array1[i] = pixels[i]* 1;
pd.writeArray("array1", array1); }
Here I would send a resize message to the array if the array length is different from you image size. Also, I'm assuming you set the correct size for the array1 vector to be the size of the image pixel buffer aka width*height ...
void AppCore::send(unsigned char *pixels) {
// check array length
if(array1.size() != pd.getArrayLen("array1") {
//
// send resize message to array1
//
// aka [ ; array1 resize # <
//
pd. << StartMsg("array1") << "resize" << pixelLen << Finish();
}
for(int i = 0; i < array1.size(); i++)
array1[i] = pixels[i];
pd.writeArray("array1", array1);
}
then im calling the function from testApp.cpp and sending the pixels from a opecv gray image.
void testApp::draw() { core.send(grayImage.getPixels());
}
I'd send the image to pd in the core.update() function. The whole point of the AppCore wrapper classes is to be able to write the same core app code for both desktop and iOS, since iOS requires a Obj-C file for the main Application delegate aka example/src/ios/testApp.m.
What do you guys think, maybe theres a more effective way?
Dunno. Try it out and let us know. I'm pretty sure it may be slow to send a largish image > 640x480, so I'd start out at 120x240 or so. I've streamed realtime color video at that size using binary blobs in OSC without a problem, so I can't imagine small images being too slow ... then again I haven't tried it with libpd.
cheers
R.
2011/8/30 IOhannes m zmoelnig zmoelnig@iem.at:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On 2011-08-29 20:51, Peter Brinkmann wrote:
Maybe we can have a poll and come up with a better estimate. Here are a few questions:
- What sort of use case for long list messages to you have in mind?
- Exactly how long would you need the list to be?
- Is this really a use case for list messages or would it make more sense
to write to an array instead?
If we converge to a reasonable number, that'll be the new limit. Otherwise, the entire approach may have to go.
personally i do think that any fixed limit is going to impose troubles.
afaict, the main idea here is to provide an easy to use API, combined with some performance.
somebody _will_ reach your hard limit, and i think that telling them to either switch from the "foolproof API" to "export mode" or to redesign their patches just because they called "add_element()" once too often will not do.
why not simply resize the internal array as needed, starting with 32 elements and doubling whenever the limit is reached?
fgasdr IOhannes -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
iEYEARECAAYFAk5ckYcACgkQkX2Xpv6ydvQ85gCfWJcNIzEGnhz9hdnz/XBuRYuI TMEAnjfytStl5sFDqkJ9HppZ9XQylgni =HvJ0 -----END PGP SIGNATURE-----
Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Dan Wilcox danomatika.com robotcowboy.com