Re: [PD-dev] flext and gnu/windows - 'undefined reference' with pd global vars?
On 04/05/2011 01:14 AM, Hans-Christoph Steiner wrote: 'undefined reference' generally means that the linker has found symbols in the .o files that it can't find a reference to. I.e. take the function 'foo', if myobject.o uses foo() from the bar lib, and the bar lib is not including the linking, because its not specified or not in the lib path, the you'll get an 'undefined reference'. Basically it means it can't find the code that matches a given symbol (i.e. function, variable, etc). .hc yes, i'm quite aware of what causes an 'undefined reference', but the flext lib should already be linking to pd.dll with -lpd and the locations -L check out.. it only complains of a small handfull of the many symbols that flext uses from pd (it is afterall a programming interface which uses pds api extensively). the problem is caused only by the global data defined in the pd.dll (garray_class, s_float, etc.) not by function protoypes gr~~~ I keep running into that. I think you have to #define MSW so this bit of m_pd.h gets included: #ifdef MSW #ifdef PD_INTERNAL #define EXTERN __declspec(dllexport) extern #else #define EXTERN __declspec(dllimport) extern #endif /* PD_INTERNAL */ #else #define EXTERN extern #endif /* MSW */ Martin ___ Pd-dev mailing list Pd-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
Re: [PD-dev] odd key object behavior under Linux
It probably happens when you get two keydowns in the space of one Pd event loop. The second is output at the same time. The same thing happens with [metro] banging serial data into [comport] or [midiout]. The metro rate is quantized to the event loop rate, so individual bangs are irregularly spaced but the mean time over many bangs is perfect. The only way to get perfect timing is to use signals, messages are always handled after the sound has been computed. So if you don't like it you could slow down your keyboard repeat rate to slower than Pd, or use a microphone to detect the keypresses ;) Martin Ico wrote: It all started when I noticed that my threaded version of coll object tended to freeze Pd at apparently random points. As it turns out, I was testing its robustness simply by passing a key into a read/write message and holding the key down to generate a large number of requests per second and the [key] object at times seemed to spit out (while autorepeat of the pressed key was taking place) two outputs at the same time which in turn crashed Pd as threaded coll object did not handle this gracefully. I've since fixed the coll object but the key behavior baffles me. The double redundant output is apparent in both rt and non-rt Pd (on Ubuntu 9.10 using rt kernel on the MSI Wind atom netbook) and below is the simplest patch to invoke this. Basically, I am measuring the aforesaid time delta between broadcast strokes using timer object and printing it out to console. #N canvas 549 345 383 297 10; #X obj 162 83 key; #X obj 162 107 sel 32; #X text 208 108 space; #X obj 162 145 timer; #X obj 162 182 print; #X connect 0 0 1 0; #X connect 1 0 3 1; #X connect 1 0 3 0; #X connect 3 0 4 0; So, while certainly the fact that threaded version of coll wasn't handling gracefully multiple redundant requests at the same time was a bug (which I am hoping has been fixed now), I am wondering whether the aforesaid [key] behavior might be a bug as it seems to me that keystrokes of the same key, even if the key is autorepeating should never have a time delta of zero. Naturally, one can always put a speedlim after the [key] object but that might result in a truncated output of fast typing. I would greatly appreciate it if others can test this to see if they are getting the same results. FWIW, allowing this kind of key behavior in more complex patches did result in the pd-gui communication tearing with the stderr reporting several truncated messages before crashing. Due to their complexity and unpredictability of a point where tearing would occur I am not sure where the problem might be stemming from but it is undoubtedly at least in part instigated by double redundant output from the key object possibly in conjunction with objects that may have not provided graceful handling of such requests. NB: I only tested the same patch on Win platform and there it does not exhibit this problem. Any thoughts would be most appreciated. Best wishes, Ico ___ Pd-dev mailing list Pd-dev@iem.at http://lists.puredata.info/listinfo/pd-dev ___ Pd-dev mailing list Pd-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
Re: [PD-dev] [PD] odd key object behavior under Linux
Yes, the OS also has its own event loop, which might be more responsible for that kind of timing, as it isn't running at a fixed rate and keyboard is probably a lower priority than mouse or network events. Martin Ico wrote: Many thanks for the explanation! What seems weird, however, is how divergent time delta between repeats is. On Windows it is always around 30ms (at least on my hardware) whereas on Linux it goes between 0, including 1.4ms and up to 50+. Even when accounting for jitter between two events I cannot imagine that they oscillate that much (unless my flavor of kernel/hardware treats keypress timing like a dirt :-). Best wishes, Ico martin.pe...@sympatico.ca wrote: It probably happens when you get two keydowns in the space of one Pd event loop. The second is output at the same time. The same thing happens with [metro] banging serial data into [comport] or [midiout]. The metro rate is quantized to the event loop rate, so individual bangs are irregularly spaced but the mean time over many bangs is perfect. The only way to get perfect timing is to use signals, messages are always handled after the sound has been computed. So if you don't like it you could slow down your keyboard repeat rate to slower than Pd, or use a microphone to detect the keypresses ;) Martin Ico wrote: It all started when I noticed that my threaded version of coll object tended to freeze Pd at apparently random points. As it turns out, I was testing its robustness simply by passing a key into a read/write message and holding the key down to generate a large number of requests per second and the [key] object at times seemed to spit out (while autorepeat of the pressed key was taking place) two outputs at the same time which in turn crashed Pd as threaded coll object did not handle this gracefully. I've since fixed the coll object but the key behavior baffles me. The double redundant output is apparent in both rt and non-rt Pd (on Ubuntu 9.10 using rt kernel on the MSI Wind atom netbook) and below is the simplest patch to invoke this. Basically, I am measuring the aforesaid time delta between broadcast strokes using timer object and printing it out to console. #N canvas 549 345 383 297 10; #X obj 162 83 key; #X obj 162 107 sel 32; #X text 208 108 space; #X obj 162 145 timer; #X obj 162 182 print; #X connect 0 0 1 0; #X connect 1 0 3 1; #X connect 1 0 3 0; #X connect 3 0 4 0; So, while certainly the fact that threaded version of coll wasn't handling gracefully multiple redundant requests at the same time was a bug (which I am hoping has been fixed now), I am wondering whether the aforesaid [key] behavior might be a bug as it seems to me that keystrokes of the same key, even if the key is autorepeating should never have a time delta of zero. Naturally, one can always put a speedlim after the [key] object but that might result in a truncated output of fast typing. I would greatly appreciate it if others can test this to see if they are getting the same results. FWIW, allowing this kind of key behavior in more complex patches did result in the pd-gui communication tearing with the stderr reporting several truncated messages before crashing. Due to their complexity and unpredictability of a point where tearing would occur I am not sure where the problem might be stemming from but it is undoubtedly at least in part instigated by double redundant output from the key object possibly in conjunction with objects that may have not provided graceful handling of such requests. NB: I only tested the same patch on Win platform and there it does not exhibit this problem. Any thoughts would be most appreciated. Best wishes, Ico ___ Pd-dev mailing list Pd-dev@iem.at http://lists.puredata.info/listinfo/pd-dev ___ pd-l...@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list ___ Pd-dev mailing list Pd-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
Re: [PD-dev] [comport] errors
I just committed to svn a check for valid handle before any write can happen. Strange that it didn't give errors before though, the handle would be -1. Martin hc wrote: I'm just trying out the new comport object in trunk, and it seems that it no longer outputs an error when you try to send bytes to a closed serial port, even with [verbose 1(. While the earlier messages were less than ideal, I think there should be some kind of notification if you send bytes to a closed serial port. It might even be worth making it a pd_error() so you can easily find which object has the problem, but I am not sure. .hc kill your television ___ Pd-dev mailing list Pd-dev@iem.at http://lists.puredata.info/listinfo/pd-dev ___ Pd-dev mailing list Pd-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
Re: [PD-dev] udpreceive~
Hi Michal, I don't think it's any bug with Pd, it's just that you are suffering from dropped packets. The packets are sent by UDP, which sends each packet once and forgets about it, unlike TCP which checks that the other end actually received the packet and resends as necessary. So it seems that [udpreceive~] sometimes tries to read a data packet as a header packet and gets confused. Here udpreceive~: EFAULT: 0x832dda0 1900572 1576380 it thinks that it wants to read 1576380 bytes, which is too many for the buffer. In other cases the size is probably acceptable but Pd crashes because it's trying to access memory out of its allowed space. I think that a first step would be to have [udpreceive~] check that the header is sane before attempting to use it. I'll try to do that today. Martin From: m...@artengine.ca Date: Thu, 11 Mar 2010 12:02:04 -0500 To: pd-dev@iem.at Subject: [PD-dev] udpreceive~ Hello Martin and others, I think I should bring this issue to the general pd-dev attention because there seem to be some serious glitches in the way pd interacts with externals that try to send audio signal over the network. Just to put everyone on a more or less the same page, I have been trying to use pd in a situation where several musician will improvise together over a local network. The main requirement is that the playing happens over WiFi. I had netsend~/netreceive~ crash regularly and Mr Peach's udpsend~/receive~ appeared on my radar. They, too, crash, on WiFi networks. Using them on wired connections seems to be quite reliable (but I have not tested with wires extensively). It seems that udpreceive~ is the source of crashes. I played quite a bit with udpreceive~ but I cannot put my finger on any particular bug. Even running just one udpreceive~ listening on 1 channel it will eventually crash. I get sometimes this mysterious message: error: udpreceive~: incoming stream has too many channels (2) Even if I send 1 channel and receive 1. At some point this happended to print into the pd console as well udpreceive~: EFAULT: 0x832dda0 1900572 1576380 udpreceive~: recv data: Bad address (14) The above messages are, I guess, udpreceive~ specific gdb backtraces show that the problem lies deeper: #0 0x01834f21 in ?? () from /home/mis/pd-externals/udpreceive~.pd_linux #1 0x080c9335 in dsp_tick () at d_ugen.c:336 #2 0x080b6821 in sched_tick (next_sys_time=19501527040) at m_sched.c:382 #3 0x080b799d in m_pollingscheduler () at m_sched.c:482 #4 m_mainloop () at m_sched.c:558 #5 0x080ba96f in sys_main (argc=2, argv=0xb314) at s_main.c:307 #6 0x080c3fff in main (argc=Cannot access memory at address 0xb5ff0d00 but also occasional: 0x080bace5 in sys_domicrosleep (microsec=, pollem=) at s_inter.c:171 171 s_inter.c: No such file or directory. in s_inter.c #1 0x080bbfe1 in sys_pollgui () at s_inter.c:833 #2 0x080b776f in m_pollingscheduler () at m_sched.c:488 #3 m_mainloop () at m_sched.c:558 #4 0x080ba96f in sys_main (argc=2, argv=0xb314) at s_main.c:307 #5 0x080c3fff in main (argc=Cannot access memory at address 0x1f ) at s_entry.c:32 sometimes: #0 0x080b5299 in pd_float (x=0x86d5f08, f=nan(0x428487)) at m_pd.c:274 #1 0x080b8c77 in outlet_float (x=0x868dc18, f=nan(0x428487)) at m_obj.c:397 #2 0x08059af2 in env_tilde_tick (x=0x868db38) at d_ctl.c:671 #3 0x080c33fc in sched_tick (next_sys_time=901427200) at m_sched.c:374 #4 0x080c3843 in m_pollingscheduler () at m_sched.c:484 #5 m_mainloop () at m_sched.c:560 #6 0x080c6509 in sys_main (argc=2, argv=0xb354) at s_main.c:304 #7 0x080ce1ab in main (argc=2, argv=0xb354) at s_entry.c:32 or #0 0x0166adeb in ?? () from /home/mis/pd-externals/udpreceive~.pd_linux #1 0x080bafaa in sys_domicrosleep (microsec=, pollem=) at s_inter.c:184 #2 0x080bbfe1 in sys_pollgui () at s_inter.c:833 #3 0x080b776f in m_pollingscheduler () at m_sched.c:488 #4 m_mainloop () at m_sched.c:558 #5 0x080ba96f in sys_main (argc=2, argv=0xb314) at s_main.c:307 #6 0x080c3fff in main (argc=Cannot access memory at address 0xb ) at s_entry.c:32 or #0 0x080ac7f6 in pd_checkobject (x=0x830bf78) at m_obj.c:554 #1 0x0808c7ba in canvas_hitbox (x=0x82f54f8, xpos=171, ypos=139, which=0, mod=, doit=0) at g_editor.c:768 #2 canvas_doclick (x=0x82f54f8, xpos=171, ypos=139, which=0, mod=, doit=0) at g_editor.c:1095 #3 0x0808d6fe in canvas_motion (x=0x82f54f8, xpos=171, ypos=139, fmod=0) at g_editor.c:1614 #4 0x080aaf27 in pd_typedmess (x=0x82f54f8, s=0x822bd10, argc=3, argv=0xbfffda5c) at m_class.c:728 #5 0x080aac24 in pd_typedmess (x=0x8323bf0, s=0x822bd10, argc=3, argv=0xbfffda5c) at m_class.c:749 #6 0x080af027 in binbuf_eval (x=0x823e078, target=0x8323bf0, argc=0, argv=0x0) at m_binbuf.c:722 #7 0x080bce19 in socketreceiver_read (x=0x823e088, fd=6) at s_inter.c:546 #8 0x080bafaa in sys_domicrosleep (microsec=, pollem=) at s_inter.c:184 #9 0x080bbfe1 in
Re: [PD-dev] changes in atom_getsymbol between pd 0.40-3 and 0.42.4?
ben wrote: ... So that worked for getting the proper value, but the method I was using to get the second argument (argv+1) no longer works. Presumably because the next location is no longer the same. ... Do you mean after you copied the data? Did you try either threadargs-argv[1] or *(threadargs-argv+1) ? They should both give the value of the second argument. Martin ___ Pd-dev mailing list Pd-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
Re: [PD-dev] changes in atom_getsymbol between pd 0.40-3 and 0.42.4?
That's because atom_getint() wants a pointer to an atom, not the atom itself. Try: intValue = atom_getint(((gphoto_gimme_struct *)threadArgs)-argv+1); or: intValue = atom_getint(((gphoto_gimme_struct *)threadArgs)-argv[1]); Martin ben wrote: Yes after copying. gcc does not like either, both result in: error: incompatible type for argument 1 of 'atom_getint' This is the old way: intValue = atom_getint( ((gphoto_gimme_struct *)threadArgs)-argv+1 ); post(in: config value: %d, intValue); and I tried both these: intValue = atom_getint( *(((gphoto_gimme_struct *)threadArgs)-argv+1) ); intValue = atom_getint( ((gphoto_gimme_struct *)threadArgs)-argv[1] ); Same thing happens when I try to access the second argument from the wrapper function, from the threadargs struct. .b. martin.pe...@sympatico.ca wrote: ben wrote: ... So that worked for getting the proper value, but the method I was using to get the second argument (argv+1) no longer works. Presumably because the next location is no longer the same. ... Do you mean after you copied the data? Did you try either threadargs-argv[1] or *(threadargs-argv+1) ? They should both give the value of the second argument. Martin ___ Pd-dev mailing list Pd-dev@iem.at http://lists.puredata.info/listinfo/pd-dev ___ Pd-dev mailing list Pd-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
Re: [PD-dev] changes in atom_getsymbol between pd 0.40-3 and 0.42.4?
So what have I misunderstood? argv is a pointer, it's size is 4. You're still not copying whatever argv is pointing to. Martin ___ Pd-dev mailing list Pd-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
Re: [PD-dev] [PD] midiout / sysex on windows
I don't think sysex works on linux either; at least I'm trying to send using [midiout] using alsa midi and nothing is going through the interface, whereas [noteout] works fine. On Pd 0.42.5-extended2010105 debian lenny. I think I should be able to send a list like: [240 88 123 247( | [midiout] ...but it won't. Martin Date: Wed, 3 Feb 2010 09:38:16 -0800 From: x37v.a...@gmail.com To: pd-l...@iem.at; pd-dev@iem.at Subject: Re: [PD] midiout / sysex on windows BTW, he is using pd 0.41.4-extended -Alex On Tue, Feb 2, 2010 at 7:46 PM, Alex x37v.a...@gmail.com wrote: I just tried this myself on a friend's windows machine running a relatively recent version of pd extended, though I'm not exactly sure which one.. it gave me an error MidiOut Error 1 whenever I tried to send a sysex message out. And there was an error about [sysexin] not being implemented on windows and [midiout] being dangerous.. I'm not sure if midiin worked with sysex or not because i couldn't get the sysex out.. Anyone know if this has changed or if there are plans to make sysex i/o work for windows? Thanks, Alex On Wed, Nov 11, 2009 at 7:23 AM, kristof lauwers p...@kristoflauwers.domainepublic.net wrote: hello, I was wondering what the current state of midiout is on windows (i'm working on Xp, but should make something that works under any recent windows version) I see some discussion about it in the list archives and forum, but it's not clear if it should be working or not right now.. I tried it on vanilla PD 0.42.5 and in extended 0.4.3. It seems in vanilla it does nothing at all. In extended it's sending out something, but not what i expect.. (sometimes the 3 bytes i try to send each padded by 2 or 3 0's, sometimes nothing at all..) Also, it's not very clear what kind of input midiout expects - the documentation doesn't say anything about that.. i'd guess a list with first status byte and then the data bytes? if it's not working (yet), are there any alternatives to send sysexes from Pd? thanks, Kristof ___ pd-l...@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list ___ pd-l...@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list ___ Pd-dev mailing list Pd-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
Re: [PD-dev] [PD] midiout / sysex on windows
On linux with alsa midi, sysex output works this way: bang | [t b b b b] | | | | [247( [123( [88( [240( |_|_|| | | [midiout] That is, banging all the values separately into [midiout] during one message time slot. (Note the message is written backwards since the first byte to transmit is the sysex status byte, 240) Banging them in one at a time manually only sends one byte, banging them in as a list stops [midiout] from working until you reopen the patch. Martin ___ Pd-dev mailing list Pd-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
Re: [PD-dev] including MSVC in Makefile template
hans wrote: Hey all, I know there are some of you who use MSVC. We are finalizing the new Makefile template, if you want to include MSVC rules in it, now would be the time to do it. Here's how: edit externals/ext13/Makefile and add the stuff for MSVC. The key part is that it can't break the other stuff. Ummm, what's special about ext13? I realized I didn't even have that directory in my local copy. I think it's because on MSW Tortoise svn always bails when it runs into the file in gridflow that has an asterisk as part of its name, so whatever came after that isn't included. Maybe that could be fixed first? Martin ___ Pd-dev mailing list Pd-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
Re: [PD-dev] iem_tab on amd64 WAS: Building extended on amd64
hans wrote: On Oct 4, 2009, at 9:19 PM, András Murányi wrote:... Cool. We're here now: cc -DPD -I/home/muranyia/Download/0.41/pd/src -Wall -W -ggdb -I/home/muranyia/Download/0.41/Gem/src -I/home/muranyia/Download/0.41/externals/pdp/include -DUNIX -Dunix -DDL_OPEN -fPIC -DIEMTAB_SINGLE_OBJ -o /home/muranyia/Download/0.41/externals/iem/iem_tab/src/tab_add_scalar.o -c /home/muranyia/Download/0.41/externals/iem/iem_tab/src/tab_add_scalar.c /home/muranyia/Download/0.41/externals/iem/iem_tab/src/tab_add_scalar.c: In function ‘tab_add_scalar_list’: /home/muranyia/Download/0.41/externals/iem/iem_tab/src/tab_add_scalar.c:85: error: incompatible types in assignment /home/muranyia/Download/0.41/externals/iem/iem_tab/src/tab_add_scalar.c:105: error: invalid operands to binary + /home/muranyia/Download/0.41/externals/iem/iem_tab/src/tab_add_scalar.c: At top level: /home/muranyia/Download/0.41/externals/iem/iem_tab/src/tab_add_scalar.c:69: warning: unused parameter ‘s’ /home/muranyia/Download/0.41/externals/iem/iem_tab/src/tab_add_scalar.c:119: warning: unused parameter ‘x’ /home/muranyia/Download/0.41/externals/iem/iem_tab/src/tab_add_scalar.c:123: warning: unused parameter ‘s’ make[2]: *** [/home/muranyia/Download/0.41/externals/iem/iem_tab/src/tab_add_scalar.o] Error 1 make[2]: Leaving directory `/home/muranyia/Download/0.41/externals' make[1]: *** [externals_install] Error 2 make[1]: Leaving directory `/home/muranyia/Download/0.41/packages' make: *** [install] Error 2 Andras Strange one there, seems to be something else since -fPIC is set. IEM people, any ideas? Not an IEM peep but in iemlib.h we find this: /* on 64bit systems we cannot use garray_getfloatarray... */ #if (defined __x86_64__) # define iemarray_t t_word # define iemarray_getarray garray_getfloatwords # define iemarray_getfloat(pointer, index) (pointer[index].w_float) # define iemarray_setfloat(pointer, index, fvalue) (pointer[index].w_float = fvalue) #else # define iemarray_t t_float # define iemarray_getarray garray_getfloatarray # define iemarray_getfloat(pointer, index) (pointer[index]) # define iemarray_setfloat(pointer, index, fvalue) (pointer[index] = fvalue) #endif Then in tab_add_scalar the variable add is defined: iemarray_t *vec_src1, *vec_dst, add; ...and then at line 85 an error occurs because add is a t_word, not a t_float: add = (t_float)atom_getfloatarg(3, argc, argv); ...so probably add.w_float = (t_float)atom_getfloatarg(3, argc, argv); would work, but this is likely not the only place this will happen. Martin ___ Pd-dev mailing list Pd-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
[PD-dev] lib.pd on pd-extended
The latest autobuild for windows http://autobuild.puredata.info/auto-build/latest/Pd-0.42.5-extended-windowsxp-i386.exe now installs pd.a as pd.lib and that seems to work OK to link against with MSVisualC++2008ExpressEdition, so the .def file that is also installed is probably redundant. I notice in the log that moocow stuff fails when -lpd is used, although -lpd works OK for pd.dll and others: gcc -DPD -I/home/pd/auto-build/pd-extended/pd/src -Wall -W -ggdb -I/home/pd/auto-build/pd-extended/Gem/src -mms-bitfields -DMSW -DNT -D'O_NONBLOCK=1' -D'srand48(n)=srand((n))' -D'drand48()=((double)rand()/RAND_MAX)' -D'bzero(p,n)=memset(p,0,n)' -L/home/pd/auto-build/pd-extended/pd/bin -L/home/pd/auto-build/pd-extended/pd/obj -L/sw/lib -shared -L/home/pd/auto-build/pd-extended/externals/moocow/extended/build.moo/bin -L/home/pd/auto-build/pd-extended/externals/moocow/extended/build.moo/obj -o locale.dll locale.o -lpd -lwsock32 -lpthreadGC2 -lkernel32 -luser32 -lgdi32 -lregex c:\MinGW\bin\..\lib\gcc\mingw32\3.4.5\..\..\..\..\mingw32\bin\ld.exe: cannot find -lpd Maybe the path is wrong? I don't think it wants to find libpd.a instead of pd.a, since in makefile.mingw, pd.dll is built with --out-implib=pd.a, then pd.exe uses -lpd without any errors. Martin ___ Pd-dev mailing list Pd-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
Re: [PD-dev] [LONG] Building extended on amd64
You need to install the fftw3-dev package. Martin muranyia wrote: # sudo make install ... cc -DPD -I/home/muranyia/Download/0.41/pd/src -Wall -W -ggdb -I/home/muranyia/Download/0.41/Gem/src -I/home/muranyia/Download/0.41/externals/pdp/include -DUNIX -Dunix -DDL_OPEN -fPIC -O2 -funroll-loops -fomit-frame-pointer -o /home/muranyia/Download/0.41/externals/bsaylor/partconv~.o -c /home/muranyia/Download/0.41/externals/bsaylor/partconv~.c /home/muranyia/Download/0.41/externals/bsaylor/partconv~.c:34:19: error: fftw3.h: No such file or directory /home/muranyia/Download/0.41/externals/bsaylor/partconv~.c:51: error: expected specifier-qualifier-list before ‘fftwf_complex’ ... ___ Pd-dev mailing list Pd-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
Re: [PD-dev] [tcpserver]: new 'clientbuf' method seems to be buggy
Well I'm trying to get rid of the bugs in it... I don't get that on WinXP though (Pd 0.41.4-extended). I set the buffer to 12 and still received 30 bytes. On Debian with Pd 0.41.4-extended I get two separate messages (each longer than 12) but still all the data arrives. Martin From: reduzie...@yahoo.de To: pd-dev@iem.at Date: Mon, 6 Apr 2009 17:38:20 +0200 Subject: [PD-dev] [tcpserver]: new 'clientbuf' method seems to be buggy hi martin i reckon, that you're working on tcpserver code these days, at least when ever i update mrpeach from svn, the tcpserver.c file is updated. so please tell me, if it makes sense at all to currently report bugs. after having set the buffersize using the 'clientbuf' messages, message to the client, for which the buffersize was set, are truncated. while sending 30 byte messages, only 15 bytes are sent, respectively 15 bytes are received on the client side. please check the attached bug illustration patch roman ___ Pd-dev mailing list Pd-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
Re: [PD-dev] PD-cvs Digest, Vol 29, Issue 11
IOhannes m zmoelnig wrote: another question: in osc, timetags are per-bundle (not per message). is the scheduling information sent to the outlet for each message or only once for each bundle? The delay is output exactly once for each time tag. packOSC generates a time tag whenever a bundle is opened with a '[' message. It's possible for a bundle to contain other bundles whose time tags _must_ be later than that of the enclosing bundle. In that case I suppose you could get two or more delays output for a single message but the last delay would always be the correct one. Martin ___ PD-dev mailing list PD-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
Re: [PD-dev] PD-cvs Digest, Vol 29, Issue 11
Martin Peach wrote: IOhannes m zmoelnig wrote: nevertheless i think it might be very good if i could distinguish between the 3 types of timetags) That's a difficult problem. What's the difference between zero and zero? I mean how does one tag no delay as being different from a delay of zero without adding another outlet? OK, I changed packOSC to output negative delays and it's now obvious, even on the same machine a current time tag always has a slight negative delay, whereas an immediate time tag is always exactly zero. That leaves the slight problem of a future message that arrives exactly on time... Martin ___ PD-dev mailing list PD-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
Re: [PD-dev] PD-cvs Digest, Vol 29, Issue 11
Hans-Christoph Steiner wrote: Martin Peach wrote: IOhannes m zmoelnig wrote: OK, I changed packOSC to output negative delays and it's now Oops, that should say unpackOSC... obvious, even on the same machine a current time tag always has a slight negative delay, whereas an immediate time tag is always exactly zero. That leaves the slight problem of a future message that arrives exactly on time... Martin Wow, nice work! That sounds like it'll be quite easy to use timetags now. Is there anyway to generate timetags with Pd yet? Well, packOSC does that when you open a bundle, you can also specify an offset. Is there a need for actual raw timetags? I started an external to generate them as a list of four floats (64 bits split into four 16-bit numbers). Then I realized it's easier to use millisecond delays since that's what pd is using, so unpackOSC just converts the received time tag into a millisecond delay relative to the current time. This could be altered easily by adding a constant at the outlet. Martin ___ PD-dev mailing list PD-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
Re: [PD-dev] add_string_support.patch
Is there a correct way to use diff to make the paths properly in the first place? Do you have to run it from a particular location or specify a path? Also I agree that string should be blob (or puredata ;)) since string implies text and it's really able to manipulate any kind of byte data. Martin From: Hans-Christoph Steiner [EMAIL PROTECTED] On May 1, 2007, at 2:59 AM, [EMAIL PROTECTED] wrote: Quoting Hans-Christoph Steiner [EMAIL PROTECTED]: try -p 2 This is automated, so that would mean changing all the patches in packages/patches. I think it would be much easier to change that one patch to remove the path information. the last one was another mail where i clicked send before thinking. the -p 2 would strip _at most_ the first 2 path-elements (see 'man patch' for a better explanation) of the filenames. so pd/src/g_rtext.c becomes g_rtext.c, while src/g_canvas.c becomes g_canvas.c and m_pd.h stays the same. so all patches should apply just as fine as they do now, and the string-support patch would apply too. apart from that, i agree that all patches should be normalized in a way. (and that string really should be blob) Feel free to add this stuff to the build system, as long as it works on all platforms. an older sed is installed on everything in the auto-build farm. But it might save more trouble in the long run to keep a consistent format. Hard to say... .hc ___ PD-dev mailing list PD-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
Re: [PD-dev] d_math.c break[s] strict-aliasing rules
They all seem to be directly manipulating the exponent field of a float to make/access lookup tables for every possible exponent. Is this necessary now that everybody has floating-point units built-in to their processors? I can see that it would be a big speed enhancer in a 386 or 68000 but the fpu probably already has internal tables along the same lines. Martin Hans-Christoph Steiner wrote: So it seems that this bug in d_math.c is triggered by turning on the Apple-recommended optimization flags: http://sourceforge.net/tracker/index.php? func=detailaid=1692649group_id=55736atid=478070 I did notice that there are these warnings in the source. IIRC, optimization generally requires strict aliasing, so it seems that these warnings are probably related to the above bug: d_math.c: In function 'init_rsqrt': d_math.c:79: warning: dereferencing type-punned pointer will break strict-aliasing rules d_math.c: In function 'q8_rsqrt': d_math.c:93: warning: dereferencing type-punned pointer will break strict-aliasing rules d_math.c: In function 'q8_sqrt': d_math.c:101: warning: dereferencing type-punned pointer will break strict-aliasing rules Here are the lines in question: 79:*(long *)(f) = l; 93:long l = *(long *)(f); 101: long l = *(long *)(f); Can anyone speak to what's this for and what it can be replaced with so as to follow strict-aliasing rules. Maybe we could use something like this instead (from http://www.cs.tut.fi/~jkorpela/ round.html ): #define round(x) ((x) LONG_MIN-0.5 || (x) LONG_MAX+0.5 ?\ error() : ((x)=0?(long)((x)+0.5):(long)((x)-0.5)) This requires that you have #include limits.h and that you have an error handling routine called error which is a function of type long. .hc kill your television ___ PD-dev mailing list PD-dev@iem.at http://lists.puredata.info/listinfo/pd-dev ___ PD-dev mailing list PD-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
Re: [PD-dev] text placement
You mean the labels? In g_all_guis.c: void iemgui_label(void *x, t_iemgui *iemgui, t_symbol *s) and void iemgui_label_pos(void *x, t_iemgui *iemgui, t_symbol *s, int ac, t_atom *av) The x_lab and y_lab items can be set in u_main.tk, they are the x_off and y_off parameters for some of the guis. Or did you mean the contents of the boxes? static void *my_canvas_new(t_symbol *s, int argc, t_atom *argv) in g_mycanvas.c might be relevant... Martin From: Hans-Christoph Steiner [EMAIL PROTECTED] Date: 2007/01/08 Mon PM 01:20:49 EST To: PD List pd-dev@iem.at Subject: [PD-dev] text placement Can anyone point me to where the text is placed on the canvas in relation to the object and message boxes? It seems to vary depending on platform and I'd like to troubleshoot it. .hc As we enjoy great advantages from inventions of others, we should be glad of an opportunity to serve others by any invention of ours; and this we should do freely and generously. - Benjamin Franklin ___ PD-dev mailing list PD-dev@iem.at http://lists.puredata.info/listinfo/pd-dev ___ PD-dev mailing list PD-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
Re: Re: [PD-dev] strings
Mathieu Bouchard [EMAIL PROTECTED] wrote: Do you realise that the quoting problem can be solved independently of the allocation problem? In that case, you would be able to save any symbol and read it back. This would solve the problem about CR LF and spaces; only the problem with \0 (NUL) would remain. If ascii values from 0 - 31 can be part of symbols that would be nice. How do you specify a symbol containing ascii values 1 2 and 3? Do they have names? Symbols could be usable, if the problems that can be fixed in symbol without changing the nature of symbols, are fixed. You don't need strings for that. You still have the problem of the symbol table that grows by one each time the symbol changes. If I want to parse a book one word at a time, for example, it would only take one string for the input buffer, but it would take as many symbols as there are different words in the book. Wouldn't you want objects to be able to emit strings in a way as carefree as they are with symbols? I'm talking about not putting the burden of memory management on the emitter of strings. A string library could have functions similar to getbytes(), resizebytes() and freebytes() for changing the length of strings that could be called by any other external in the library. Or pd could have the same functions that could be called by any external. Either way... Martin ___ PD-dev mailing list PD-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
Re: Re: [PD-dev] strings
De: Hans-Christoph Steiner [EMAIL PROTECTED] Date: 2006/12/18 lun. AM 09:45:26 GMT-05:00 À: carmen [EMAIL PROTECTED] Cc: pd-dev@iem.at Objet: Re: [PD-dev] strings On Dec 18, 2006, at 1:23 AM, carmen wrote: Automatic type conversion sounds like a really bad idea if the language only partially supports it. Pd is strongly typed is it? it mainly has numbers that occasionally look like symbols, and symbols that more than occasionally look like lists and/or strings.. There are set rules which defined what is a float, symbol, or pointer. You cannot change that type, often even with a special method. Ever tried to turn a float into a symbol? Doesn't really work, only partially. Along the lines of pd_defaultlist() in m_class.c, which handles list messages for objects that don't have list methods, one could add a pd_defaultstring(), which attempts to convert strings into symbols/floats/lists, instead of calling pd_defaultanything(), which would print no method for string. But it needs to be understood that it might not do it correctly, which is Not A Good Thing, but no worse than comments getting mangled. Maybe a [string unpack] object would be better: it could attempt to unpack a string into specified types, so the user could decide if a string like 123 is meant to represent a float or a symbol. Martin .hc , so what Martin says is definitely appropriate. Perl is the opposite, everything can be automatically cast, so there it makes sense. it is definitely a design decision which way to go. could PD flexibly support both at once? or does there need to be an OCaml edition, and a Perl edition? ___ PD-dev mailing list PD-dev@iem.at http://lists.puredata.info/listinfo/pd-dev Mistrust authority - promote decentralization. - the hacker ethic ___ PD-dev mailing list PD-dev@iem.at http://lists.puredata.info/listinfo/pd-dev ___ PD-dev mailing list PD-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
Re: Re: [PD-dev] strings
De: Mathieu Bouchard [EMAIL PROTECTED] Date: 2006/12/18 lun. PM 12:11:18 GMT-05:00 À: Martin Peach [EMAIL PROTECTED] Cc: pd-dev@iem.at Objet: Re: [PD-dev] strings On Sun, 17 Dec 2006, Martin Peach wrote: You make them work as strings when they can, and You make them work as symbols when they must. There would be two objects, [stringtosymbol] and [symboltostring] that you could put between string and symbol objects. Of course some strings would get impossibly mangled this way but that's because of the way symbols work. I have no clue what you're talking about: how mangled would they be? i don't plan any mangling to happen, except for the presence of \0 characters. Maybe you don't understand what is being proposed. How would you make a symbol containing ASCII NUL and CR LF characters for instance? Yes, there's no reason not to have 0-length strings. And no reason to trash them when they are unused either, since they don't take up more space than any other object. They take the space it takes to tell their size and the pointer to the buffer. That's significant, and nearly as much as in the case of a t_symbol, supposing that those t_strings can live independently of the objects that produce them. Like any other object strings have that overhead, but unlike lists they only have one atom per string. They would be created by string objects and last as long as the string objects. One string per string object. String messages are passed between string manipulator objects. For this purpose symbols are not usable because they can't contain every possible character and lists have too much overhead since each element of a list is an atom. I'm suggesting that a [string] be like any other object and be deallocated when the patcher is closed. Ok, that's certainly the string feature that I want. It's too much trouble for the benefit. Whatever. Man, that's not n atom type. No it's not n atoms, it's a single atom that contains a pointer to a list of bytes. That's the main advantage of string over list. Symbols are difficult to work with because their content gets interpreted, You say that in answer to my questions on allocation? (That's not an allocation issue and not even any kind of memory layout issue.) I don't know, did I? It looks to me like an answer to a question about why symbols can't be used to encode arbitrary strings. Maybe I was tired. for example if I write a comment MP 20061214 it gets converted into MP 2.00612e+007 the contents of a comment box is not a symbol. It's a list of atoms. However, Pd has the same problem you describe when trying to save some symbols. e.g. say you have a symbol with a space in it and you pass it to a messagebox set $1 which passes it to an empty messagebox, and then you save the patch: then you have that problem with symbols. But the contents of the comment box has that problem while never storing its contents as a symbol. I wonder how the list of atoms in a comment box gets by without some of those atoms being symbols... Martin ___ PD-dev mailing list PD-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
Re: [PD-dev] mrpeach/net/tcpserver
I get: if(argc 2) on line 420, so I don't get it... But whatever it really is, go ahead and change it if you think it works. Martin De: IOhannes m zmoelnig [EMAIL PROTECTED] Date: 2006/12/11 lun. PM 12:55:42 GMT-05:00 À: pd-dev pd-dev@iem.at Objet: [PD-dev] mrpeach/net/tcpserver i just discovered a bug in mrpeach/net/tcpserver the break in mrpeach/net/tcpserver.c:420 effectively makes the broadcast message useless. is there any reason for this? can i change the file? mfg.adr IOhannes ___ PD-dev mailing list PD-dev@iem.at http://lists.puredata.info/listinfo/pd-dev ___ PD-dev mailing list PD-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
