Re: [PD-dev] pdstring's crashing
On Tue, 24 Jul 2007, Martin Peach wrote: Bryan Jurish wrote: all that allocation and de-allocation at every message just makes my skin crawl... maybe we should find a better way to do it... or just use Martin's string patches ;-) When I made the [str] external that uses the string atom, I found that constantly reallocating/resizing memory eventually crashed pd so I ended up just allocating a big wad of space up front for each [str]. If the user can set the initial size of this memory then the amount of wasted ram may be minimized, but the default is quite large. Consider using Valgrind. It's essentially an emulator of your CPU that checks whether each instruction makes sense in terms of previous calls to malloc() and free(). It can detect lots of pointer errors and give you backtraces of both the error that happened and the original allocation. It can be configured to report on memory leaks as well. _ _ __ ___ _ _ _ ... | Mathieu Bouchard - tél:+1.514.383.3801, Montréal QC Canada___ PD-dev mailing list PD-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
Re: [PD-dev] please add 'mokhov' to pure-data at SF.net
trust thing is what worries me. In the last month we had two pleas for being added as an SF developer by people. who neverever have posted a single mail to pd-list, at least not with the mail addresses they were using. Compare that to for example one of the latest new additions, I was probably the other one. I have no problem posting patches instead of direct-committing stuff to the CVS repository. If that works without having SF access, then great. I've just recently started using Pd, and, no, I haven't gone thru the entire core and portmidi source and understood the Grand Scheme of Things. Just enough to write my patch and not interfere with anything else - which is better judged by someone w/ more experience. Of course these were changes to the core (sysex/OSX), and not externals. Those are 2 somewhat different stories. (I did post *once* on the non-dev pd-list; the patch was written in response to it and other similar posts) -- We've Got Your Name at http://www.mail.com! Get a FREE E-mail Account Today - Choose From 100+ Domains ___ PD-dev mailing list PD-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
Re: [PD-dev] pdstring's crashing
Bryan Jurish wrote: moin again, the fastest lurker on the list... the new code has been checked into cvs as externals/moocow/pdstring v0.04 ... let me know if it works (or doesn't)... and send me some sequence of inputs that reproduces the error if you can find one... thanks bryan. i have not been able to test your changes under our conditions, i'll tell you when i know more. mfg.asdr IOhannes ___ PD-dev mailing list PD-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
Re: [PD-dev] devel_0_39 ? devel_0_40 ?
On Tue, 2007-07-24 at 11:08 -0700, Miller Puckette wrote: On Mon, Jul 23, 2007 at 12:20:33PM +0200, Tim Blechmann wrote: Now for the hard part: in Pd, 32-bit floating point tables are stored as 64-but 'atoms' for a 50% hit in memory efficiency. Something Must Be Done; but what? split audio buffers and array-of-atoms? maybe this could include rewriting the whole audio buffers with an asynchronous interface ... imo, data structures and audio buffer have completely different real-time and performance constraints, so i see no real benefit in combining both concepts ... Well, I only just combined table~ with 'data structures' in 0.39 (I think), because there were hundreds of lines of essentially duplicate GUI code for the two types of arrays. The other complication is that I'm trying to design a new system of buffers suitable for images, perhaps with 8- 16- and 32- bit cells. It would be desirable for tabread4~ and all that to be able to talk to images too. Big design problem... the problem of generic design is, that you might have an implementation, that does everything more or less, but does nothing completely right ... like ... do you want/need 128bit alignment? do you want/need power-of-two sizes? what are your real-time constraints (1.3 ms or 40 ms deadlines)? can you affort to waste memory? generic design is great, if you don't have to sacrifice too much performance / usability ... i'm not sure about combining ds, audio buffers and video buffers (and maybe multi-dimensional matrices), though ... tim -- [EMAIL PROTECTED]ICQ: 96771783 http://tim.klingt.org I had nothing to offer anybody except my own confusion Jack Kerouac signature.asc Description: This is a digitally signed message part ___ PD-dev mailing list PD-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
Re: [PD-dev] help-array crashing outlet_anything
[EMAIL PROTECTED] wrote: Intstore *storepointer; Intstore *storepointer = new Intstore(); storepointer[arraynumber] = *pointer; This is the problem. You have only one Intstore object pointed to by storepointer, but you're assuming you have more than one whenever arraynumber is not 0. When arraynumber is not 0, you get undefined behaviour (which could be wrong results or (if you're lucky) a crash). Claude -- http://claudiusmaximus.goto10.org ___ PD-dev mailing list PD-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
Re: [PD-dev] help-array crashing outlet_anything
On 7/25/07, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote: BTW its a blobtracking external. It is working perfect tracking quicktime movies but the camera tracking only works if I exclude the addToArray function. This really has me scratching my head! Why would your processing code know or even care if the input is from a camera or a file? Both should be pixel arrays with no differences in their format. ___ PD-dev mailing list PD-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
Re: [PD-dev] please add 'mokhov' to pure-data at SF.net
On Jul 24, 2007, at 3:35 PM, Frank Barknecht wrote: Hallo, Mathieu Bouchard hat gesagt: // Mathieu Bouchard wrote: However in terms of practical security, even though common sense tells you that more people is more trouble, what matters is whether their account can be trusted to be them, that they can be trusted to not cause trouble, and which access control measures are put in place in order to prevent trouble. As there are practically no access control measures in effect, that trust thing is what worries me. In the last month we had two pleas for being added as an SF developer by people. who neverever have posted a single mail to pd-list, at least not with the mail addresses they were using. Compare that to for example one of the latest new additions, Chris McCormick, who is active in the project and on the lists for years. I didn't have any problem with adding him. To say it clearly: I wouldn't want to add people to SF, who are unknown, unless one of the regulars can vouch for them. If someone is just in need of a place to host externals or abstractions, there's always puredata.info. Or course this is nothing personal against Serguei, whom I don't know anyway. But probably we'll meet in Montreal and drink a beer. ;) If people wanted to, we could purge non-active developers from the list, especially since it's quite easy to get added again. That would probably bring us below 40 (I must say it would feel sad and strange to remove Jamie and Gerard...). I agree that we should expect a fair amount of activity before being added, whether in terms of code output, list posts, etc. .hc Ciao -- Frank Barknecht _ __footils.org_ __goto10.org__ ___ PD-dev mailing list PD-dev@iem.at http://lists.puredata.info/listinfo/pd-dev All mankind is of one author, and is one volume; when one man dies, one chapter is not torn out of the book, but translated into a better language; and every chapter must be so translated -John Donne ___ PD-dev mailing list PD-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
Re: [PD-dev] help-array crashing outlet_anything
Ok I tried with a static array like Class array[amount] and it did not crash, it worked perfect. Now I have to figure out what I am doing to cause a crash (with heavy cpu load I persume, still a bit confused?) using a dynamic array? It would be nice to have a dynamic array so as not to eat up so much ram. Alain From: [EMAIL PROTECTED] Date: 2007/07/25 Wed PM 03:35:33 EDT To: chris clepper [EMAIL PROTECTED] CC: pd-dev@iem.at Subject: Re: [PD-dev] help-array crashing outlet_anything It doesn't thats whats confusing me. Pixel data is the same on both exept it takes more cpu to process. I think it has to do with cpu load but I am not sure. I think I am going to just try a simple Class array[amount] intead of Class *pointer = new Class[amount] see if that would be easier on the cpu or the coding gods. Alain From: chris clepper [EMAIL PROTECTED] Date: 2007/07/25 Wed PM 01:04:52 EDT To: [EMAIL PROTECTED] [EMAIL PROTECTED] CC: pd-dev@iem.at Subject: Re: [PD-dev] help-array crashing outlet_anything On 7/25/07, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote: BTW its a blobtracking external. It is working perfect tracking quicktime movies but the camera tracking only works if I exclude the addToArray function. This really has me scratching my head! Why would your processing code know or even care if the input is from a camera or a file? Both should be pixel arrays with no differences in their format. ___ 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] help-array crashing outlet_anything
It doesn't thats whats confusing me. Pixel data is the same on both exept it takes more cpu to process. I think it has to do with cpu load but I am not sure. I think I am going to just try a simple Class array[amount] intead of Class *pointer = new Class[amount] see if that would be easier on the cpu or the coding gods. Alain From: chris clepper [EMAIL PROTECTED] Date: 2007/07/25 Wed PM 01:04:52 EDT To: [EMAIL PROTECTED] [EMAIL PROTECTED] CC: pd-dev@iem.at Subject: Re: [PD-dev] help-array crashing outlet_anything On 7/25/07, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote: BTW its a blobtracking external. It is working perfect tracking quicktime movies but the camera tracking only works if I exclude the addToArray function. This really has me scratching my head! Why would your processing code know or even care if the input is from a camera or a file? Both should be pixel arrays with no differences in their format. ___ PD-dev mailing list PD-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
Re: [PD-dev] please add 'mokhov' to pure-data at SF.net
On Wed, 25 Jul 2007, Frank Barknecht wrote: To say it clearly: I wouldn't want to add people to SF, who are unknown, unless one of the regulars can vouch for them. I agree that it should stay like that. _ _ __ ___ _ _ _ ... | Mathieu Bouchard - tél:+1.514.383.3801, Montréal QC Canada___ PD-dev mailing list PD-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
[PD-dev] [ pure-data-Feature Requests-1760589 ] cos~ help
Feature Requests item #1760589, was opened at 2007-07-25 13:44 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=478073aid=1760589group_id=55736 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 Priority: 5 Private: No Submitted By: Nobody/Anonymous (nobody) Assigned to: Nobody/Anonymous (nobody) Summary: cos~ help Initial Comment: I spent a very long time to realise that the cos~ object outputs the cosine of _2*pi_ its signal input and not simply the cosine of its signal input. It would be nice to change it for the beginners coming next. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=478073aid=1760589group_id=55736 ___ PD-dev mailing list PD-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
[PD-dev] [ pure-data-Patches-1738839 ] tcl extensions for ix widgets
Patches item #1738839, was opened at 2007-06-17 22:09 Message generated for change (Comment added) made by eighthave You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=478072aid=1738839group_id=55736 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: Patko (patricecolet) Assigned to: Nobody/Anonymous (nobody) Summary: tcl extensions for ix widgets Initial Comment: ix widgets requires packages for being loaded on pd-extended-win32, attached is a patch that provides the code for loading those libraries: http://megalego.free.fr/pd/pkg-pd-tk8.4-win32.rar -- Comment By: Hans-Christoph Steiner (eighthave) Date: 2007-07-25 14:41 Message: Logged In: YES user_id=27104 Originator: NO In order to make this usable, you should provide how to get the original files (i.e. the download URL) and also provide a patch to the makefiles which will install these files in the right place. These makesfiles are all in the packages branch of CVS. There is a cross-platform makefile, packages/Makefile, and platform/package-specific makefiles (e.g. packages/win32_inno/Makefile). -- You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=478072aid=1738839group_id=55736 ___ PD-dev mailing list PD-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
[PD-dev] [ pure-data-Patches-1760624 ] font/box size overhaul with properties panel clean-up
Patches item #1760624, was opened at 2007-07-25 18:01 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=478072aid=1760624group_id=55736 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: feature Status: Open Resolution: None Priority: 8 Private: No Submitted By: Hans-Christoph Steiner (eighthave) Assigned to: Miller Puckette (millerpuckette) Summary: font/box size overhaul with properties panel clean-up Initial Comment: This patch includes everything from branch-v0-39-2-extended to make the fonts and boxes the same size on every platform. The default font is changed to Monaco on Mac OSX (included with the OS) and Bitstream Vera Sans Mono on Windows and GNU/Linux (included with GNOME). The font is free as in speech and beer, so it can be distributed with any Pd package. The iemgui properties panels were also changed to reflect the new fonts, plus they were cleaned up a bit to make them more readable. It applies cleanly, builds and seems to work fine on 0.40.3 and 0.41.0-test04. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=478072aid=1760624group_id=55736 ___ PD-dev mailing list PD-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
