Pd-dev June 2007

pd-dev@lists.iem.at

17 participants
92 discussions

compile partconv~ for intelmac
by Luigi Rensinghoff 30 Aug '07

30 Aug '07

Hi Developers, in particular Inte-Mac Users ;-) well probably i shouldnt even try, but i would like to test partconv on an intel mac. So i am trying to compile it myself, which, well.......i dont really have enough background knowledge. Maybe someone wants to help me anyway or has a pd_darwin version, to share... So i installed fftw3 with fink because it was missing, but now i encounter the next "stop" ---- gigimacbook:/Applications/PureData/Added_abs/partconv~-0.2 root# make pd_darwin cc -DPD -O3 -funroll-loops -fomit-frame-pointer -Wall -W -Wno-long- double -Wstrict-prototypes -Werror -Wno-unused -Wno-parentheses -Wno- switch -fno-common -I/Applications/PureData/pd-0.39-2/src -o partconv~.o -c partconv~.c cc -bundle -undefined suppress -flat_namespace -o partconv~.pd_darwin partconv~.o /usr/local/lib/libfftw3f.a -lc -lm i686-apple-darwin8-gcc-4.0.1: /usr/local/lib/libfftw3f.a: No such file or directory make: *** [partconv~.pd_darwin] Error 1 ... any idea ???

7 9

pointers
by Mathieu Bouchard 15 Jul '07

15 Jul '07

GEM, PDP, GridFlow, all use fake pointers. That is, pd defines A_POINTER as being a t_gpointer * and all of the above externals disregard this completely and send something else. It's because pd provides no other sensible means to send a pointer. Older versions of GridFlow were sending a pointer as 2 floats of integer value, and I was going to make it 3 floats when beginning to support 64-bit, but thought that although misusing A_POINTER was more evil in my book, at least it's being done with passing only one atom around, and I'm also happy to be doing the same evil as everybody else too. (I could have tried a plain reinterpret_cast<> so that it'd be 1 float in 32-bit or 2 floats in 64-bit, but I didn't want to think of the special float values such as +0, -0, +inf, -inf, NaN, denormals, and anything else. It could've been fine, but I didn't want to have to think about it.) _ _ __ ___ _____ ________ _____________ _____________________ ... | Mathieu Bouchard - tél:+1.514.383.3801, Montréal QC Canada

3 6

[ pure-data-Bugs-1607030 ] Pd crach when closeing patch with GOP enabled subpatch open
by SourceForge.net 09 Jul '07

09 Jul '07

Bugs item #1607030, was opened at 2006-12-01 19:24 Message generated for change (Settings changed) made by stffn You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=478070&aid=1607030&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: puredata Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: stffn (stffn) >Assigned to: Miller Puckette (millerpuckette) Summary: Pd crach when closeing patch with GOP enabled subpatch open Initial Comment: Pd crach when closing a patch with a GOP enabled subpatch or abstrasion is open. Attached is a patch that by following the procedure descibed in it will crash Pd. Note that the abstrasion isn't attached sine I can only attach one file. ---------------------------------------------------------------------- Comment By: stffn (stffn) Date: 2006-12-01 19:26 Message: Logged In: YES user_id=1658640 Originator: YES Attached is the abstracsion need to test the part/problem related to abstrasions. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=478070&aid=1607030&group_…

3 2

cleanup of CVS
by IOhannes m zmoelnig 29 Jun '07

29 Jun '07

i would like to file a request to sourceforge that they remove the ":pserver:anonymous@cvs.gridflow.ca:/" directory from the pd-repository. reasoning: - the entire tree is obviously supposed to be a mirror of another repository which is hosted somewhere else - the name is obviously a mistake; it should read "gridflow" instead of ":pserver:anonymous@cvs.gridflow.ca:/home/cvs/gridflow" - since the initial checkin one year ago not a single submit has been done if anyone has objections, they shall speak now. mfg.asdr. IOhannes

2 1

FYI: auto-build machines updated
by Hans-Christoph Steiner 27 Jun '07

27 Jun '07

