On Sun, 28 Aug 2011, Peter Brinkmann wrote:
Pointlessness is in the eye of the beholder. You may find many of the
libpd wrappers pointless because you're working in C and you're already
familiar with the functions in m_pd.h,
Well, actually, most of the time, I've been using my own C++
I think it's much simpler to just add a call to get/set the message limit, say:
int libpd_max_message_length();
void libpd_set_max_message_length(int length);
This doesn't break any current code.
Having to set a custom limit each time is far more tedious then just setting it
at startup.
On
On Wed, Aug 31, 2011 at 6:25 AM, Dan Wilcox danomat...@gmail.com wrote:
I think it's much simpler to just add a call to get/set the message limit,
say:
int libpd_max_message_length();
void libpd_set_max_message_length(int length);
This doesn't break any current code.
Having to set a
On Wed, Aug 31, 2011 at 11:27 AM, Peter Brinkmann
peter.brinkm...@googlemail.com wrote:
On Wed, Aug 31, 2011 at 9:01 AM, Dan Wilcox danomat...@gmail.com wrote:
On Aug 31, 2011, at 8:45 AM, Peter Brinkmann wrote:
On Wed, Aug 31, 2011 at 6:25 AM, Dan Wilcox danomat...@gmail.com wrote:
I
On Wed, Aug 31, 2011 at 9:01 AM, Dan Wilcox danomat...@gmail.com wrote:
On Aug 31, 2011, at 8:45 AM, Peter Brinkmann wrote:
On Wed, Aug 31, 2011 at 6:25 AM, Dan Wilcox danomat...@gmail.com wrote:
I think it's much simpler to just add a call to get/set the message limit,
say:
int
On Aug 31, 2011, at 8:45 AM, Peter Brinkmann wrote:
On Wed, Aug 31, 2011 at 6:25 AM, Dan Wilcox danomat...@gmail.com wrote:
I think it's much simpler to just add a call to get/set the message limit,
say:
int libpd_max_message_length();
void libpd_set_max_message_length(int length);
-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:
1. What sort of use case for long list messages to you have in mind?
2. Exactly how long would you need the
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);
}
then im calling the function from testApp.cpp and sending the
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;
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 2011-08-30 14:45, Dan Wilcox wrote:
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
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 2011-08-30 17:15, Dan Wilcox wrote:
Hah, oh IOhannes ...
Go to Ars Electronica and you'll see a little pillar next to the Donau that's
running from 9pm to 10pm every night. The live display is actually rendered
on the server deep inside the
Doh, ok sorry for being an ass ... on second thought I believe it's more like
80x60 RGB. I was reminded that the facade framebuffer is much lower res then
240x120 ... The OSC datagram size is set to 2 in Processing (oscP5), so 20
kB. OSC is designed to handle packet sizes for you, so I
On Tue, 30 Aug 2011, IOhannes m zmoelnig wrote:
why not simply resize the internal array as needed, starting with 32
elements and doubling whenever the limit is reached?
binbuf could be used for that, if the libc's realloc does in effect the
same thing. i think that this is the case with
On Tue, Aug 30, 2011 at 12:51 PM, Mathieu Bouchard ma...@artengine.cawrote:
On Tue, 30 Aug 2011, IOhannes m zmoelnig wrote:
why not simply resize the internal array as needed, starting with 32
elements and doubling whenever the limit is reached?
binbuf could be used for that, if the
On Tue, 30 Aug 2011, Peter Brinkmann wrote:
For the time being, I have something much simpler in mind: Just take the
current call int libpd_start_message(void), which returns the current
limit, and replace it with int libpd_start_message(int length), which
takes a parameter indicating the
On Tue, Aug 30, 2011 at 3:44 PM, Mathieu Bouchard ma...@artengine.cawrote:
On Tue, 30 Aug 2011, Peter Brinkmann wrote:
For the time being, I have something much simpler in mind: Just take the
current call int libpd_start_message(void), which returns the current
limit, and replace it with
Okay, I just pushed the latest version of libpd (including dynamic
allocation of the t_atom array for assembling list messages, i.e., no
a-priori limit of the message size). I also updated the Android and iOS
branches as well as the wiki.
Cheers,
Peter
On Tue, Aug 30, 2011 at 1:25 PM,
- Original Message -
From: Mathieu Bouchard ma...@artengine.ca
To: Jonathan Wilkes jancs...@yahoo.com
Cc: Dan Wilcox danomat...@gmail.com; PD List pd-list@iem.at
Sent: Monday, August 29, 2011 1:19 AM
Subject: Re: [PD] sending image from of / libpd
On Sun, 28 Aug 2011, Jonathan
On Mon, Aug 29, 2011 at 1:23 AM, Dan Wilcox danomat...@gmail.com wrote:
No, I'm talking about sending a list or typed message with libpd as in:
[list 1 2 3 4 ... 32
|
[s toC++]
The print messaging isn't limited as far as I know.
That's right. The only part that imposes a limit on the
Whoah whoah hold on. I'm not suggesting to dump the message sending API. I'm
only asking for the ability to set the max message size. In most cases 32 is
plenty. The *t_atom send func is sufficient for more advanced users. I like the
message API and will use it as the default anyway.
enohp ym
Here's the problem that it is supposed to solve: You want to translate a
heterogeneous list of objects in Java into an array of type t_atom in C.
That's all.
Btw, did you look at Pascal Gauthier's library ?
Yes, but I think it solves a different problem. In particular, I don't want
to
On Mon, Aug 29, 2011 at 1:15 AM, Mathieu Bouchard ma...@artengine.cawrote:
[...]
and also, I just read your libpd_read_array and libpd_write_array functions.
They don't work in 64-bit mode, in which sizeof(t_word) != sizeof(t_float).
Okay, should be fixed now. I just pushed the latest
That's a good question.
Hrm, well you can easily read and write to arrays which are naturally 1
dimensional. I would first try flattening the image by writing the pixel buffer
into a float array. Then send the width and height as well for reading it back
in pd. There currently isn't a way to
On Sat, Aug 27, 2011 at 11:16 PM, Mathieu Bouchard ma...@artengine.cawrote:
On Sun, 21 Aug 2011, Hans-Christoph Steiner wrote:
I think with the libpd API, you can write to Pd arrays. That's probably
you're best bet.
You must be meaning the pd API (m_pd.h).
There's nothing
On Sun, 28 Aug 2011, Peter Brinkmann wrote:
Can you bypass many of the functions in libpd and use m_pd.h directly?
Sure, but then again maybe m_pd.h is pointless because you can just hack
your binaries with a hex editor. That doesn't mean that that's a good
level of abstraction to work at.
On Sun, 28 Aug 2011, Dan Wilcox wrote:
and I could imagine sending a giant list would be alot slower then using
an array.
A list is passed by pointer. The first thing that can be slower, is having
to read the atomtype because list elements can be things other than
floats. The second thing
On Sun, Aug 28, 2011 at 1:26 PM, Mathieu Bouchard ma...@artengine.cawrote:
On Sun, 28 Aug 2011, Peter Brinkmann wrote:
Can you bypass many of the functions in libpd and use m_pd.h directly?
Sure, but then again maybe m_pd.h is pointless because you can just hack
your binaries with a hex
On Sun, 28 Aug 2011, Peter Brinkmann wrote:
One major simplification is the use of built-in data types vs custom
structs and unions.
You mean you simplify by making things more low-level ?
const char * is rarely ever called high-level...
With this transition to built-in data types, you can
On Sun, Aug 28, 2011 at 5:04 PM, Mathieu Bouchard ma...@artengine.cawrote:
On Sun, 28 Aug 2011, Peter Brinkmann wrote:
One major simplification is the use of built-in data types vs custom
structs and unions.
You mean you simplify by making things more low-level ?
const char * is rarely
I was talking about sending a large list through libpd which, I assume, is
doing some sort of copying of floats as it translates from the libpd api to the
internal pd api. At least that's what my ofxPD wrapper does, passes each float
by value to libpd. Someone correct me if I'm wrong.
Besides,
On Mon, 29 Aug 2011, Dan Wilcox wrote:
I was talking about sending a large list through libpd which, I assume,
is doing some sort of copying of floats as it translates from the libpd
api to the internal pd api.
Oh, yeah... if you use z_libpd.h, it copies the floats, whereas with
m_pd.h, you
- Original Message -
From: Mathieu Bouchard ma...@artengine.ca
To: Dan Wilcox danomat...@gmail.com
Cc: PD List pd-list@iem.at
Sent: Monday, August 29, 2011 12:54 AM
Subject: Re: [PD] sending image from of / libpd
On Mon, 29 Aug 2011, Dan Wilcox wrote:
I was talking about
On Sun, 28 Aug 2011, Peter Brinkmann wrote:
Well, I'm taking a complicated implementation detail (t_symbol)
but t_symbol is a higher-level structure for wrapping the const char *.
:}
I thought I had already explained this when we had our little chat over
at pd-everywhere, but I'll try
On Sun, 28 Aug 2011, Jonathan Wilkes wrote:
With z_libpd.h, you have an artificial limit of 32 atoms per message
I must be misunderstanding what you've written, because it would break
trivial patches:
[osc~ 440]
|
| [bang(
|/
[print~]
Where's the 32 atoms in a message in your example ?
AM, Jonathan Wilkes wrote:
- Original Message -
From: Mathieu Bouchard ma...@artengine.ca
To: Dan Wilcox danomat...@gmail.com
Cc: PD List pd-list@iem.at
Sent: Monday, August 29, 2011 12:54 AM
Subject: Re: [PD] sending image from of / libpd
On Mon, 29 Aug 2011, Dan Wilcox
On Sun, 21 Aug 2011, Hans-Christoph Steiner wrote:
I think with the libpd API, you can write to Pd arrays. That's probably
you're best bet.
You must be meaning the pd API (m_pd.h).
There's nothing libpd-specific (z_libpd.h) about arrays.
It's a good thing, because IMHO, many of the
On Sat, 20 Aug 2011, ronni montoya wrote:
Hi , Do anybody is working with openframeoworks and libpd? i would like
to develop an application that interpret pixels as sounds using libpd
addon on openframeworks. I was wondering which would be the best way for
sending images(opencvimages ) or
I think with the libpd API, you can write to Pd arrays. That's
probably you're best bet.
.hc
On Aug 20, 2011, at 6:11 PM, ronni montoya wrote:
Hi , Do anybody is working with openframeoworks and libpd? i would
like to develop an application that interpret pixels as sounds using
libpd
Hi , Do anybody is working with openframeoworks and libpd? i would
like to develop an application that interpret pixels as sounds using
libpd addon on openframeworks.
I was wondering which would be the best way for sending
images(opencvimages ) or pixels arrrays from openframeworks to pd
using
39 matches
Mail list logo
