[PD] Mac OSX 10.7 resume states crash Pd-extended
Since I've upgraded to Mac OSX 10.7 Lion, I've noticed Pd-extended 0.42.5 seemed to crash on startup sometimes, while other times it was fine. It finally dawned on me that OSX is trying to load the previous saved state since I had CMD-Q'd Pd with windows open. It automatically opens those windows at start. I assume pd is not yet ready for these and crashes due to some init order issue ... If anyone else has noticed this, a quick fix is to delete the save state so you can open Pd again. Then make sure to close all windows before quitting the next time ... thanks for the help apple. http://osxdaily.com/2011/07/17/delete-specific-application-saved-states-from-mac-os-x-10-7-lion-resume/ Commandline: rm -rf ~/Library/Saved\ Application\ State/org.puredata.* Dan Wilcox danomatika.com robotcowboy.com ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] Mac OSX 10.7 resume states crash Pd-extended
I tested this with Pd-Vanilla 0.43-0 and there are no problems. The patch windows come up nicely. I tried to test it with a Pd-Extended-0.43.1autobuild but I keep getting load errors and can't open any patch windows :P Is there a more stable version somewhere? As for Pd-Extended 0.42.5, there are some options: http://reviews.cnet.com/8301-13727_7-20083707-263/managing-mac-os-x-lions-application-resume-feature/ You can hold Option when quitting (aka Cmd+Opt+Q ) to bypass the save state mechanism and delete any current states. You can also disable the state saving by locking the state folder for Pd-Extended itself in ~/Library/Saved\ Application\ State/org.puredata.pd.wish.savedState/ through the Get Info dialog (CMD+I) ... On Aug 28, 2011, at 5:16 AM, Dan Wilcox wrote: Since I've upgraded to Mac OSX 10.7 Lion, I've noticed Pd-extended 0.42.5 seemed to crash on startup sometimes, while other times it was fine. It finally dawned on me that OSX is trying to load the previous saved state since I had CMD-Q'd Pd with windows open. It automatically opens those windows at start. I assume pd is not yet ready for these and crashes due to some init order issue ... If anyone else has noticed this, a quick fix is to delete the save state so you can open Pd again. Then make sure to close all windows before quitting the next time ... thanks for the help apple. http://osxdaily.com/2011/07/17/delete-specific-application-saved-states-from-mac-os-x-10-7-lion-resume/ Commandline: rm -rf ~/Library/Saved\ Application\ State/org.puredata.* Dan Wilcox danomatika.com robotcowboy.com Dan Wilcox danomatika.com robotcowboy.com ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] sending image from of / libpd
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 send an area of memory and I could imagine sending a giant list would be alot slower then using an array. See the example in https://github.com/danomatika/ofxPd for how to read/write to pd arrays. Otherwise you could write and external as Mathieu suggests ... On Aug 27, 2011, at 11:21 PM, Mathieu Bouchard wrote: 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 pixels arrrays from openframeworks to pd using libpd and receiving it in pd for interpreting it as sound in real time. Do anybody have tried soemthing like this? any idea? You can make yourself tilde externals for pd, that you embed in your libpd-based app... e.g. one or two outlets, no inlets. You just call the setup-functions of the externals just after initialising libpd... the externals don't need to be separate files (dll, so, dylib) : they can be part of your main executable instead, which is easier. I already do that with non-tilde externals. (Haven't had a reason to make tilde externals in that context yet). ___ | Mathieu Bouchard tél: +1.514.383.3801 Villeray, Montréal, QC Dan Wilcox danomatika.com robotcowboy.com ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] [PD-dev] tkwidgets
To be honest I don't care. You can get into semantics all you like but it's a library that can run Pd patches. If there are issues with ZenGarden then wouldn't it make sense to bring them up with the developer? It's not like they couldn't be resolved. I'm just looking to create a GUI that resolves many usability issues (for me anyway) when constructing Pd patches. Don't get me wrong, I love Pd and use it everyday. But I feel more work could be done on workflow to improve productivity. If other people find that useful then great! On 27 August 2011 20:48, Mathieu Bouchard ma...@artengine.ca wrote: On Fri, 26 Aug 2011, Joe White wrote: For fun I was making a GUI interface for OSX with ZenGarden, a Pd runtime library. ZenGarden is not a Pd runtime library, even though it's advertised like that. ZenGarden thinks that $2 is for getting the first element of a list, and it also thinks that bang is an atomtype. It also fails to give any error message for any unrecognised selector («no method for...»). And then there are other problems. __**__** ___ | Mathieu Bouchard tél: +1.514.383.3801 Villeray, Montréal, QC ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] autobuild site down?
Works now. On Sat, Aug 27, 2011 at 10:53 PM, Hans-Christoph Steiner h...@at.or.atwrote: Its hosted here, so it looks like their whole internet connection is down: http://www.poly.edu .hc On Aug 27, 2011, at 11:09 AM, Pedro Lopes wrote: Is autobuild site down? http://autobuild.puredata.info/auto-build/latest/ -- Pedro Lopes (HCI Researcher / MSc) contact: pedro.lo...@ist.utl.pt website: http://web.ist.utl.pt/Pedro.Lopes / http://pedrolopesresearch.wordpress.com/ | http://twitter.com/plopesresearch ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list I have always wished for my computer to be as easy to use as my telephone; my wish has come true because I can no longer figure out how to use my telephone. --Bjarne Stroustrup (creator of C++) -- Pedro Lopes (HCI Researcher / MSc) contact: pedro.lo...@ist.utl.pt website: http://web.ist.utl.pt/Pedro.Lopes / http://pedrolopesresearch.wordpress.com/ | http://twitter.com/plopesresearch ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] sending image from of / libpd
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 libpd-specific (z_libpd.h) about arrays. That's not true. Recent versions of libpd come with functions for reading and writing arrays, memcpy-style. It's a good thing, because IMHO, many of the functions whose name start with the letters «libpd» are pointless, as they can already be done using typedmess() and such. Okay, I'll bite. 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, but that's not the use case that I had in mind when writing libpd. 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. libpd aims to provide a high-level API at a consistent level of abstraction, and I believe that that's the correct level of abstraction for the kind of work that libpd is intended for. The immediate motivation was to create an API that would be easy to wrap for languages like Java and Python, but I also have deeper reasons for wanting to work at this level of abstraction. I'm hoping that we'll see a major redesign of Pd in the not too distant future. One goal we talked about at PdCon is to allow multiple instances of Pd. Another change I'm hoping to see is a rewrite that takes advantage of multiple cores on current machines. I also believe that such changes will be necessary to remain competitive. The libpd API is meant to be (mostly) above such implementation details, while the low-level API will almost certainly change when Pd is updated. Pd itself will be much more nimble and maintainable if developers think about it at a higher level of abstraction. In case you're interested, I recently added a few more functions to libpd, and I wrote up my reasoning behind them in a blog post: http://nettoyeur.noisepages.com/2011/08/pure-data-convention-libpd-and-a-minor-epiphany/ Cheers, Peter ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
[PD] [PD-announce] gem 0.93.1
after a few days of waiting (for you) and hard labour (for me), Gem 0.93.1, the 1st bugfix release for the 0.93 series, has been released today. like always we have fixed numerous bugs and features, and most likely introduced an equal number of wishlists and showstoppers. noteable differences since 0.93.0: functionality bugs: - [pix_film] no longer crashes when sending an auto message to it, while no film is loaded - [pix_film]'s auto message actually does something - [pix_frei0r] no longer crashes when dynamically instantiating plugins documentation: - [pix_frei0r]/[pix_freeframe] help patches now mention how to dynamically load a plugin at runtime (or change the plugin) - [separator] help patch now explains how to only work on special openGL matrices binaries are available for w32 (installer zip), for the brave and adventurous there is the source code. binaries for OSX are still not available yet, but we hope to get them online soonish. grab it while it's hot: http://gem.iem.at/releases/0.93.1 alternatively you can get the files from https://sourceforge.net/projects/pd-gem mfgadr IOhannes signature.asc Description: OpenPGP digital signature ___ Pd-announce mailing list pd-annou...@iem.at http://lists.puredata.info/listinfo/pd-announce ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] [PD-dev] tkwidgets
On Sun, 28 Aug 2011, Joe White wrote: To be honest I don't care. Ah. Nevermind then. If there are issues with ZenGarden then wouldn't it make sense to bring them up with the developer? It's not like they couldn't be resolved. No, because those issues were created on purpose. ___ | Mathieu Bouchard tél: +1.514.383.3801 Villeray, Montréal, QC ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] Webcam not working in Gridflow on Ubuntu
On Tue, 28 Jun 2011, IOhannes m zmoelnig wrote: the v4l2convert trick mentioned above, is a workaround to make applications not using libv4l to still be able to benefit from libv4l's color conversion routines. but really, the application (e.g. GF or Gem) should use libv4l natively. as far as i know, both do so, if they can find libv4l (+headers!) during configure/compile time. it seems however, that your version of Gem has found libv4l while it was built, whereas GF has not. if you compiled GF yourself, try installing libv4l-dev and then re-configure re-compile GF. Even when you compile GF with libv4l1 support, it doesn't use it by default. The default is still plain v4l1. I think that it's because some old cameras' v4l1 extensions don't work in libv4l1 at all, but I don't recall for sure. libv4l1 is going to be the default in the next release of GF. ___ | Mathieu Bouchard tél: +1.514.383.3801 Villeray, Montréal, QC ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] [PD-announce] gem 0.93.1
hello IOhannes, is gem 0.93 compiled with mingw, if not, is it planned? - IOhannes zmölnig zmoel...@iem.at a écrit : after a few days of waiting (for you) and hard labour (for me), Gem 0.93.1, the 1st bugfix release for the 0.93 series, has been released today. like always we have fixed numerous bugs and features, and most likely introduced an equal number of wishlists and showstoppers. noteable differences since 0.93.0: functionality bugs: - [pix_film] no longer crashes when sending an auto message to it, while no film is loaded - [pix_film]'s auto message actually does something - [pix_frei0r] no longer crashes when dynamically instantiating plugins documentation: - [pix_frei0r]/[pix_freeframe] help patches now mention how to dynamically load a plugin at runtime (or change the plugin) - [separator] help patch now explains how to only work on special openGL matrices binaries are available for w32 (installer zip), for the brave and adventurous there is the source code. binaries for OSX are still not available yet, but we hope to get them online soonish. grab it while it's hot: http://gem.iem.at/releases/0.93.1 alternatively you can get the files from https://sourceforge.net/projects/pd-gem mfgadr IOhannes ___ Pd-announce mailing list pd-annou...@iem.at http://lists.puredata.info/listinfo/pd-announce ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list -- Patrice Colet ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] [PD-announce] gem 0.93.1
On 08/28/2011 05:54 PM, Patrice Colet wrote: hello IOhannes, is gem 0.93 compiled with mingw, if not, is it planned? it's not compiled with mingw, and it is not planned for 0.93 Gem currently does not compile with mingw (see recent postings on gem-dev@), but it would be a nice feature to have for 0.94 (help would be appreciated; hint, hint :-)) apart from mingw currently not properly compiling Gem at all, there are some more things that ought be kept in mind: - i (personally) currently don't have time nor energy to setup a local mingw build machine for Gem - for video capture and image acquisition Gem uses DirectShow and i remember that there were problems using those with mingw - all the DirectShow stuff is no longer part of Gem proper, but lives in plugins (cool); unfortunately the plugins (still only) have a C++ API, so you couldn't use a plugin compiled with M$VC within Gem compiled on mingw. so having Gem build on MinGW would be great, but it is not very high on my todo list (but again, if you feel like doing the work, go ahead; in this case, it might be a good idea to join gem-dev@) fgmasdr IOhannes signature.asc Description: OpenPGP digital signature ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] [PD-dev] tkwidgets
If the developer exhibits a capacity for purposefulness, couldn't that same a sense of purpose be used to undo a mistake? Or do you suggest the errors were placed there as obstacles with malice aforethought? On Sun, 28 Aug 2011 11:34:18 -0400 (EDT) Mathieu Bouchard ma...@artengine.ca wrote: On Sun, 28 Aug 2011, Joe White wrote: If there are issues with ZenGarden then wouldn't it make sense to bring them up with the developer? It's not like they couldn't be resolved. No, because those issues were created on purpose. -- Andy Farnell padawa...@obiwannabe.co.uk ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] [PD-announce] gem 0.93.1
Okay i will join the gem-dev list when I'll get time to work on it... before I'd like to finish the pd-extended build system stuff, there still are problems to get it working. Using mingw would be great for me because we will be able to use Gem libs on gridflow. - IOhannes zmölnig zmoel...@iem.at a écrit : On 08/28/2011 05:54 PM, Patrice Colet wrote: hello IOhannes, is gem 0.93 compiled with mingw, if not, is it planned? it's not compiled with mingw, and it is not planned for 0.93 Gem currently does not compile with mingw (see recent postings on gem-dev@), but it would be a nice feature to have for 0.94 (help would be appreciated; hint, hint :-)) apart from mingw currently not properly compiling Gem at all, there are some more things that ought be kept in mind: - i (personally) currently don't have time nor energy to setup a local mingw build machine for Gem - for video capture and image acquisition Gem uses DirectShow and i remember that there were problems using those with mingw - all the DirectShow stuff is no longer part of Gem proper, but lives in plugins (cool); unfortunately the plugins (still only) have a C++ API, so you couldn't use a plugin compiled with M$VC within Gem compiled on mingw. so having Gem build on MinGW would be great, but it is not very high on my todo list (but again, if you feel like doing the work, go ahead; in this case, it might be a good idea to join gem-dev@) fgmasdr IOhannes -- Patrice Colet ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] [PD-announce] gem 0.93.1
On Sun, 28 Aug 2011, IOhannes zmölnig wrote: Gem currently does not compile with mingw (see recent postings on gem-dev@), but it would be a nice feature to have for 0.94 (help would be appreciated; hint, hint :-)) It's not that I would like to have the option of compiling Gem in MinGW, it's that I would like the default builds of Gem to be able to communicate with GridFlow. So it's either that Gem binaries for Windows all use MinGW, or that a workaround is created so that anything that communicates with Gem can do it without being compiled in MSVC. Otherwise, it would mean that GEM users who want to try GF have to reinstall a different GEM than default just to have something that runs with MinGW. Afaict, GridFlow will never run with MSVC. Well, it might not be using that many GCC extensions, but I haven't counted them. Maybe it's only variable-sized arrays on stack, and variable number of args in macros. ___ | Mathieu Bouchard tél: +1.514.383.3801 Villeray, Montréal, QC ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] [PD-dev] tkwidgets
On Sun, 28 Aug 2011, Andy Farnell wrote: If the developer exhibits a capacity for purposefulness, couldn't that same a sense of purpose be used to undo a mistake? Well, the developer would have to think of those things as mistakes first, and also, to think of vanilla's ways as being the solutions. When the idea of «cleaner design than vanilla's» is to use a big if else if else if else if else if else if instead of the constructor table and instead of every method table, does it make it look like you or I has any business trying to change the mind of the author, and does that look easier than (!!!) submitting patches to Miller ? ___ | Mathieu Bouchard tél: +1.514.383.3801 Villeray, Montréal, QC ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] [PD-dev] tkwidgets
- Original Message - From: Mathieu Bouchard ma...@artengine.ca To: Andy Farnell padawa...@obiwannabe.co.uk Cc: pd-list@iem.at Sent: Sunday, August 28, 2011 1:04 PM Subject: Re: [PD] [PD-dev] tkwidgets On Sun, 28 Aug 2011, Andy Farnell wrote: If the developer exhibits a capacity for purposefulness, couldn't that same a sense of purpose be used to undo a mistake? Well, the developer would have to think of those things as mistakes first, and also, to think of vanilla's ways as being the solutions. When the idea of «cleaner design than vanilla's» is to use a big if else if else if else if else if else if instead of the constructor table and instead of every method table, does it make it look like you or I has any business trying to change the mind of the author, and does that look easier than (!!!) submitting patches to Miller ? _Submitting_ patches to Miller is easy. -Jonathan ___ | Mathieu Bouchard tél: +1.514.383.3801 Villeray, Montréal, QC ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] sending image from of / libpd
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. libpd aims to provide a high-level API at a consistent level of abstraction, and I believe that that's the correct level of abstraction for the kind of work that libpd is intended for. Well, for the libpd message-passing, I felt like it added an API at the same level of abstraction as m_pd.h, except a tiny bit slower than SETFLOAT and SETSYMBOL macros, and which needed a bit more thread-safety than m_pd.h, as even the construction of the message has to be protected. Those are really small details, and to me, the biggie is that this API is not any easier than m_pd.h's message passing to a C programmer. The immediate motivation was to create an API that would be easy to wrap for languages like Java and Python, but I also have deeper reasons for wanting to work at this level of abstraction. I don't see any practical difference in easiness of wrapping for other languages. I don't know how you see that. I'm hoping that we'll see a major redesign of Pd in the not too distant future. One goal we talked about at PdCon is to allow multiple instances of Pd. I don't see any planning about this in the way that the libpd api works, and I don't see how the libpd api currently helps for that. Another change I'm hoping to see is a rewrite that takes advantage of multiple cores on current machines. What's a «rewrite», and how much actual change do you wish for ? Do you have a plan for actual changes to the API ? I also believe that such changes will be necessary to remain competitive. If anyone really needs a big speed hike, then how about integrating SSE support in vanilla and/or libpd ? The prototype was made in 2005 or so, and then abandoned. That's a lot easier to do than to support double/triple/quad CPUs. The libpd API is meant to be (mostly) above such implementation details, while the low-level API will almost certainly change when Pd is updated. Pd itself will be much more nimble and maintainable if developers think about it at a higher level of abstraction. What constitutes a higher level of abstraction ? BTW, yes, there are additions to your API that I hadn't seen, because I'm not using the latest version. ___ | Mathieu Bouchard tél: +1.514.383.3801 Villeray, Montréal, QC ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] [PD-dev] tkwidgets
On Sun, 28 Aug 2011, Jonathan Wilkes wrote: _Submitting_ patches to Miller is easy. hehe, yeah, I know what you mean, though I really meant getting the patches accepted. ___ | Mathieu Bouchard tél: +1.514.383.3801 Villeray, Montréal, QC___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] [PD-dev] tkwidgets
I think reasonable suggestions might be welcome. Some say the sulphur fumes, screams and maniacal laughter emanating from Martin and Joe's subterranean laboratory beneath the opera house catacombs is too intimidating. But I've heard that mortals making offerings have been spared. Occasionally. On Sun, 28 Aug 2011 13:04:44 -0400 (EDT) Mathieu Bouchard ma...@artengine.ca wrote: On Sun, 28 Aug 2011, Andy Farnell wrote: If the developer exhibits a capacity for purposefulness, couldn't that same a sense of purpose be used to undo a mistake? Well, the developer would have to think of those things as mistakes first, and also, to think of vanilla's ways as being the solutions. When the idea of «cleaner design than vanilla's» is to use a big if else if else if else if else if else if instead of the constructor table and instead of every method table, does it make it look like you or I has any business trying to change the mind of the author, and does that look easier than (!!!) submitting patches to Miller ? ___ | Mathieu Bouchard tél: +1.514.383.3801 Villeray, Montréal, QC -- Andy Farnell padawa...@obiwannabe.co.uk ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] [PD-dev] tkwidgets
- Original Message - From: Martin Peach martin.pe...@sympatico.ca To: Jonathan Wilkes jancs...@yahoo.com Cc: András Murányi muran...@gmail.com; pd-list pd-list@iem.at Sent: Friday, August 26, 2011 2:30 PM Subject: Re: [PD] [PD-dev] tkwidgets On 2011-08-26 11:31, Jonathan Wilkes wrote: It might be a good idea to list the problems with tcl/tk so we can weigh them against the difficulty of using a different GUI toolkit. The problems I see are: * difficult to implement a decent zoom function for a canvas * can't display png without the Img library (included in 8.6) * can't do alpha transparency Of the three I listed, I'm mostly interested in the first as it means that (without prior planning) it's hard to take a patch you've been working on at font size 10 and display it adequately over a projector, for example. (If there's a work around I'd like to know it.) I'd like to hear others, but I'm mostly interested in problems with tcl/tk = 8.5 as the GUI. * Because tcl/tk is an interpreted language it is a lot slower than a compiled language: you have a script in ASCII that has to go through a processor that interprets the script to call a lower-level machine that actually does the work, while Qt is compiled so it does what you ask it directly, more or less. If there are any GUI developers out there, I'd love to see a few comparisons between tk canvas and Qt graphics view-- say, moving a large number of rectangles with the mouse, or creating/destroying a bunch of polygons, and looking at memory/cpu usage. -Jonathan ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] sending image from of / libpd
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 that can be slower, is if ever you need to copy the list or part thereof. But until the method returns, the argc and argv parametres can be used directly. ___ | Mathieu Bouchard tél: +1.514.383.3801 Villeray, Montréal, QC ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] [PD-announce] gem 0.93.1
Le 28/08/2011 17:27, IOhannes zmölnig a écrit : after a few days of waiting (for you) and hard labour (for me), Gem 0.93.1, the 1st bugfix release for the 0.93 series, has been released today. like always we have fixed numerous bugs and features, and most likely introduced an equal number of wishlists and showstoppers. noteable differences since 0.93.0: functionality bugs: - [pix_film] no longer crashes when sending an auto message to it, while no film is loaded - [pix_film]'s auto message actually does something - [pix_frei0r] no longer crashes when dynamically instantiating plugins documentation: - [pix_frei0r]/[pix_freeframe] help patches now mention how to dynamically load a plugin at runtime (or change the plugin) - [separator] help patch now explains how to only work on special openGL matrices OK, thanx for the clarification about [separator]. ++ Jack binaries are available for w32 (installer zip), for the brave and adventurous there is the source code. binaries for OSX are still not available yet, but we hope to get them online soonish. grab it while it's hot: http://gem.iem.at/releases/0.93.1 alternatively you can get the files from https://sourceforge.net/projects/pd-gem mfgadr IOhannes ___ Pd-announce mailing list pd-annou...@iem.at http://lists.puredata.info/listinfo/pd-announce ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] [PD-announce] gem 0.93.1
On 08/28/2011 06:41 PM, Mathieu Bouchard wrote: On Sun, 28 Aug 2011, IOhannes zmölnig wrote: Gem currently does not compile with mingw (see recent postings on gem-dev@), but it would be a nice feature to have for 0.94 (help would be appreciated; hint, hint :-)) It's not that I would like to have the option of compiling Gem in MinGW, it's that I would like the default builds of Gem to be able to communicate with GridFlow. So it's either that Gem binaries for Windows all use MinGW, or that a workaround is created so that anything that communicates with Gem can do it without being compiled in MSVC. Otherwise, it would mean that GEM users who want to try GF have to reinstall a different GEM than default just to have something that runs with MinGW. i'm aware of the problem. however, the problem is the solution. gfmasr IOhannes signature.asc Description: OpenPGP digital signature ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] [PD-announce] gem 0.93.1
On Sun, 28 Aug 2011, IOhannes zmölnig wrote: i'm aware of the problem. however, the problem is the solution. What does that mean ? ___ | Mathieu Bouchard tél: +1.514.383.3801 Villeray, Montréal, QC ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] [PD-announce] gem 0.93.1
On 08/28/2011 07:44 PM, Mathieu Bouchard wrote: On Sun, 28 Aug 2011, IOhannes zmölnig wrote: i'm aware of the problem. however, the problem is the solution. What does that mean ? i meant: i'm aware of the problem, however i don't see a solution. it was not meant to be self-referring. gfmasdr IOhannes signature.asc Description: OpenPGP digital signature ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] sending image from of / libpd
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 editor. That doesn't mean that that's a good level of abstraction to work at. libpd aims to provide a high-level API at a consistent level of abstraction, and I believe that that's the correct level of abstraction for the kind of work that libpd is intended for. Well, for the libpd message-passing, I felt like it added an API at the same level of abstraction as m_pd.h, except a tiny bit slower than SETFLOAT and SETSYMBOL macros, and which needed a bit more thread-safety than m_pd.h, as even the construction of the message has to be protected. Those are really small details, and to me, the biggie is that this API is not any easier than m_pd.h's message passing to a C programmer. Matter of taste, I suppose. When working with libpd, I want to think in terms of calls to libpd. Reaching into m_pd.h is a context switch that I'd rather avoid, and with the latest revision of libpd I can avoid it altogether. And I do think that saying libpd_get_symbol(a) is simpler than saying a.a_w.w_symbol-s_name (although the former is just a macro that maps to the latter). Then again, my instincts run libertarian. I have no desire to tell you how to do your work. When you include z_libpd.h, you get m_pd.h with it. If you want to work too hard, I won't stand in your way;) The immediate motivation was to create an API that would be easy to wrap for languages like Java and Python, but I also have deeper reasons for wanting to work at this level of abstraction. I don't see any practical difference in easiness of wrapping for other languages. I don't know how you see that. One major simplification is the use of built-in data types vs custom structs and unions. Many of the functions that you find pointless basically do two things; they convert const char* to t_symbol and then delegate to functions in m_pd.h. With this transition to built-in data types, you can simply run SWIG on the header file and automatically create bindings for a significant part of libpd for lots of target languages; only the callbacks will require some additional work. Without this conversion, you would have to descend into the netherworld of custom typemaps and such. I'm hoping that we'll see a major redesign of Pd in the not too distant future. One goal we talked about at PdCon is to allow multiple instances of Pd. I don't see any planning about this in the way that the libpd api works, and I don't see how the libpd api currently helps for that. It doesn't. The point is that it would be easy to extend because you'd just need to add an instance pointer to the parameter list of a smallish collection of functions. Incidentally, I've also gotten flak for not baking any multi-instance support into the initial version of libpd (I did consider it, but it seemed pointless because with the current version of Pd it would still have just one single instance). I figure that as long as I'm drawing fire from both low-level C hackers and high-level OOP types, I must be doing something right;) Another change I'm hoping to see is a rewrite that takes advantage of multiple cores on current machines. What's a «rewrite», and how much actual change do you wish for ? Do you have a plan for actual changes to the API ? It's more of a general consideration, and I don't have any road map in mind. Right now I'm just hoping to have a conversation about this. I also believe that such changes will be necessary to remain competitive. If anyone really needs a big speed hike, then how about integrating SSE support in vanilla and/or libpd ? The prototype was made in 2005 or so, and then abandoned. That's a lot easier to do than to support double/triple/quad CPUs. I'd be more than happy to see that, ideally in vanilla because I want libpd to remain nothing more than a thin wrapper on top of Pd. The libpd API is meant to be (mostly) above such implementation details, while the low-level API will almost certainly change when Pd is updated. Pd itself will be much more nimble and maintainable if developers think about it at a higher level of abstraction. What constitutes a higher level of abstraction ? In this case, I mostly mean hiding implementation details. For example, as an application programmer I don't want to know what exactly is going on inside an instance of t_atom, I just want to get string or float values in and out. Cheers, Peter ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] [PD-announce] gem 0.93.1
Iohannes Thanks for the clarification regarding Frei0r/freeframe! From: Jack j...@rybn.orgmailto:j...@rybn.org Date: Sun, 28 Aug 2011 19:42:30 +0200 To: pd-list@iem.atmailto:pd-list@iem.at Subject: Re: [PD] [PD-announce] gem 0.93.1 Le 28/08/2011 17:27, IOhannes zmölnig a écrit : after a few days of waiting (for you) and hard labour (for me), Gem 0.93.1, the 1st bugfix release for the 0.93 series, has been released today. like always we have fixed numerous bugs and features, and most likely introduced an equal number of wishlists and showstoppers. noteable differences since 0.93.0: functionality bugs: - [pix_film] no longer crashes when sending an auto message to it, while no film is loaded - [pix_film]'s auto message actually does something - [pix_frei0r] no longer crashes when dynamically instantiating plugins documentation: - [pix_frei0r]/[pix_freeframe] help patches now mention how to dynamically load a plugin at runtime (or change the plugin) - [separator] help patch now explains how to only work on special openGL matrices OK, thanx for the clarification about [separator]. ++ Jack binaries are available for w32 (installer zip), for the brave and adventurous there is the source code. binaries for OSX are still not available yet, but we hope to get them online soonish. grab it while it's hot: http://gem.iem.at/releases/0.93.1 alternatively you can get the files from https://sourceforge.net/projects/pd-gem mfgadr IOhannes ___ Pd-announce mailing list pd-annou...@iem.atmailto:pd-annou...@iem.athttp://lists.puredata.info/listinfo/pd-announce ___ Pd-list@iem.atmailto:Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list ___ Pd-list@iem.atmailto:Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] [PD-announce] gem 0.93.1
Is there a how-to for compiling GEM on OSX? I really want to get started with frei0r and freeframe pp ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] sending image from of / libpd
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 simply run SWIG on the header file and automatically create bindings for a significant part of libpd for lots of target languages; only the callbacks will require some additional work. Without this conversion, you would have to descend into the netherworld of custom typemaps and such. When you are using typemaps, do you have the impression that you're using SWIG in a high-level way ? Isn't the lack of typemaps a sign that your API isn't very abstract ? Incidentally, I've also gotten flak for not baking any multi-instance support into the initial version of libpd (I did consider it, but it seemed pointless because with the current version of Pd it would still have just one single instance). The point would be to make all the backward-compat and forward-compat you need for supporting a future version of pd that will include features that you're already thinking about. But you don't have to add an argument everywhere. I bet that you'll add a libpd_set_current_pd_instance(t_pd_interpreter *) function that will set a global variable used by the rest of the pd api. That would be consistent with the stateful message-passing in many small steps using a hidden global array. Later you can make all of that thread-safe by making all of those functions call pthread_self() to figure out which thread they're in, and replace the globals by threadwise-locals. I figure that as long as I'm drawing fire from both low-level C hackers and high-level OOP types, I must be doing something right;) It's bad to insist on a low-level vs high-level dichotomy. It's been quite a while that those words cause confusion because they give the impression that those levels are all stacked in top of each other along one axis of highness. The truth is a lot more complicated, in which levels aren't well-defined, more abstract isn't necessarily better, more concrete isn't necessarily better either, it depends a lot on what you want to achieve, and what you expect for the future, etc. ; I still use expressions like low-level or high-level sometimes, but it isn't as seriously as when people first invented the term. So, it's possible that you're doing something right, but drawing fire from people that you categorise in two bins is probably not a good sign of what you think it is. It's more of a general consideration, and I don't have any road map in mind. Right now I'm just hoping to have a conversation about this. Well, does that involve multiple interpreters, with one interpreter per core, but still in the same process, with a way to pass messages quickly from one interpreter to the other ? Would they be sharing the same gensym, or would they need to re-gensym everything when talking from one interpreter to the other ? ___ | Mathieu Bouchard tél: +1.514.383.3801 Villeray, Montréal, QC___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] sending image from of / libpd
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 ever called high-level... Well, I'm taking a complicated implementation detail (t_symbol) and I'm providing an API that lets application developers to refer to this detail by name, without having to think about the data structure behind it. I consider that an abstraction, even if the name is given as const char *. Incidentally, I've also gotten flak for not baking any multi-instance support into the initial version of libpd (I did consider it, but it seemed pointless because with the current version of Pd it would still have just one single instance). The point would be to make all the backward-compat and forward-compat you need for supporting a future version of pd that will include features that you're already thinking about. Nah, that would have been a clear case of overdesign, preparing for some future development that may never happen. We'll figure out how to support multiple instances when multiple instances become a possibility. But you don't have to add an argument everywhere. I bet that you'll add a libpd_set_current_pd_instance(**t_pd_interpreter *) function that will set a global variable used by the rest of the pd api. That would be consistent with the stateful message-passing in many small steps using a hidden global array. Later you can make all of that thread-safe by making all of those functions call pthread_self() to figure out which thread they're in, and replace the globals by threadwise-locals. I thought I had already explained this when we had our little chat over at pd-everywhere, but I'll try again. Calling the message assembly API of libpd stateful is technically true but completely misleading because the hidden state is only meant to be used in a very specific and limited way. 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. Doing the entire conversion in JNI would be a huge pain, and dynamically allocating t_atom arrays in JNI would be a pain, too. So, I chose to allocate one array up front and then provide a set of functions that will populate the array with values, in a way that's easy to wrap for Java. The fact that it's a global array does not cause any problems because the entire calling sequence needs to be protected by a lock, and so there is only one method that will ever access the array at one time. The lock would be required in any case, because any access to the symbol table needs to be locked. The upshot is, the array you mention really acts as a local variable for a couple of methods in languages like Java or Python or Objective-C. The fact that it's currently a hidden global variable is an implementation detail that does not add problematic global state to libpd. (I can't even think of a way to creatively misuse this mechanism to introduce global statue through the back door.) Believe me, I've agonized over this, but it's been working very nicely for more than a year now, and I still can't think of a simpler way to assemble compound messages in Java. It's more of a general consideration, and I don't have any road map in mind. Right now I'm just hoping to have a conversation about this. Well, does that involve multiple interpreters, with one interpreter per core, but still in the same process, with a way to pass messages quickly from one interpreter to the other? That's not at all what I have in mind. What I'm really thinking about is one interpreter that does a topological sort on the signal processing chain and then parallelizes the computation on the fly, but that's a topic for another day. I'm outta here. Cheers, Peter ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] [PD-announce] gem 0.93.1
Iohannes, cheers for the bug fix! On Sun, Aug 28, 2011 at 8:27 PM, Pagano, Patrick p...@digitalworlds.ufl.edu wrote: Is there a how-to for compiling GEM on OSX? I really want to get started with frei0r and freeframe pp ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] [PD-dev] tkwidgets
That has little to do with Tcl/Tk being slow. That has a lot more to do with how Pd is implemented. It generates and sends raw Tcl to the GUI, and if you are moving a lot of stuff, that means a lot of raw Tcl needs to be generated, sent, parsed, and executed. That definitely slows things down. In my tests, I saw that moving a big patch around or animating a big array could send 1 megabyte of raw Tcl to the GUI per second. Receiving, parsing, and executing 1 megabyte of code per second is actually pretty good, IMHO. What needs to happen is that Pd should call Tcl procs not send blocks of raw Tcl. .hc On Aug 26, 2011, at 5:19 PM, João Pais wrote: tcl/tk behaves very slowly for fast calls, such as when dragging an array of considerable size, or a big group of objects? afaik this is something that could be improved in the present platform, but how better could it be when using another gui framework? It might be a good idea to list the problems with tcl/tk so we can weigh them against the difficulty of using a different GUI toolkit. The problems I see are: * difficult to implement a decent zoom function for a canvas * can't display png without the Img library (included in 8.6) * can't do alpha transparency Of the three I listed, I'm mostly interested in the first as it means that (without prior planning) it's hard to take a patch you've been working on at font size 10 and display it adequately over a projector, for example. (If there's a work around I'd like to know it.) I'd like to hear others, but I'm mostly interested in problems with tcl/tk = 8.5 as the GUI. ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list Access to computers should be unlimited and total. - the hacker ethic ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] [PD-dev] tkwidgets
That's an excellent example. In the case I just wrote about, using Tcl's tag and move could reduce 500 KB/sec of Tcl code to 5KB/sec. .hc On Aug 26, 2011, at 9:46 PM, Patrice Colet wrote: This is very slow because everything selected is moving, this method makes a very slow dragging, if a rectangle is drawn just to show up area of selection that is been moving, that would be very fluid, and it shouldn't so hard to implement. I guess it would even be possible to capture the selection as an image, so we would drag just an image, and then there would be no difference. something like this: B1-motion --- capture area to move, copy in clipboard selected objects and args, build an image or a rectangle, delete the selection, and move the image or rectangle. B1-Release --- delete the image or rectangle, and paste the selected object(s). - João Pais jmmmp...@googlemail.com a écrit : tcl/tk behaves very slowly for fast calls, such as when dragging an array of considerable size, or a big group of objects? afaik this is something that could be improved in the present platform, but how better could it be when using another gui framework? It might be a good idea to list the problems with tcl/tk so we can weigh them against the difficulty of using a different GUI toolkit. The problems I see are: * difficult to implement a decent zoom function for a canvas * can't display png without the Img library (included in 8.6) * can't do alpha transparency Of the three I listed, I'm mostly interested in the first as it means that (without prior planning) it's hard to take a patch you've been working on at font size 10 and display it adequately over a projector, for example. (If there's a work around I'd like to know it.) I'd like to hear others, but I'm mostly interested in problems with tcl/tk = 8.5 as the GUI. ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list -- Patrice Colet ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list ¡El pueblo unido jamás será vencido! ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] [PD-announce] gem 0.93.1
On Aug 28, 2011, at 12:08 PM, IOhannes zmölnig wrote: On 08/28/2011 05:54 PM, Patrice Colet wrote: hello IOhannes, is gem 0.93 compiled with mingw, if not, is it planned? it's not compiled with mingw, and it is not planned for 0.93 Gem currently does not compile with mingw (see recent postings on gem-dev@), but it would be a nice feature to have for 0.94 (help would be appreciated; hint, hint :-)) apart from mingw currently not properly compiling Gem at all, there are some more things that ought be kept in mind: - i (personally) currently don't have time nor energy to setup a local mingw build machine for Gem - for video capture and image acquisition Gem uses DirectShow and i remember that there were problems using those with mingw - all the DirectShow stuff is no longer part of Gem proper, but lives in plugins (cool); unfortunately the plugins (still only) have a C++ API, so you couldn't use a plugin compiled with M$VC within Gem compiled on mingw. so having Gem build on MinGW would be great, but it is not very high on my todo list (but again, if you feel like doing the work, go ahead; in this case, it might be a good idea to join gem-dev@) I believe that the DirectShow stuff was resolved many years ago. But I've never tried it. Here's instructions on how to do it with DirectX 9: http://nova.polymtl.ca/~guardia/programming.php .hc Mistrust authority - promote decentralization. - the hacker ethic ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] [PD-announce] gem 0.93.1
The 0.43 Pd-extended nightly builds include it, AFAIK. .hc On Aug 28, 2011, at 3:27 PM, Pagano, Patrick wrote: Is there a how-to for compiling GEM on OSX? I really want to get started with frei0r and freeframe pp ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list ¡El pueblo unido jamás será vencido! ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] search plugin update
0 0 is problematic on couple platforms. On Mac OS X, the menubar is always there, so it puts the window header behind on menubar. A similar problem happens on GNOME. .hc On Aug 25, 2011, at 5:33 PM, Jonathan Wilkes wrote: Ok, fixed the weird resizing issue when the text in the status area is larger than the window. Fixed search window to appear at 0 0 on when it's first created. Fixed font sizing bindings. Fixed minimum font size. -Jonathan - Original Message - From: Hans-Christoph Steiner h...@at.or.at To: Mathieu Bouchard ma...@artengine.ca Cc: Jonathan Wilkes jancs...@yahoo.com; pd-list List pd-list@iem.at Sent: Sunday, August 7, 2011 5:38 PM Subject: Re: [PD] search plugin update On Aug 7, 2011, at 2:51 PM, Mathieu Bouchard wrote: On Sat, 6 Aug 2011, Hans-Christoph Steiner wrote: - on Mac OS X Cmd-Shift-= (i.e. Cmd-+) is the standard key for increasing the size of the text. Currently, its Cmd-=. It will break on keyboard layouts that are not QWERTY or that are heavily modified QWERTY. When I designed some things in the default DD keyboard bindings, I only had US keyboard and CF-family keyboards in mind (french QWERTY used in Québec) and then someone notified me that I couldn't distinguish Alt+Shift+1 from Alt+1 because 1 is already shifted in AZERTY (it's Shift-, whereas is not shifted). German QWERTZ has = on Shift+0 and * on Shift++, meaning + is unshifted ; however, Swiss QWERTZ has + shifted as Shift+1, and then there are other QWERTZ than that... It'd be something to test, Cmd-+ might work as a keybinding, and would then work on other keyboards. Or perhaps you can just bind to both Cmd- Shift-+ and Cmd-+. For other platforms, its not a big deal since the keybindings are not very consistent. On Mac OS X, they are quite consistent across OS and apps, so people notice wrong bindings a lot more. .hc “We must become the change we want to see. - Mahatma Gandhi search-plugin.tcl 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-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] Mac OSX 10.7 resume states crash Pd-extended
Hmm.. maybe that should be the first line of the Tcl main. cheers Miller On Sun, Aug 28, 2011 at 05:16:15AM -0400, Dan Wilcox wrote: Since I've upgraded to Mac OSX 10.7 Lion, I've noticed Pd-extended 0.42.5 seemed to crash on startup sometimes, while other times it was fine. It finally dawned on me that OSX is trying to load the previous saved state since I had CMD-Q'd Pd with windows open. It automatically opens those windows at start. I assume pd is not yet ready for these and crashes due to some init order issue ... If anyone else has noticed this, a quick fix is to delete the save state so you can open Pd again. Then make sure to close all windows before quitting the next time ... thanks for the help apple. http://osxdaily.com/2011/07/17/delete-specific-application-saved-states-from-mac-os-x-10-7-lion-resume/ Commandline: rm -rf ~/Library/Saved\ Application\ State/org.puredata.* Dan Wilcox danomatika.com robotcowboy.com ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] Mac OSX 10.7 resume states crash Pd-extended
Nah, you're fine. It's a problem with Pd-extended 0.42.5 ... Pd-0.43.0 Vanilla handles resume fine. :D On Aug 28, 2011, at 10:58 PM, Miller Puckette wrote: Hmm.. maybe that should be the first line of the Tcl main. cheers Miller On Sun, Aug 28, 2011 at 05:16:15AM -0400, Dan Wilcox wrote: Since I've upgraded to Mac OSX 10.7 Lion, I've noticed Pd-extended 0.42.5 seemed to crash on startup sometimes, while other times it was fine. It finally dawned on me that OSX is trying to load the previous saved state since I had CMD-Q'd Pd with windows open. It automatically opens those windows at start. I assume pd is not yet ready for these and crashes due to some init order issue ... If anyone else has noticed this, a quick fix is to delete the save state so you can open Pd again. Then make sure to close all windows before quitting the next time ... thanks for the help apple. http://osxdaily.com/2011/07/17/delete-specific-application-saved-states-from-mac-os-x-10-7-lion-resume/ Commandline: rm -rf ~/Library/Saved\ Application\ State/org.puredata.* Dan Wilcox danomatika.com robotcowboy.com ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list Dan Wilcox danomatika.com robotcowboy.com ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] sending image from of / libpd
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, isn't there some sort of limit on the length of lists or does libpd handle this for you? On Aug 28, 2011, at 1:33 PM, Mathieu Bouchard wrote: 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 that can be slower, is if ever you need to copy the list or part thereof. But until the method returns, the argc and argv parametres can be used directly. ___ | Mathieu Bouchard tél: +1.514.383.3801 Villeray, Montréal, QC Dan Wilcox danomatika.com robotcowboy.com ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] sending image from of / libpd
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 have the option to have your data as atoms in the first place, so that they don't have to be copied. Besides, isn't there some sort of limit on the length of lists or does libpd handle this for you? With z_libpd.h, you have an artificial limit of 32 atoms per message, whereas with m_pd.h, there's no formal limit ; in practice the OS will limit you to something like 100 atoms on the stack at once, for example. On 32-bit Linux, the limit can be as high as 800 atoms (64 megs) but I don't remember what the default limits are. ___ | Mathieu Bouchard tél: +1.514.383.3801 Villeray, Montréal, QC ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
[PD] Pd-gui bug (was Re: search plugin update)
Test1: Gnome 3 (Fedora 15) -- no problems Gnome 2.32.0 (Ubuntu Maverick) -- no problems OSX 10.7 -- problem: window decoration behind Apple's menubar. Test2: Tried a little stand-alone version of my plugin. Still specifying 0 0 screen coordinates, and Apple automatically puts the .search window below the menu bar, as it does for everything else I've ever seen in OSX except this issue. Test3: Tried any number of my PDDP help patches, which all have 0 0 specified as the coordinates for the patch window. Again, Apple does the right thing and shifts it down an appropriate amount. Test4: Tried to fool wish on OSX into putting a toplevel underneath the menubar. Can't do it. Hypothesis: Something isn't set correctly in pd-gui, but all I can see (at a glance) are options that have nothing to do with window position, and some variables: menubarsize and windowframey. -Jonathan - Original Message - From: Hans-Christoph Steiner h...@at.or.at To: Jonathan Wilkes jancs...@yahoo.com Cc: Mathieu Bouchard ma...@artengine.ca; pd-list List pd-list@iem.at Sent: Sunday, August 28, 2011 10:13 PM Subject: Re: [PD] search plugin update 0 0 is problematic on couple platforms. On Mac OS X, the menubar is always there, so it puts the window header behind on menubar. A similar problem happens on GNOME. .hc On Aug 25, 2011, at 5:33 PM, Jonathan Wilkes wrote: Ok, fixed the weird resizing issue when the text in the status area is larger than the window. Fixed search window to appear at 0 0 on when it's first created. Fixed font sizing bindings. Fixed minimum font size. -Jonathan - Original Message - From: Hans-Christoph Steiner h...@at.or.at To: Mathieu Bouchard ma...@artengine.ca Cc: Jonathan Wilkes jancs...@yahoo.com; pd-list List pd-list@iem.at Sent: Sunday, August 7, 2011 5:38 PM Subject: Re: [PD] search plugin update On Aug 7, 2011, at 2:51 PM, Mathieu Bouchard wrote: On Sat, 6 Aug 2011, Hans-Christoph Steiner wrote: - on Mac OS X Cmd-Shift-= (i.e. Cmd-+) is the standard key for increasing the size of the text. Currently, its Cmd-=. It will break on keyboard layouts that are not QWERTY or that are heavily modified QWERTY. When I designed some things in the default DD keyboard bindings, I only had US keyboard and CF-family keyboards in mind (french QWERTY used in Québec) and then someone notified me that I couldn't distinguish Alt+Shift+1 from Alt+1 because 1 is already shifted in AZERTY (it's Shift-, whereas is not shifted). German QWERTZ has = on Shift+0 and * on Shift++, meaning + is unshifted ; however, Swiss QWERTZ has + shifted as Shift+1, and then there are other QWERTZ than that... It'd be something to test, Cmd-+ might work as a keybinding, and would then work on other keyboards. Or perhaps you can just bind to both Cmd-Shift-+ and Cmd-+. For other platforms, its not a big deal since the keybindings are not very consistent. On Mac OS X, they are quite consistent across OS and apps, so people notice wrong bindings a lot more. .hc “We must become the change we want to see. - Mahatma Gandhi search-plugin.tcl 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 search-plugin.tcl Description: Tcl script ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] sending image from of / libpd
- 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 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 have the option to have your data as atoms in the first place, so that they don't have to be copied. Besides, isn't there some sort of limit on the length of lists or does libpd handle this for you? 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~] whereas with m_pd.h, there's no formal limit ; in practice the OS will limit you to something like 100 atoms on the stack at once, for example. On 32-bit Linux, the limit can be as high as 800 atoms (64 megs) but I don't remember what the default limits are. ___ | Mathieu Bouchard tél: +1.514.383.3801 Villeray, Montréal, QC ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] sending image from of / libpd
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 again. Calling the message assembly API of libpd stateful is technically true but completely misleading because the hidden state is only meant to be used in a very specific and limited way. Hidden states usually are meant to be used in very specific and limited ways... I don't know at all the distinction you're trying to make. The statefulness of libpd is not misleading. Trying to say that it's not really stateful, is misleading. I don't know what kind of connotations the statefulness means to you and why you're trying to avoid calling it as such. Anyway, it's not a big loss to have statefulness in those circumstances, as it's just before the beginning of a part that would have to be locked anyway, or in a part that would have to be locked anyway (if calling gensym). 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 ? ... 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). ___ | Mathieu Bouchard tél: +1.514.383.3801 Villeray, Montréal, QC___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] sending image from of / libpd
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 ? And then, they have to be sent using libpd_add_ functions, because with typedmess or outlet_anything, you have no limit other than the OS' maximum stack size. ___ | Mathieu Bouchard tél: +1.514.383.3801 Villeray, Montréal, QC ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] sending image from of / libpd
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. I think it's reasonable to limit the message size, but 32 may be too small for some. It would make sense for libpd to have a call that would allow users to set the max message size, akin to how you can set the max packet size on sockets etc 32 is fine for most people, but there are uses for more ... Also, I imagine you don't have this limitation using the new *t_atom sending func. Is this true Peter? On Aug 29, 2011, at 1:15 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 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 have the option to have your data as atoms in the first place, so that they don't have to be copied. Besides, isn't there some sort of limit on the length of lists or does libpd handle this for you? 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~] whereas with m_pd.h, there's no formal limit ; in practice the OS will limit you to something like 100 atoms on the stack at once, for example. On 32-bit Linux, the limit can be as high as 800 atoms (64 megs) but I don't remember what the default limits are. ___ | Mathieu Bouchard tél: +1.514.383.3801 Villeray, Montréal, QC ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list Dan Wilcox danomatika.com robotcowboy.com ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
