Pd-dev June 2007

pd-dev@lists.iem.at

17 participants
92 discussions

Re: [PD-dev] Pd external-window crash
by nosehair911＠bellsouth.net 23 Jun '07

23 Jun '07

Well it looks like if I get a Gemwin opened first, then I can open an opencv window without a crash. Does anyone know what specifically does Gem do to get Pd to open a carbon window without a crash? Alain > > From: <nosehair911(a)bellsouth.net> > Date: 2007/06/22 Fri PM 02:37:30 EDT > To: <pd-dev(a)iem.at> > Subject: Re: [PD-dev] Pd external-window crash > > It seems like the window is made using Carbon. Is there any special way Pd handles Carbon > windows that would cause this stall? I can also compile opencv to use X11 windowing thru finks gdk. > Would Pd handle that better? > Alain > > > > > From: <nosehair911(a)bellsouth.net> > > Date: 2007/06/22 Fri AM 10:53:54 EDT > > To: <pd-dev(a)iem.at> > > Subject: [PD-dev] Pd external-window crash > > > > I am trying to write an external library that uses opencv. I am using os x 10.4.9 and Pd extended > 0.3.9. > > To display images and movies opencv uses a call to a window. I have a standalone terminal > program > > that call the window and displays the image correctly. > > When I try to call a window from within Pd I get a window followed by a long stall and eventually a > crash. > > On my dock I get a second Pd app with no icon like when I open a Gemwin in Gem. The original > app > > seems responsive but the second app seems to be in a "I want to crash state" untill it does. > > Does anyone how I can figure out what is happening here? Is it a lib that Pd is lacking? What is the > > best way to bugtrack this? > > I know that Pd knows where the opencv libs are at because other opencv functions work flawlessly. > > Thanks for any input. > > Alain > > > > > > _______________________________________________ > > PD-dev mailing list > > PD-dev(a)iem.at > > http://lists.puredata.info/listinfo/pd-dev > > > > > _______________________________________________ > PD-dev mailing list > PD-dev(a)iem.at > http://lists.puredata.info/listinfo/pd-dev >

1 0

Re: [PD-dev] Pd external-window crash
by nosehair911＠bellsouth.net 22 Jun '07

22 Jun '07

It seems like the window is made using Carbon. Is there any special way Pd handles Carbon windows that would cause this stall? I can also compile opencv to use X11 windowing thru finks gdk. Would Pd handle that better? Alain > > From: <nosehair911(a)bellsouth.net> > Date: 2007/06/22 Fri AM 10:53:54 EDT > To: <pd-dev(a)iem.at> > Subject: [PD-dev] Pd external-window crash > > I am trying to write an external library that uses opencv. I am using os x 10.4.9 and Pd extended 0.3.9. > To display images and movies opencv uses a call to a window. I have a standalone terminal program > that call the window and displays the image correctly. > When I try to call a window from within Pd I get a window followed by a long stall and eventually a crash. > On my dock I get a second Pd app with no icon like when I open a Gemwin in Gem. The original app > seems responsive but the second app seems to be in a "I want to crash state" untill it does. > Does anyone how I can figure out what is happening here? Is it a lib that Pd is lacking? What is the > best way to bugtrack this? > I know that Pd knows where the opencv libs are at because other opencv functions work flawlessly. > Thanks for any input. > Alain > > > _______________________________________________ > PD-dev mailing list > PD-dev(a)iem.at > http://lists.puredata.info/listinfo/pd-dev >

1 0

changing netsend
by Mathieu Bouchard 22 Jun '07

22 Jun '07

On Fri, 22 Jun 2007, Alex Q wrote: > I think that the "list", "float" and "symbol" selectors are somewhat > obvious and should be types, not selectors. Those selectors bring some > ankward constructs like that. For this (pd!) software, it might be too > late, but for the next dataflow generation, it is not... float and symbol and pointer correspond to atomtypes and are used because pd is designed to accept those atoms using three separate methods; the type-signature could be considered part of the selector (it is in C++/Java) or could be considered part of the dispatch (it is in LISP). In pd it's neither (as in Python/Ruby/Perl/etc) because because it still has to be split in three methods, it's exposed right in the user's face. Instead I'd prolly enjoy a selector or atom called "atom" or "value". pd's "list" selector does not correspond to any atom type. What do you want to do with that? _ _ __ ___ _____ ________ _____________ _____________________ ... | Mathieu Bouchard - tél:+1.514.383.3801, Montréal QC Canada

1 0

Pd external-window crash
by nosehair911＠bellsouth.net 22 Jun '07

22 Jun '07

I am trying to write an external library that uses opencv. I am using os x 10.4.9 and Pd extended 0.3.9. To display images and movies opencv uses a call to a window. I have a standalone terminal program that call the window and displays the image correctly. When I try to call a window from within Pd I get a window followed by a long stall and eventually a crash. On my dock I get a second Pd app with no icon like when I open a Gemwin in Gem. The original app seems responsive but the second app seems to be in a "I want to crash state" untill it does. Does anyone how I can figure out what is happening here? Is it a lib that Pd is lacking? What is the best way to bugtrack this? I know that Pd knows where the opencv libs are at because other opencv functions work flawlessly. Thanks for any input. Alain