Just an FYI: I updated all of the GNU/Linux machines from their respective repositories. On the Mac OS X machines, I updated all the fink packages. There have been some big changes in Debian/testing recently, so there might be some breakage... .hc ------------------------------------------------------------------------ ---- Computer science is no more related to the computer than astronomy is related to the telescope. -Edsger Dykstra

1 0

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

26 Jun '07

Well it seems like the way Pd handles tcl/tk you have to use a workaround to get Pd to display a carbon window correctly. The work around is to put this before creating a window: EventRef theEvent; EventTargetRef theTarget; theTarget = GetEventDispatcherTarget(); ReceiveNextEvent( 0, NULL, kEventDurationNoWait, true, &theEvent ); { SendEventToEventTarget( theEvent, theTarget); ReleaseEvent( theEvent ); } clock_delay(s_windowClock, 10); } Now I have to figure out how to destroy the window properly. Alain > > From: <nosehair911(a)bellsouth.net> > Date: 2007/06/25 Mon PM 04:05:24 EDT > To: <pd-dev(a)iem.at>, <tigital(a)mac.com> > Subject: Re: [PD-dev] Pd external-window crash > > Jamie, > I am running thru your 2004 apple developer posts. > http://lists.apple.com/archives/carbon-development/2004/Jan/msg00318.html > I am trying to figure out how you solved the carbon windowing issue you had with Gem for my > external but you never posted a solution. What did you finaly do to get it working? I am looking at the > GemWinCreateMac.cpp but cant find the solution. > Thanks, > Alain > > > > From: <nosehair911(a)bellsouth.net> > > Date: 2007/06/25 Mon AM 09:18:44 EDT > > To: <pd-dev(a)iem.at> > > Subject: Re: [PD-dev] Pd external-window crash > > > > > Well it looks like if I get a Gemwin opened first, then I can open an opencv window without a > > > crash... > > > > It seems like the window is made using Carbon. Is there any special way Pd handles Carbon > > > > windows that would cause this stall?

1 0

Trouble with memory+pointers
by Ed Kelly 26 Jun '07

26 Jun '07

Hi devs, I'm trying to rewrite some of my externals to be a bit more effe\icient, clear up after themselves and generally work more smoothly. I started with maskxor, because I really need this to work for the ICMC, and it's not working properly in certain situations. So I borrowed some code from zexy/src/drip.c and rewrote it. It compiled OK, but crashes PD. Can anyone tell me what is wrong with my code, and how to fix it? Best, Ed Lone Shark "Aviation" out now on http://www.pyramidtransmissions.com http://www.myspace.com/sharktracks --------------------------------- Yahoo! Answers - Get better answers from someone who knows. Tryit now.

2 3

Re: [PD-dev] [PD] Trouble with Memory and Pointers
by Frank Barknecht 26 Jun '07

26 Jun '07

Hallo, switching to pd-dev ... Ed Kelly hat gesagt: // Ed Kelly wrote: > I'm trying to rewrite some of my externals to be a bit more > efficient, clear up after themselves and generally work more > smoothly. I started with maskxor, because I really need this to work > for the ICMC, and it's not working properly in certain situations. > > So I borrowed some code from zexy/src/drip.c and rewrote it. It > compiled OK, but crashes PD. Can anyone tell me what is wrong with > my code, and how to fix it? No idea how to fix it, but I know where it crashes by compiling with "-g" and not "strip"ping the external: [Switching to Thread -1211164992 (LWP 2541)] 0xb73f5bd7 in maskxor_new (s=0x0, fmode=4.89521765e-34) at maskxor.c:226 226 SETFLOAT(&x->masking.maskr[0], 0); (gdb) bt #0 0xb73f5bd7 in maskxor_new (s=0x0, fmode=4.89521765e-34) at maskxor.c:226 #1 0x0809fcd6 in pd_typedmess () #2 0x080b3404 in sys_load_lib () Ciao -- Frank Barknecht _ ______footils.org_ __goto10.org__

1 0

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

25 Jun '07

