[PD] [PD-announce] Xth Sense - Enhanced musical bodies @ Pure Data Convention 2011
(sorry for x-post) Dear all, here a brief update and cordial invitation. If you are around, feel free to drop me a line! ~ __8th August / 13.00-17.30 WORKSHOP: Xth Sense: Biophysical Music @ Pure Data Convention http://www.uni-weimar.de/medien/wiki/PDCON:Workshops/Xth_Sense,_Biophysical_Music __9th August / 9.30 PAPER: A Pd framework for the Xth Sense: enabling computers to sense human kinetic behaviour http://www.uni-weimar.de/medien/wiki/PDCON:Conference/A_Pd_framework_for_the_Xth_Sense:_enabling_computers_to_sense_human_kinetic_behaviour __21.30 CONCERT Music for Flesh II http://www.uni-weimar.de/medien/wiki/PDCON:Concerts/Marco_Donnarumma ~ Complete schedule of the event http://www.uni-weimar.de/medien/wiki/PDCON:Schedule Best wishes, -- Marco Donnarumma Independent New Media and Sonic Arts Professional, Performer, Instructor ACE, Sound Design MSc by Research (ongoing) The University of Edinburgh, UK ~ Portfolio: http://marcodonnarumma.com Lab: http://www.thesaddj.com | http://cntrl.sourceforge.net | http://www.flxer.net Event: http://www.liveperformersmeeting.net ___ 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] netsend/netreceive + GUI bug
If you are indeed talking about vanilla netsend and netreceive, the poll function is called during pd's main loop, not when something arrives at the socket. In x_net.c : sys_addpollfn(sockfd, (t_fdpollfn)socketreceiver_read, y); socketreceiver_read is in s_inter.c: void socketreceiver_read(t_socketreceiver *x, int fd) sys_addpollfunction schedules the function to be called each pass through Pd's main loop. Martin If that is the case, then it seems the bug lies elsewhere but is there nonetheless. The clock_delay workaround has fixed this in pd-l2ork permanently and I am yet to experience gui freeze that has been plaguing our setup way too often before the said workaround. ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
[PD] Turing Tarpit (was Re: (breaking symbols))
On Thu, 4 Aug 2011, Jonathan Wilkes wrote: I don't understand what you're saying about receive symbols. How do you get the single characters in the first place? Oh, nevermind. Just a silly mistake of mine. Anyway... I think that all this kind of thing will do, is scare off any potential pd users that like clean designs... I mean, such patches are quite skilled, but wouldn't it be nice if such skills could concentrate more on things that aren't Turing Tarpit Voodoo Dance. http://en.wikipedia.org/wiki/Turing_tarpit It does scare me that my [list-drip] is more used than my [foreach]. Both do the same thing, but [list-drip] is more twisted, much slower than [foreach], and I originally designed it to show how ridiculous things can get when trying to be efficient while sticking to what plain vanilla 42 has to offer. The answer is that what is considered the standard class library (used by everybody) has to grow faster than what someone is willing to do. Few people have the luxury of holding back additions to core software while pondering a few years on how to name them. I consider my [list-drip] to be a small improvement over the older [list-drip]. The big improvement is when people will stop insisting on using an abstraction for doing something that ought to be written in C. ___ | 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] (breaking symbols) was Re: find a list of numbers in a text file
On Wed, 3 Aug 2011, Jonathan Wilkes wrote: The idiosyncratic recursion happens when combining the single digits to make the final two values of the numerator and denominator. It's a [list split 1] with the middle outlet to a [t a] that feeds back into the left inlet. This outputs the list backwards-- I'm not exactly sure why, but it's handy in this case because I can just multiply each digit by increasing powers of ten and accumulate to get the final value for the numerator. (Same process for the denominator.) There's the danger of a stack overflow, but it's unlikely that either part of the fraction would have more than 249 digits. I think I had made such a recursion in an intermediate version of [list-drip] that I didn't publish, which might have been a bit faster, but having a limit of 200 or 300 levels wasn't fine at all. Who would I be to say that people can't have uses for more elements than that ? That's why I made a half-half splitter which uses only log2(n) recursion levels, which means it's only one more level for each time you double the list size. Actually now that I look at it, there should be a much greater danger of a stack overflow in the outer loop, because there are seven objects involved in the recursion. Not sure I understand the relationship between # of objects in recursive chain and max # function calls before stack overflow. Yeah, for Pd, it's a matter of maximum number of levels of calls, whereas for the OS, what matters is the total size in bytes. You'll normally reach Pd's limit a lot faster. The number of levels of calls is the number of calls per recursion times the number of recursions. IIRC, much older versions of Pd used a stack size check in bytes, but it caused problems real quickly. I don't remember whether the change had to do with the introduction of the [list] classes, which use stack-allocated buffers. ___ | 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] search plugin update
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... ___ | 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] netsend/netreceive + GUI bug
Here's a guess... if incoming (vanilla) netreceive traffic is swamping Pd, then since Pd prioritizes input from GUI above output back to GUI, the output never gets scheduled. If that were happening, you'd see the windows freeze but still be able to send Pd events from the GUI (hitting buttons in the patch, for instance.) I haven't recreated the situation myself yet, but will do that at some point to try to get a better idea. At any rate, it's likely that incoming net traffic is also getting dropped - not a good scenario. Ideally there should be a some way for Pd to sense that so that the patch could send out requests to slow the flow down before it starts dropping packets. In the meantime, a possible workaround: send occasional pings to the receiving Pd, hav ethe Pd patch echo the pings back to tne sending patch, and have the sending patch not allow more than a certain number of other messages go out between pings. cheers Miller On Sun, Aug 07, 2011 at 11:56:45AM -0400, Ivica Ico Bukvic wrote: If you are indeed talking about vanilla netsend and netreceive, the poll function is called during pd's main loop, not when something arrives at the socket. In x_net.c : sys_addpollfn(sockfd, (t_fdpollfn)socketreceiver_read, y); socketreceiver_read is in s_inter.c: void socketreceiver_read(t_socketreceiver *x, int fd) sys_addpollfunction schedules the function to be called each pass through Pd's main loop. Martin If that is the case, then it seems the bug lies elsewhere but is there nonetheless. The clock_delay workaround has fixed this in pd-l2ork permanently and I am yet to experience gui freeze that has been plaguing our setup way too often before the said workaround. ___ 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
[PD] Versioning for patches?
Hi is there some git project or similar for versioning of patches? ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] Versioning for patches?
On Sun, 7 Aug 2011, Ludwig Maes wrote: Hi is there some git project or similar for versioning of patches? What do you want to have, in more detail ? ___ | 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] netsend/netreceive + GUI bug
On Sun, 7 Aug 2011, Miller Puckette wrote: Here's a guess... if incoming (vanilla) netreceive traffic is swamping Pd, then since Pd prioritizes input from GUI above output back to GUI, the output never gets scheduled. If that were happening, you'd see the windows freeze but still be able to send Pd events from the GUI (hitting buttons in the patch, for instance.) That sounds like the same symptom as when there is an extra unquoted open-brace. ___ | 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] 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 ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] netsend/netreceive + GUI bug
On Aug 7, 2011, at 5:19 PM, Mathieu Bouchard wrote: On Sun, 7 Aug 2011, Miller Puckette wrote: Here's a guess... if incoming (vanilla) netreceive traffic is swamping Pd, then since Pd prioritizes input from GUI above output back to GUI, the output never gets scheduled. If that were happening, you'd see the windows freeze but still be able to send Pd events from the GUI (hitting buttons in the patch, for instance.) That sounds like the same symptom as when there is an extra unquoted open-brace. What would it take to convince you to port your DD escaping code to Pd 0.43? :-D :-D :-D .hc Looking at things from a more basic level, you can come up with a more direct solution... It may sound small in theory, but it in practice, it can change entire economies. - Amy Smith ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] Desktop Screen Capture
Here's two methods that came up when I asked about this: http://lists.puredata.info/pipermail/pd-list/2010-08/082168.html http://lists.puredata.info/pipermail/pd-list/2010-08/082173.html I vaguely remember that there might be a way to do this just with gridflow as well? I went with webcam studio and it worked great, but I think that might be Linux only. -John On 08/06/2011 09:21 PM, Andreas Eberharter wrote: Hi all, I would like to create a patch, which allows the capture of the desktop screen and at the same time the iSight camera. If you are familiar with Silverpack http://silverbackapp.com/ it is basically, what I would like to achieve with pd/gem. I am just starting, so if this question was asked already once, please point me to the right direction (I used the search on the archives, but could not find what I was searching for) I am on a MacBook Pro running OS X 10.7. I have played with the examples and capturing video from the iSight camera works really nice, what I can't find though, is a screen capture option. Is this possible? Thank you for your help, Greetings, Andreas ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list -- John Harrison http://alumni.media.mit.edu/~harrison ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] Desktop Screen Capture
On Sun, 7 Aug 2011, John Harrison wrote: I vaguely remember that there might be a way to do this just with gridflow as well? GridFlow has had this feature since 2002 or 2003... I used it for making self-screenshot art this year : http://gridflow.ca/gallery/patch_dans_patch_8.png http://gridflow.ca/gallery/patch_dans_patch_9.png http://gridflow.ca/gallery/patch_dans_patch_m.png http://gridflow.ca/gallery/patch_dans_patch_35.png (and more... go see the full series of 42 similarly-named images in the same folder) The use of [gf/canvas_xid] is only if you need to want to make screenshots of your own patch. It's also used for making screenshots of all help patches automatically : http://gridflow.ca/help/ But if you want to make fullscreen shots, or screenshots of the topleft corner of the screen, you don't need that, just : [#in x11 here root] This requires x11, which is available on OSX as «Apple X11», but I don't recall trying the screenshot feature on OSX. The screenshot feature is not part of the [#in quartz] module. ___ | 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