1 0

Re: [PD-dev] sending data out using sprintf
by nosehair911＠bellsouth.net 22 Jun '07

22 Jun '07

Well for never passing pointers around you have some great insight. That did it. Thanks.. The final outcode for any interested parties: x->in_frame = (IplImage *)strtol(s->s_name, NULL, 0); Now I have another snag, but thats in another email. Alain > > From: Bryan Jurish <moocow(a)ling.uni-potsdam.de> > Date: 2007/06/22 Fri AM 05:52:47 EDT > To: nosehair911(a)bellsouth.net > CC: pd-dev(a)iem.at > Subject: Re: [PD-dev] sending data out using sprintf > > moin Alain, > > I've never passed pointers around between externals myself, but... > > On 2007-06-22 04:57:35, <nosehair911(a)bellsouth.net> appears to have written: > > I am trying to send some data out of an outlet using a symbol pointer. I have tried using sprintf like > > martin suggested with little succes. I am sure I am the one doing something wrong. I am getting a > > pointer symbol but I am not able to convert the pointer back. In external#1 I have: > > > > The out ---------------- > > IplImage *frame; > > char symstr[10]; > > t_symbol *sym; > > sprintf(symstr, "%p", frame); > > sym = gensym(symstr); > > outlet_symbol(x->m_outFrames, sym); > > > > With this I get an address like: > > symbol 0x1159da0 > > ... looks kosher to me ... > > > ...but on the conversion in external#2 I get the problem. The conversion looks like: > > > > The in----------------------- > > IplImage *in_frame; > > x->in_frame = (IplImage *)atol(s->s_name); > > post("frame %s", x->in_frame); > > post("symbol %s",s->s_name); > > > > ...with this I get this: > > frame (null) > > symbol 0x1159da0 > > first of all, you probably want to post("frame %p", x->in_frame), rather > than "%s". Second, in the docs for my atol (here under linux|glibc), I see: > > -- Function: long int atol (const char *STRING) > This function is similar to the `strtol' function with a BASE > argument of `10', except that it need not detect overflow errors. > The `atol' function is provided mostly for compatibility with > existing code; using `strtol' is more robust. > > ... so if your atol() is similar, then trying to convert a hex string to > a pointer with atol() is an exercise in futility (since in general, > 10!=16). strtol() ought to work better, auto-detetcting the hex-iness > of the string by its '0x' prefix. You might also just want to roll out > the big guns and use the "%x" format to scanf(), but strtol() is likely > to be the better way to go. > > marmosets, > Bryan > > -- > Bryan Jurish "There is *always* one more bug." > jurish(a)ling.uni-potsdam.de -Lubarsky's Law of Cybernetic Entomology >

1 0

sending data out using sprintf
by nosehair911＠bellsouth.net 22 Jun '07

22 Jun '07

I am trying to send some data out of an outlet using a symbol pointer. I have tried using sprintf like martin suggested with little succes. I am sure I am the one doing something wrong. I am getting a pointer symbol but I am not able to convert the pointer back. In external#1 I have: The out ---------------- IplImage *frame; char symstr[10]; t_symbol *sym; sprintf(symstr, "%p", frame); sym = gensym(symstr); outlet_symbol(x->m_outFrames, sym); With this I get an address like: symbol 0x1159da0 ...but on the conversion in external#2 I get the problem. The conversion looks like: The in----------------------- IplImage *in_frame; x->in_frame = (IplImage *)atol(s->s_name); post("frame %s", x->in_frame); post("symbol %s",s->s_name); ...with this I get this: frame (null) symbol 0x1159da0 So I'm getting the symbol in, but its not converting into "in_fame." Does anyone know what I am doing wrong or a way to use Pd's A_POINTER. I have looked at Gem and pdp but I cant figure it out. Thanks, Alain

3 2

[ pure-data-Patches-1739655 ] automatically "send" lists with [udpsend]
by SourceForge.net 21 Jun '07

21 Jun '07

Patches item #1739655, was opened at 2007-06-19 13:09 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=478072&aid=1739655&group_… Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: externals Group: feature Status: Open Resolution: None Priority: 5 Private: No Submitted By: IOhannes m zmölnig (zmoelnig) Assigned to: Martin Peach (mrpeach) Summary: automatically "send" lists with [udpsend] Initial Comment: with this patch one can use [udpsend] to send data without having to prepend the "send" selector to each message. everything that is a "list" will automatically be "send". e.g. "1 2 3 59" is the same as "send 1 2 3 59" "list /tmp/test.txt" is the same as "send /tmp/test.txt" reasoning: - when dealing with a lot of messages to be sent, it quickly becomes tiresome and cpu-consuming to have to prepend "send" to every message. - lists are the native type of "data" in pd (as opposed to "commands"); [udpsend]s native way to deal with "data" is to send it (special behaviour like (dis)connecting is done via special messages) might be that my reasoning is not completely in-line with pd-vanilla (compare the "send" message to [netsend]) if this gets accepted, [tcpsend] should also be modified accordingly ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=478072&aid=1739655&group_…