Jamie, I am running thru your 2004 apple developer posts. http://lists.apple.com/archives/carbon-development/2004/Jan/msg00318.html I am trying to figure out how you solved the carbon windowing issue you had with Gem for my external but you never posted a solution. What did you finaly do to get it working? I am looking at the GemWinCreateMac.cpp but cant find the solution. Thanks, Alain > > From: <nosehair911(a)bellsouth.net> > Date: 2007/06/25 Mon AM 09:18:44 EDT > To: <pd-dev(a)iem.at> > Subject: Re: [PD-dev] Pd external-window crash > > > Well it looks like if I get a Gemwin opened first, then I can open an opencv window without a crash... > > > It seems like the window is made using Carbon. Is there any special way Pd handles Carbon > > > windows that would cause this stall? > > This is my last hurdle. I have my externals working but in order to use the carbon window I have to > open a gemwin first(not very profecional). I am using an opencv function for windowing that looks > like this: > > CV_IMPL int cvNamedWindow( const char* name, int flags ) > { > int result = 0; > CV_FUNCNAME( "cvNamedWindow" ); > if (!wasInitialized) > cvInitSystem(0, NULL); > > // to be able to display a window, we need to be a 'faceful' application > // http://lists.apple.com/archives/carbon-dev/2005/Jun/msg01414.html > static bool switched_to_faceful = false; > if (! switched_to_faceful) > { > ProcessSerialNumber psn = { 0, kCurrentProcess }; > OSStatus ret = TransformProcessType (&psn, kProcessTransformToForegroundApplication ); > > if (ret == noErr) > { > SetFrontProcess( &psn ); > switched_to_faceful = true; > } > else > { > fprintf(stderr, "Failed to tranform process type: %d\n", (int) ret); > fflush (stderr); > } > } > > __BEGIN__; > > WindowRef outWindow = NULL; > OSStatus err = noErr; > Rect contentBounds = {100,100,320,440}; > > CvWindow* window; > UInt wAttributes = 0; > > int len; > > const EventTypeSpec genericWindowEventHandler[] = { > { kEventClassMouse, kEventMouseMoved}, > { kEventClassMouse, kEventMouseUp}, > { kEventClassMouse, kEventMouseDown}, > { kEventClassWindow, kEventWindowClose }, > { kEventClassWindow, kEventWindowBoundsChanged }//FD > }; > > if( !name ) > CV_ERROR( CV_StsNullPtr, "NULL name string" ); > > if( icvFindWindowByName( name ) != 0 ){ > result = 1; > EXIT; > } > len = strlen(name); > CV_CALL( window = (CvWindow*)cvAlloc(sizeof(CvWindow) + len + 1)); > memset( window, 0, sizeof(*window)); > window->name = (char*)(window + 1); > memcpy( window->name, name, len + 1 ); > window->flags = flags; > window->signature = CV_WINDOW_MAGIC_VAL; > window->image = 0; > window->last_key = 0; > window->on_mouse = 0; > window->on_mouse_param = 0; > > window->next = hg_windows; > window->prev = 0; > if( hg_windows ) > hg_windows->prev = window; > hg_windows = window; > wAttributes = kWindowStandardDocumentAttributes | kWindowStandardHandlerAttribute | > kWindowLiveResizeAttribute; > > err = CreateNewWindow ( kDocumentWindowClass,wAttributes,&contentBounds,&outWindow); > if (err != noErr) > fprintf(stderr,"Error while creating the window\n"); > > SetWindowTitleWithCFString(outWindow,CFStringCreateWithCString > (NULL,name,kCFStringEncodingASCII)); > if (err != noErr) > fprintf(stdout,"Error SetWindowTitleWithCFString\n"); > > window->window = outWindow; > > err = InstallWindowEventHandler(outWindow, NewEventHandlerUPP(windowEventHandler), > GetEventTypeCount(genericWindowEventHandler), genericWindowEventHandler, outWindow, > NULL); > > ShowWindow( outWindow ); > result = 1; > > __END__; > return result; > } > > It seems to me that if this works outside of Pd then there must be something Pd needs in order to > display a carbon window properly. It seems that the "faceful" stuff was written in to prevent this from > happening but it doesnt work in Pd. I have been digging thru the Gem code to find out how it does it > but it is so intertwined with the openGL code that I cant seem to figure out how it displays a carbon > window corectly. Anyway if anyone has any ideas let me know. Until I figure this out I will be opening > up a gemwin along with my external:(. > Alain > > > _______________________________________________ > 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 25 Jun '07

