Re: [PD] Kitect in Pd ?
We already got one in our lab, I guess tomorrow we will port it in Mac, then maybe I can contact you (skype?) later for Kinect external. I will give a try before I call you. I guess this would be the best way to connect Kitect and Pd instead of any other OSC connections. Koray On Nov 28, 2010, at 5:33 AM, Hans-Christoph Steiner wrote: I have libusb/libhid code for Pd, in externals/hcs/usbhid. It shouldn't be too hard to make a Kinect external for Pd. .hc On Nov 27, 2010, at 6:12 AM, Koray Tahiroglu wrote: Hi all, Does anybody have any chance to get those nice sensory inputs in Pd? Seems like its USB connection has been hacked and I was wondering if anybody already used that with Pd. Any ideas/comments on its possible Pd connection? Best, Koray - M.Koray Tahiroğlu Media Lab, Aalto University, School of Art and Design http://mlab.taik.fi/~korayt ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list 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 - M.Koray Tahiroğlu Media Lab, Aalto University, School of Art and Design http://mlab.taik.fi/~korayt tel: +358 45 233 6272 ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] call for testers for L2Ork iteration of pd-extended (based on 0.42.x branch)
This is that kind of thinking that led me to invent [#many]. I looked at their matrix of toggle-like things and told myself I should make something similar, except it would have a much shorter list of properties, and a possibility to connect plugins (using an extra inlet and outlet) so that any special behaviour can be user-specified. And then I wanted a variable element-class, not just toggle. And thus it was born. Apart from that, many things can be made using [#see]-[#mouse] with various graphics processing in GF/GEM/PDP. [#see] displays a video in a patch, and the video can be tiny, generated, and rendered on demand (it's actually a picture viewer). This is most useful for high-color, pixel-oriented data, or really complicated vector data, perhaps. that's also true, but in this case I was speaking more about small user issues. Pd people (me as well) got used to the clean look of the patches, but sometimes this lack of options also means to waste lots of time when a decent gui has to be made. Clean guis should be the result of the programmer's choices, not of the limitations of the program. I had a small look at [#many]. Do you think it would be better to use C-coded objects instead for this kind of complex gop abstractions? I use lots of abstractions with gop (from my library, specially [m-i] for midi input), and it seems to me that at some point I have so many abstractions, that my patches take longer to load. But I didn't do a real test to prove this. ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] L2Ork pd-extended release candidate 1 now available (was: Re: call for testers...)
On Sun, Nov 28, 2010 at 7:47 AM, Jonathan Wilkes jancs...@yahoo.com wrote: Small detail-- your 'Put' menu is tearoff-able. ...which is super cool, IMHO Andras ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] L2Ork pd-extended release candidate 1 now available (was: Re: call for testers...)
On Nov 28, 2010, at 11:11 AM, András Murányi wrote: On Sun, Nov 28, 2010 at 7:47 AM, Jonathan Wilkes jancs...@yahoo.com wrote: Small detail-- your 'Put' menu is tearoff-able. ...which is super cool, IMHO Andras Its one of those things that people love and hate. That's where GUI plugins come in: people who love them can enable them with a simple GUI plugin. .hc Programs should be written for people to read, and only incidentally for machines to execute. - from Structure and Interpretation of Computer Programs ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] The Game of Life
On Sun, Nov 28, 2010 at 7:51 PM, Andrew Faraday jbtur...@hotmail.comwrote: Hey All Bit of an early Christmas present. It's a pure-data based, 16x16 version of Jon Conways Game of Life ( http://en.wikipedia.org/wiki/Conway%27s_Game_of_Life). Perhaps the geekiest thing I've ever done. It's all zipped up because I've used a few abstractions, just uncompress to a single folder and open OpenMe.pd Would love to hear what you guys think of this. Particularly interested in: * Does anyone know if it's been done in puredata before? Can I get hold of it? * Is it well documented enough? * Does it work on different operating systems (was made on ubuntu (netbook remix) so some of it may not transfer)? * How might you improve on this? I may, in the longer run, be planning to use this for a generative music patch. Don't know if that means anything to you. Cheers Andrew I wouldn't mention if it was a real Christmas present :o) but it throws some r13 ... couldn't create errors and hooks my CPU (2,2GHz Opteron) heavily without clicking start. When clicking start nothing happens, perhaps because of the subpatches that didn't create. (Pd-ex autobuild of 2010-11-23) Repair it, Daddy! :o) Andras ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] big soundfiles
On Sat, 27 Nov 2010, Derek Holzer wrote: Thank you Roman, this is exactly the kind of concise and clear information I was looking for to include in the chapters on sample playback in the Pd FLOSS Manual! But that is relevant to [tabread~] and [tabread], NOT [tabread4~], which is normally used with more resolution : in the latter case, you divide the 6 minutes into the number of steps you expect to need between samples. If you play at speed 1.125, that's 9/8, so, you need 1/8 steps, so, divide 6m20s by 8. With different denominators (1.1 = 11/10) it can get complicated though. ___ | Mathieu Bouchard - Aix-en-Provence ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] The Game of Life
It was done under GEM and GridFlow ;) : GEM - examples - 10.GLSL - 04.game_of_life GridFlow examples - game_of_life.pd Should work on Linux, MacOSX and Windows, take a look ! ++ Jack Le dimanche 28 novembre 2010 à 18:51 +, Andrew Faraday a écrit : Hey All Bit of an early Christmas present. It's a pure-data based, 16x16 version of Jon Conways Game of Life (http://en.wikipedia.org/wiki/Conway%27s_Game_of_Life). Perhaps the geekiest thing I've ever done. It's all zipped up because I've used a few abstractions, just uncompress to a single folder and open OpenMe.pd Would love to hear what you guys think of this. Particularly interested in: * Does anyone know if it's been done in puredata before? Can I get hold of it? * Is it well documented enough? * Does it work on different operating systems (was made on ubuntu (netbook remix) so some of it may not transfer)? * How might you improve on this? I may, in the longer run, be planning to use this for a generative music patch. Don't know if that means anything to you. Cheers Andrew ___ 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] The Game of Life
also, I can't get this to work on my mac, not entirely sure why, oh well. never mind. Subject: Re: [PD] The Game of Life From: j...@rybn.org To: jbtur...@hotmail.com CC: pd-list@iem.at Date: Sun, 28 Nov 2010 21:05:03 +0100 It was done under GEM and GridFlow ;) : GEM - examples - 10.GLSL - 04.game_of_life GridFlow examples - game_of_life.pd Should work on Linux, MacOSX and Windows, take a look ! ++ Jack Le dimanche 28 novembre 2010 à 18:51 +, Andrew Faraday a écrit : Hey All Bit of an early Christmas present. It's a pure-data based, 16x16 version of Jon Conways Game of Life (http://en.wikipedia.org/wiki/Conway%27s_Game_of_Life). Perhaps the geekiest thing I've ever done. It's all zipped up because I've used a few abstractions, just uncompress to a single folder and open OpenMe.pd Would love to hear what you guys think of this. Particularly interested in: * Does anyone know if it's been done in puredata before? Can I get hold of it? * Is it well documented enough? * Does it work on different operating systems (was made on ubuntu (netbook remix) so some of it may not transfer)? * How might you improve on this? I may, in the longer run, be planning to use this for a generative music patch. Don't know if that means anything to you. Cheers Andrew ___ 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] The Game of Life
On 11/28/2010 09:21 PM, Andrew Faraday wrote: also, I can't get this to work on my mac, not entirely sure why, oh well. never mind. works here on macos in pd extended 0.42.5. the cpu load is a bit heavy though, on my 2009 mac mini. (about 70 percent) i also got a few r13 couldn't create. on my ubuntu (10.4) it did not work very well, but that is probably because i use basicly pd vanilla and a few externals (and no gridflow for example). after randomize the next iteration is completely black. cpu is about 50 percent (3 ghz intel core duo) Does anyone know if it's been done in puredata before? Can I get hold of it? I may, in the longer run, be planning to use this for a generative music patch. Don't know if that means anything to you. in my sequenzquadrat-patch is a live-player, which modifies the current pattern according to game-of-life rules. musically it is not that interessting though. maybe it would be a better idea to use the game-of-life in a different way than i did, for example as a monophonic sequence, with nr of dots per column as velocity or something like that. or maybe clusters of dots as different sequences... bis denn! martin ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] The Game of Life
On 2010-11-28 13:51, Andrew Faraday wrote: Hey All Bit of an early Christmas present. It's a pure-data based, 16x16 version of Jon Conways Game of Life (http://en.wikipedia.org/wiki/Conway%27s_Game_of_Life). Perhaps the geekiest thing I've ever done. Would love to hear what you guys think of this. Particularly interested in: * Does anyone know if it's been done in puredata before? Can I get hold of it? There's mrpeach/life2x that contains the engine with no display. Martin ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
[PD] pd pcap crash on Mac OS X
I'm trying to use the new pcap library on Mac OS X, and opening three of the four help patches (pdpcap-help.pd, pcap-help.pd, pcap_device- help.pd) all cause this crash: Thread 0 Crashed: 0 libSystem.B.dylib 0x956160be __sfvwrite + 393 1 libSystem.B.dylib 0x95615c3e __vfprintf + 18730 2 libSystem.B.dylib 0x956499b5 vsnprintf + 505 3 pd 0x0006190d sys_vgui + 113 (s_inter.c:668) 4 pd 0x00064a32 dopost + 320 (s_print.c: 42) 5 pd 0x00064ac9 post + 78 (s_print.c:55) .hc I have the audacity to believe that peoples everywhere can have three meals a day for their bodies, education and culture for their minds, and dignity, equality and freedom for their spirits. - Martin Luther King, Jr. ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] The Game of Life
As-salamu alaykum, On Sun, Nov 28, 2010 at 06:51:57PM +, Andrew Faraday wrote: * Does anyone know if it's been done in puredata before? Can I get hold of it? http//lists.puredata.info/pipermail/pd-list/2006-08/041323.html Unfortunately the links in that post don't resolve correctly, but you can get the same files from here: http://mccormick.cx/dev/s-abstractions/ Using that you can build CA fields of arbitrary size. There is a small bug where cells shift one unit when crossing some boundaries - I think the top and bottom of the field but I can't remember - but it doesn't have too disruptive an effect and the whole structure still functions ok. I may, in the longer run, be planning to use this for a generative music patch. Don't know if that means anything to you. I made some music with my implementation which you can hear here: http://sciencegirlrecords.com/chr15m/music/CD004/ca1.ogg If I recall correctly, notes/parameters/rhythms were triggered as cells in certain rows were crossed. I made liberal use of the Glider: http://en.wikipedia.org/wiki/Glider_%28Conway%27s_Life%29. Also check out the replies in that thread: Frank's Game of Life in datastructures: http://lists.puredata.info/pipermail/pd-list/2006-08/041386.html Mathieu's implementation in gridflow: http://lists.puredata.info/pipermail/pd-list/2006-08/041382.html Enjoy, Chris. --- http://mccormick.cx ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
[PD] Parsing Pd patches in Javascript, Python, Java
Hi,
Here is how you can parse Pd patches into rows of atoms in three languages
using regular expressions:
/*** Javascript ***/
var lines_re = new
RegExp((#((.|\r|\n)*?)[^])\r{0,1}\n{0,1};\r{0,1}\n, gi);
for (pdline = lines_re.exec(patchtext)) {
var atoms = pdline[1].split(/ |\r\n?|\n/);
}
### Python ###
lines_re = re.compile((#(.*?)[^\\\])\r{0,1}\n{0,1};\r{0,1}\n,
re.MULTILINE | re.DOTALL)
split_re = re.compile( |\r\n?|\n, re.MULTILINE)
for found in lines_re.finditer(patch):
line = found.group(1)
atoms = split_re.split(line)
/*** Java ***/
private static final String line_re =
(#((.|\r|\n)*?)[^])\r{0,1}\n{0,1};\r{0,1}\n;
private static final String token_re = |\r\n?|\n;
Pattern pattern = Pattern.compile(line_re, Pattern.MULTILINE);
Pattern token_pattern = Pattern.compile(token_re, Pattern.MULTILINE);
Matcher matcher = pattern.matcher(patchtext);
ArrayListString[] atomlines = new ArrayListString[]();
while (matcher.find()) {
String[] s = token_pattern.split(matcher.group(1));
atomlines.add(token_pattern.split(matcher.group(1)));
}
Also here is a regular expression for matching dollar args:
/(?:\\{0,1}\$)(\d+)/g;
Hopefully this is useful to someone else.
Cheers,
Chris.
---
http://mccormick.cx
___
Pd-list@iem.at mailing list
UNSUBSCRIBE and account-management -
http://lists.puredata.info/listinfo/pd-list
Re: [PD] L2Ork pd-extended release candidate 1 now available (was: Re: call for testers...)
On Sat, 2010-11-27 at 22:47 -0800, Jonathan Wilkes wrote: Small detail-- your 'Put' menu is tearoff-able. This is intentional. Best wishes, Ico ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] L2Ork pd-extended release candidate 1 now available (was: Re: call for testers...)
On Sat, 2010-11-27 at 23:18 -0800, Jonathan Wilkes wrote: Hi, Here are some scrolling observations: In the attached patch, drag the [pd] object far down into the bottom right-hand corner, so that you get some scrollbars to appear. Now, on the current pd-extended, you can scroll down to that object, and when you drag it back to its original location, the scrollbars respond in realtime so that the object swoops back up the patch until, finally, the scrollbars disappear. In your version the scrollbars don't react until you stop dragging and release the mouse button. Just an observation-- I suppose both methods have their strengths and weaknesses. I prefer the current Pd-ext behavior-- for example, if I happen to paste an object into another patch with a smaller window size, it makes it quick to drag it back up. But notice that once you drag the [pd] object back near its original position, the [f] object looks as if it's at (0,0), when it's really at (10,10). However, if you save the patch and reopen it the [f] will appear at its proper, original position-- (10,10). I think this is a bug, because it means any time one adds or takes away the scrollbars the absolute positioning of the objects on the canvas is temporarily lost, forcing the user to close and open to see the real positioning. -Jonathan Both of these are actually a feature. I actually used to have real-time scrollbar updates but that simply bogged the cpu down too much, so I opted to updating them only once an object has stopped moving which in most if not all cases makes perfect sense. The reason canvas is displaced in l2ork version is because our philosophy is if a patch can fit in a window, it should. Granted, it has some shortcomings like patches opening and then having to readjust as well as having them not (0,0)-centric which makes them potentially less compatible with vanilla version. That said, I believe this is a much better way of dealing with patches, and if one really wants to lock-in patch positioning, they should simply use a cnv (canvas) object whose name in many ways suggests exactly that. NB: repositioning of window upon load can be avoided only if the format of saving the patch also includes the top-left corner of the canvas, which current format does not support. Please note that l2ork's scrolling algorithm also accounts for all other operations, such as undo/redo/cut/copy/paste, even key presses that may extend the width of an object. Cheers! Ico ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] L2Ork pd-extended release candidate 1 now available (was: Re: call for testers...)
OK, release candidate 2 is now up with following changes: *This one was *really* bad: Cut/Paste/Undo/Redo creates double entries on gop-in-gop patches. Basically, after literally a day of troubleshooting and posting hooks all over the pd source (heck, I even got to study binbuf stuff :-) it appears in these instances window_name never changes upon restore (in other words tcl/tk canvas's documentation lies about not reusing id with every new object--why am I not surprised?) NB: this finally solves every instance I am familiar with in which pd suddenly starts spewing two or more objects per each key-press/action. Consequently, even though I've said it many times before, I finally believe this solves all of the GOP redraw/bug issues. To best test this problem you can simply create a simple patch using either vanilla pd or pd-extended with a GOP abstraction that has another visible GOP abstraction inside it. Now on the parent window cut and undo (or paste) the GOP-ed abstraction and open it. Try creating a new object inside it and presto, everything is doubled. As you do more cut/undos you can get as many of them per action as you like :-). This can also result in a crash as window close will be also registered multiple times. If you are wondering how the fix works, it's the ugliest hack on the planet made for the comparably attractive toolkit: every time the undo/copy queue is copied I insert a bogus object prior to the selection (in this case a comment with an appropriately redundant name) and offset all connections by one. Once the buffer is restored, the fact it is different from the original scene (seems to me that the tcl/tk might be caching things id-wise without properly disconnecting HID hooks to those widgets, hence multiple entries per action) forces tcl/tk to assign truly unique ids to newly pasted objects. Upon restoring the queue, I erase the bogus object. Now, how ugly is that? So, the next time you have an opportunity to read tcl/tk documentation don't forget to take it with a boulder of salt. Other fixes: *recreation of gop-ed objects when selecting their text (a.k.a. activating them) must not apply to gop-ed pd patchers (when clicked to change their names) *changing name on a gop-ed pd patcher automatically resizes patcher gop window and correctly positions outlets *Added ctrl+enter reselect option *cleaned up stderr errors about canvases/widgets not found *when closing dirty patch and dirty abstraction, prompts are incorrectly focusing on and pointing to wrong windows *cord inspector uses globally defined font size *removed xy stretch option from the font menu as it appears to be unstable *corrected text color on pd patcher Latest snapshot is available at: http://l2ork.music.vt.edu/main/?page_id=56 As always, feedback is most appreciated. Cheers! Ico ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