4 3

[ pure-data-Patches-1739650 ] add default OSC-path to packOSC
by SourceForge.net 21 Jun '07

21 Jun '07

Patches item #1739650, was opened at 2007-06-19 12:58 Message generated for change (Comment added) made by zmoelnig You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=478072&aid=1739650&group_… Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: externals Group: feature >Status: Closed >Resolution: Accepted Priority: 5 Private: No Submitted By: IOhannes m zmölnig (zmoelnig) Assigned to: Martin Peach (mrpeach) Summary: add default OSC-path to packOSC Initial Comment: this patch adds a message "prefix <symbol>" to the [packOSC] object, which adds a default OSC-prefix to all OSC-paths. e.g. [prefix /bla, send /forth 1 2 3( will output the binary representation of the OSC-message "/bla/forth 1 2 3" this is only for convenience, but when you are transmitting large numbers of osc-messages, prefixing each and everyone via pd's internal string-manipulation mechanisms can be rather slow. this should be faster... ---------------------------------------------------------------------- >Comment By: IOhannes m zmölnig (zmoelnig) Date: 2007-06-21 09:39 Message: Logged In: YES user_id=564396 Originator: YES thanks (closing) ---------------------------------------------------------------------- Comment By: Martin Peach (mrpeach) Date: 2007-06-20 22:42 Message: Logged In: YES user_id=919007 Originator: NO OK, done. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=478072&aid=1739650&group_…

1 0

[ pure-data-Patches-1739651 ] convert non-"send" messages to OSC-messages via [packOSC]
by SourceForge.net 21 Jun '07

21 Jun '07

Patches item #1739651, was opened at 2007-06-19 13:02 Message generated for change (Comment added) made by zmoelnig You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=478072&aid=1739651&group_… Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: externals Group: feature >Status: Closed >Resolution: Accepted Priority: 5 Private: No Submitted By: IOhannes m zmölnig (zmoelnig) Assigned to: Martin Peach (mrpeach) Summary: convert non-"send" messages to OSC-messages via [packOSC] Initial Comment: this patch adds the ability to [packOSC] to send messages even when they are not prefixed with the "send" selector. messages to be converted into osc-packets must have a selector starting with "/", which will become the OSC-path. example: "/bi/ba/bo 1 2 3" is the same as "send /bi/ba/bo 1 2 3" reasoning: - when dealing with large numbers of osc-messages, prepending "send" to each of them can become rather tireseome and cpu-consuming - the "send" label is a suboptimal choice anyhow ([packOSC] does not know anything about "send"ing) ---------------------------------------------------------------------- >Comment By: IOhannes m zmölnig (zmoelnig) Date: 2007-06-21 09:39 Message: Logged In: YES user_id=564396 Originator: YES thanks (of coures it was not my suggestion to remove the explitic "send" message (for compat issues)) ---------------------------------------------------------------------- Comment By: Martin Peach (mrpeach) Date: 2007-06-20 22:39 Message: Logged In: YES user_id=919007 Originator: NO Done, also 'send' is still there for backwards compatibility. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=478072&aid=1739651&group_…

1 0

[ pure-data-Patches-1739655 ] automatically "send" lists with [udpsend]
by SourceForge.net 21 Jun '07

21 Jun '07

Patches item #1739655, was opened at 2007-06-19 13:09 Message generated for change (Comment added) made by zmoelnig You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=478072&aid=1739655&group_… Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: externals Group: feature >Status: Closed >Resolution: Accepted Priority: 5 Private: No Submitted By: IOhannes m zmölnig (zmoelnig) Assigned to: Martin Peach (mrpeach) Summary: automatically "send" lists with [udpsend] Initial Comment: with this patch one can use [udpsend] to send data without having to prepend the "send" selector to each message. everything that is a "list" will automatically be "send". e.g. "1 2 3 59" is the same as "send 1 2 3 59" "list /tmp/test.txt" is the same as "send /tmp/test.txt" reasoning: - when dealing with a lot of messages to be sent, it quickly becomes tiresome and cpu-consuming to have to prepend "send" to every message. - lists are the native type of "data" in pd (as opposed to "commands"); [udpsend]s native way to deal with "data" is to send it (special behaviour like (dis)connecting is done via special messages) might be that my reasoning is not completely in-line with pd-vanilla (compare the "send" message to [netsend]) if this gets accepted, [tcpsend] should also be modified accordingly ---------------------------------------------------------------------- >Comment By: IOhannes m zmölnig (zmoelnig) Date: 2007-06-21 09:37 Message: Logged In: YES user_id=564396 Originator: YES thanks (closing) ---------------------------------------------------------------------- Comment By: Martin Peach (mrpeach) Date: 2007-06-20 22:38 Message: Logged In: YES user_id=919007 Originator: NO OK,good idea. I changed udpsend, also made the same change to tcpsend, tcpclient and tcpserver. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=478072&aid=1739655&group_…

1 0

← Newer
1
2
3
4
5
6
7
8
9
10
Older →

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

2003

2002

Pd-dev June 2007