25 Jun '07

> Well it looks like if I get a Gemwin opened first, then I can open an opencv window without a crash... > > It seems like the window is made using Carbon. Is there any special way Pd handles Carbon > > windows that would cause this stall? This is my last hurdle. I have my externals working but in order to use the carbon window I have to open a gemwin first(not very profecional). I am using an opencv function for windowing that looks like this: CV_IMPL int cvNamedWindow( const char* name, int flags ) { int result = 0; CV_FUNCNAME( "cvNamedWindow" ); if (!wasInitialized) cvInitSystem(0, NULL); // to be able to display a window, we need to be a 'faceful' application // http://lists.apple.com/archives/carbon-dev/2005/Jun/msg01414.html static bool switched_to_faceful = false; if (! switched_to_faceful) { ProcessSerialNumber psn = { 0, kCurrentProcess }; OSStatus ret = TransformProcessType (&psn, kProcessTransformToForegroundApplication ); if (ret == noErr) { SetFrontProcess( &psn ); switched_to_faceful = true; } else { fprintf(stderr, "Failed to tranform process type: %d\n", (int) ret); fflush (stderr); } } __BEGIN__; WindowRef outWindow = NULL; OSStatus err = noErr; Rect contentBounds = {100,100,320,440}; CvWindow* window; UInt wAttributes = 0; int len; const EventTypeSpec genericWindowEventHandler[] = { { kEventClassMouse, kEventMouseMoved}, { kEventClassMouse, kEventMouseUp}, { kEventClassMouse, kEventMouseDown}, { kEventClassWindow, kEventWindowClose }, { kEventClassWindow, kEventWindowBoundsChanged }//FD }; if( !name ) CV_ERROR( CV_StsNullPtr, "NULL name string" ); if( icvFindWindowByName( name ) != 0 ){ result = 1; EXIT; } len = strlen(name); CV_CALL( window = (CvWindow*)cvAlloc(sizeof(CvWindow) + len + 1)); memset( window, 0, sizeof(*window)); window->name = (char*)(window + 1); memcpy( window->name, name, len + 1 ); window->flags = flags; window->signature = CV_WINDOW_MAGIC_VAL; window->image = 0; window->last_key = 0; window->on_mouse = 0; window->on_mouse_param = 0; window->next = hg_windows; window->prev = 0; if( hg_windows ) hg_windows->prev = window; hg_windows = window; wAttributes = kWindowStandardDocumentAttributes | kWindowStandardHandlerAttribute | kWindowLiveResizeAttribute; err = CreateNewWindow ( kDocumentWindowClass,wAttributes,&contentBounds,&outWindow); if (err != noErr) fprintf(stderr,"Error while creating the window\n"); SetWindowTitleWithCFString(outWindow,CFStringCreateWithCString (NULL,name,kCFStringEncodingASCII)); if (err != noErr) fprintf(stdout,"Error SetWindowTitleWithCFString\n"); window->window = outWindow; err = InstallWindowEventHandler(outWindow, NewEventHandlerUPP(windowEventHandler), GetEventTypeCount(genericWindowEventHandler), genericWindowEventHandler, outWindow, NULL); ShowWindow( outWindow ); result = 1; __END__; return result; } It seems to me that if this works outside of Pd then there must be something Pd needs in order to display a carbon window properly. It seems that the "faceful" stuff was written in to prevent this from happening but it doesnt work in Pd. I have been digging thru the Gem code to find out how it does it but it is so intertwined with the openGL code that I cant seem to figure out how it displays a carbon window corectly. Anyway if anyone has any ideas let me know. Until I figure this out I will be opening up a gemwin along with my external:(. Alain

1 0

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