Re: [PD] Pdpedia and random generation
Hallo! afaik, pdpedia is poorly maintained at the moment. I think there will be a better solution in the future to get rid of spam and optimize searching and contributions. for now, your observation of burnout seems correct. marius. I think pdpedia has a lot of potential, but it needs someone to take ownership of it. Its really open to anyone who wants to take it on. It is useful now for searching based on keywords. I use it to find objects based on key words. Silly question: but why don't you just use captchas did get rid of all these massive spam attacks ? (However, I don't know if this is difficult to install on this system - otherwise maybe have to use user accounts ...) LG Georg ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Re: [PD] pd book sprint
Hallo, Alexandre Porres hat gesagt: // Alexandre Porres wrote: > you know, yeah, but the thing is that phasor is not actually an oscilator at > all !!! > the name actually refers to phase, and not sawtooth. And a [triangle~] may be used as a ping-pong looping [phasor~]. The objects Pd provides are building blocks - they generally are designed on a level that allows and encourages multiple uses. A square wave going from 0 to 1 can be used as a logical signal that switches another signal on and off. In fact, a trivial square or saw without bandlimit should generally not be used as an "oscillator" in the analog synth sense - it should be bandlimited first, and while you do that you may as well make them have a DC of 0. (Bandlimiting triangle waves is not *that* urgent, as corners don't add so many alias components.) Ciao -- Frank ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Re: [PD] Pdpedia and random generation
2009/3/31 Georg Holzmann : > Hallo! > >>> afaik, pdpedia is poorly maintained at the moment. I think there will be >>> a better solution in the future to get rid of spam and optimize searching >>> and contributions. for now, your observation of burnout seems correct. >>> marius. >> >> I think pdpedia has a lot of potential, but it needs someone to take >> ownership of it. Its really open to anyone who wants to take it on. It is >> useful now for searching based on keywords. I use it to find objects based >> on key words. I quite agree, and I have written for some articles to make them more useful (FIR~, multiplex~, and tabwrite) but I feel lonely doing so. I'm the only user to have made any changes to pdpedia content in the last 30 days; there has been some spamfighting by Hans and lots of spam from anonymous IPs but if noone else is updating the actual content I don't see why I am doing it. > Silly question: but why don't you just use captchas did get rid of all these > massive spam attacks ? > (However, I don't know if this is difficult to install on this system - > otherwise maybe have to use user accounts ...) http://www.mediawiki.org/wiki/Extension:SpamBlacklist is something that could be considered. It prevents any edit to a page which inserts a URL matching a list of regexes. Philip -- "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 ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
[PD] Smooth motion with GEM
Hi list, I'm using the patch below on Pd-extended 0.40.3 on a MacBook Pro, MacOsX10.4.11, to test the best setting for the [gemwin] initialization. Even with a simple 4/3 [rectangle] I can't get smooth motions: if I increase/decrease its dimensions with a [line] (let's say increasing dimensions from 3 to 4 in 1 milliseconds) the motion is not fluid, it changes by little visible steps. I've tried also to limit the amount of data from the [line] till 40 values per second without significative results. Any suggestion? Thanks a lot! marco #N canvas 595 22 579 178 10; #X obj 78 38 gemhead; #X obj 64 123 rectangle 4 3; #X obj 357 115 gemwin; #X msg 258 47 create \, 1; #X msg 349 48 destroy; #X floatatom 157 28 5 0 0 0 - - -; #X obj 139 98 * 0.865; #X obj 139 75 line; #X obj 139 54 pack f f; #X floatatom 206 29 5 0 0 0 - - -; #X msg 414 69 frame \$1; #X floatatom 414 48 5 0 0 0 - - -; #X msg 8 61 draw fill; #X obj 78 17 tgl 15 0 empty empty empty 17 7 0 10 -262144 -1 -1 1 1 ; #X connect 0 0 1 0; #X connect 3 0 2 0; #X connect 4 0 2 0; #X connect 5 0 8 0; #X connect 6 0 1 2; #X connect 7 0 6 0; #X connect 7 0 1 1; #X connect 8 0 7 0; #X connect 9 0 8 1; #X connect 10 0 2 0; #X connect 11 0 10 0; #X connect 12 0 1 0; #X connect 13 0 0 0; ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Re: [PD] Smooth motion with GEM
sending the gemwin a message FSAA 2 (or 4...) before you create it will enhance the smoothness a little bit. marius. 2009/3/31 maths...@libero.it : > > Hi list, > > I'm using the patch below on Pd-extended 0.40.3 on a MacBook Pro, > MacOsX10.4.11, to test the best setting for the [gemwin] initialization. > > Even with a simple 4/3 [rectangle] I can't get smooth motions: if I > increase/decrease its dimensions with a [line] (let's say increasing > dimensions from 3 to 4 in 1 milliseconds) the motion is not fluid, it > changes by little visible steps. I've tried also to limit the amount of data > from the [line] till 40 values per second without significative results. > > Any suggestion? Thanks a lot! marco > > > #N canvas 595 22 579 178 10; > #X obj 78 38 gemhead; > #X obj 64 123 rectangle 4 3; > #X obj 357 115 gemwin; > #X msg 258 47 create \, 1; > #X msg 349 48 destroy; > #X floatatom 157 28 5 0 0 0 - - -; > #X obj 139 98 * 0.865; > #X obj 139 75 line; > #X obj 139 54 pack f f; > #X floatatom 206 29 5 0 0 0 - - -; > #X msg 414 69 frame \$1; > #X floatatom 414 48 5 0 0 0 - - -; > #X msg 8 61 draw fill; > #X obj 78 17 tgl 15 0 empty empty empty 17 7 0 10 -262144 -1 -1 1 1 > ; > #X connect 0 0 1 0; > #X connect 3 0 2 0; > #X connect 4 0 2 0; > #X connect 5 0 8 0; > #X connect 6 0 1 2; > #X connect 7 0 6 0; > #X connect 7 0 1 1; > #X connect 8 0 7 0; > #X connect 9 0 8 1; > #X connect 10 0 2 0; > #X connect 11 0 10 0; > #X connect 12 0 1 0; > #X connect 13 0 0 0; > > > > ___ > 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] Smooth motion with GEM
setting framerate to 50 with the frame massage on your patch make the display very fluid. 50fps correspond to 20ms between frame, and that's exactly the default output rate of line. so everything is fine in your patch. once correctly configured it works perfectly. at least on my computer. Cyrille maths...@libero.it a écrit : Hi list, I'm using the patch below on Pd-extended 0.40.3 on a MacBook Pro, MacOsX10.4.11, to test the best setting for the [gemwin] initialization. Even with a simple 4/3 [rectangle] I can't get smooth motions: if I increase/decrease its dimensions with a [line] (let's say increasing dimensions from 3 to 4 in 1 milliseconds) the motion is not fluid, it changes by little visible steps. I've tried also to limit the amount of data from the [line] till 40 values per second without significative results. Any suggestion? Thanks a lot! marco #N canvas 595 22 579 178 10; #X obj 78 38 gemhead; #X obj 64 123 rectangle 4 3; #X obj 357 115 gemwin; #X msg 258 47 create \, 1; #X msg 349 48 destroy; #X floatatom 157 28 5 0 0 0 - - -; #X obj 139 98 * 0.865; #X obj 139 75 line; #X obj 139 54 pack f f; #X floatatom 206 29 5 0 0 0 - - -; #X msg 414 69 frame \$1; #X floatatom 414 48 5 0 0 0 - - -; #X msg 8 61 draw fill; #X obj 78 17 tgl 15 0 empty empty empty 17 7 0 10 -262144 -1 -1 1 1 ; #X connect 0 0 1 0; #X connect 3 0 2 0; #X connect 4 0 2 0; #X connect 5 0 8 0; #X connect 6 0 1 2; #X connect 7 0 6 0; #X connect 7 0 1 1; #X connect 8 0 7 0; #X connect 9 0 8 1; #X connect 10 0 2 0; #X connect 11 0 10 0; #X connect 12 0 1 0; #X connect 13 0 0 0; ___ 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] Pdpedia and random generation
Hi, welll, so "someone" needs to take over? I would definately be interested on this. I do, nevertheless, feel I bit clueless as I dont know the way to the source of all objects. And cant really be an expert on things other than audio/music. I also consider rather unfair to be the work of only one ho has taken over. I do believe in forming a team, things like that. Anyway, with the convention this year and all, I hope to bring this issue into round tables and discussions, make some noise on the list to see if a small group would move a bit their asses to launch this out. I could kinda take it over this way. I could definately make the commitment. But I cant be the one and only. I am not even a Native Speaker/Writer of English. So please help me out here, I also need a partner to guide me and help me not getting so bit clueless. Cheers Alex ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Re: [PD] Pdpedia and random generation
the "someone" would be in charge of the server space and the maintainance of the mediawiki (accounts, updates, spam, search functionality, synchronization with other documentations). this could also be done by several people, but usually the responsibility is with one person. all the rest can easily be done by a group of admins or even be totally open to the public. I guess the work that is missing at the moment is not so much about writing all the articles. marius. 2009/3/31 Alexandre Porres : > Hi, welll, so "someone" needs to take over? > I would definately be interested on this. I do, nevertheless, feel I bit > clueless as I dont know the way to the source of all objects. And cant > really be an expert on things other than audio/music. > I also consider rather unfair to be the work of only one ho has taken over. > I do believe in forming a team, things like that. > Anyway, with the convention this year and all, I hope to bring this issue > into round tables and discussions, make some noise on the list to see if a > small group would move a bit their asses to launch this out. > I could kinda take it over this way. I could definately make the commitment. > But I cant be the one and only. I am not even a Native Speaker/Writer of > English. > So please help me out here, I also need a partner to guide me and help me > not getting so bit clueless. > Cheers > Alex > > ___ > 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] recursive video feedback in GEM or PDP?
The other night I watched a very nice lecture from Paul Prudence (dataisnature.com). He uses to make audio-responsive video feedback, where a single shape (a square) is recursively displayed, causing very complex structures to arise. The relevant parts of the lecture are here: http://www.vimeo.com/2930699 http://www.vimeo.com/3003040 although I would encourage people to go through the whole thing (11 parts on Vimeo) if they have time + interest. I'd at a loss to think of how something similar, i.e. the recursive feedback, could be done in GEM or PDP. Any suggestions? best! Derek -- ::: derek holzer ::: http://blog.myspace.com/macumbista ::: http://www.vimeo.com/macumbista ::: ---Oblique Strategy # 8: "Accretion" ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Re: [PD] recursive video feedback in GEM or PDP?
look at gem exemple 07.feedback in 07.texture directory and also at "self similar" performance by Ben bogart (2004) : http://www.ekran.org/ben/wp/?page_id=101 ++ c Derek Holzer a écrit : The other night I watched a very nice lecture from Paul Prudence (dataisnature.com). He uses to make audio-responsive video feedback, where a single shape (a square) is recursively displayed, causing very complex structures to arise. The relevant parts of the lecture are here: http://www.vimeo.com/2930699 http://www.vimeo.com/3003040 although I would encourage people to go through the whole thing (11 parts on Vimeo) if they have time + interest. I'd at a loss to think of how something similar, i.e. the recursive feedback, could be done in GEM or PDP. Any suggestions? best! Derek ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Re: [PD] recursive video feedback in GEM or PDP?
Thanks much! [pix_snap2tex] is exactly the starting point I needed. D. cyrille henry wrote: look at gem exemple 07.feedback in 07.texture directory and also at "self similar" performance by Ben bogart (2004) : http://www.ekran.org/ben/wp/?page_id=101 ++ c Derek Holzer a écrit : The other night I watched a very nice lecture from Paul Prudence (dataisnature.com). He uses to make audio-responsive video feedback, where a single shape (a square) is recursively displayed, causing very complex structures to arise. The relevant parts of the lecture are here: http://www.vimeo.com/2930699 http://www.vimeo.com/3003040 although I would encourage people to go through the whole thing (11 parts on Vimeo) if they have time + interest. I'd at a loss to think of how something similar, i.e. the recursive feedback, could be done in GEM or PDP. Any suggestions? best! Derek -- ::: derek holzer ::: http://blog.myspace.com/macumbista ::: http://www.vimeo.com/macumbista ::: ---Oblique Strategy # 145: "Slow preparation, fast execution" ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Re: [PD] recursive video feedback in GEM or PDP?
this was the old way to do (but still working fine). i think it can be faster to render in a framebuffer, and use this framebuffer as a texture to draw in a 2nd framebuffer. and drawing back to the 1st. etc. there are also some example in the glsl section. jack also send a simple exemple somwhere recently. ++ c Derek Holzer a écrit : Thanks much! [pix_snap2tex] is exactly the starting point I needed. D. cyrille henry wrote: look at gem exemple 07.feedback in 07.texture directory and also at "self similar" performance by Ben bogart (2004) : http://www.ekran.org/ben/wp/?page_id=101 ++ c Derek Holzer a écrit : The other night I watched a very nice lecture from Paul Prudence (dataisnature.com). He uses to make audio-responsive video feedback, where a single shape (a square) is recursively displayed, causing very complex structures to arise. The relevant parts of the lecture are here: http://www.vimeo.com/2930699 http://www.vimeo.com/3003040 although I would encourage people to go through the whole thing (11 parts on Vimeo) if they have time + interest. I'd at a loss to think of how something similar, i.e. the recursive feedback, could be done in GEM or PDP. Any suggestions? best! Derek ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Re: [PD] Pdpedia and random generation
the server space & the maintenance is currently done by claudio the sys-admin at the school here in zürich where the wiki is hostet atm. so far he's been trying to maintain it as much as possible - sometimes certain request take more time - queuing up on other things that need to be done. but so far ev'rything should be on the line. recently php-admin was installed for user management & should be up & functional. the spam issue we've discussed on the list & i got the consensus to clean up the mess by hand. So if there's any lack regarding the hosting or enhancements please let me know & i'll forward it. olsen On Tue, Mar 31, 2009 at 2:46 PM, marius schebella wrote: > the "someone" would be in charge of the server space and the > maintainance of the mediawiki (accounts, updates, spam, search > functionality, synchronization with other documentations). this could > also be done by several people, but usually the responsibility is with > one person. all the rest can easily be done by a group of admins or > even be totally open to the public. > > I guess the work that is missing at the moment is not so much about > writing all the articles. > marius. > > 2009/3/31 Alexandre Porres : >> Hi, welll, so "someone" needs to take over? >> I would definately be interested on this. I do, nevertheless, feel I bit >> clueless as I dont know the way to the source of all objects. And cant >> really be an expert on things other than audio/music. >> I also consider rather unfair to be the work of only one ho has taken over. >> I do believe in forming a team, things like that. >> Anyway, with the convention this year and all, I hope to bring this issue >> into round tables and discussions, make some noise on the list to see if a >> small group would move a bit their asses to launch this out. >> I could kinda take it over this way. I could definately make the commitment. >> But I cant be the one and only. I am not even a Native Speaker/Writer of >> English. >> So please help me out here, I also need a partner to guide me and help me >> not getting so bit clueless. >> Cheers >> Alex >> >> ___ >> 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 > -- Planet Pluto bleibt! ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Re: [PD] recursive video feedback in GEM or PDP?
which objects could be used to make this framebuffer? d. cyrille henry wrote: this was the old way to do (but still working fine). i think it can be faster to render in a framebuffer, and use this framebuffer as a texture to draw in a 2nd framebuffer. and drawing back to the 1st. etc. there are also some example in the glsl section. jack also send a simple exemple somwhere recently. ++ c Derek Holzer a écrit : Thanks much! [pix_snap2tex] is exactly the starting point I needed. D. cyrille henry wrote: look at gem exemple 07.feedback in 07.texture directory and also at "self similar" performance by Ben bogart (2004) : http://www.ekran.org/ben/wp/?page_id=101 ++ c Derek Holzer a écrit : The other night I watched a very nice lecture from Paul Prudence (dataisnature.com). He uses to make audio-responsive video feedback, where a single shape (a square) is recursively displayed, causing very complex structures to arise. The relevant parts of the lecture are here: http://www.vimeo.com/2930699 http://www.vimeo.com/3003040 although I would encourage people to go through the whole thing (11 parts on Vimeo) if they have time + interest. I'd at a loss to think of how something similar, i.e. the recursive feedback, could be done in GEM or PDP. Any suggestions? best! Derek -- ::: derek holzer ::: http://blog.myspace.com/macumbista ::: http://www.vimeo.com/macumbista ::: ---Oblique Strategy # 69: "Feed the recording back out of the medium" ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Re: [PD] recursive video feedback in GEM or PDP?
Second question: would I gain anything by bridging between GEM and PDP for something like this? Or would the [gem2pdp] and [pdp2gem] use more resources than I would gain from using PDP in this situation? D. Derek Holzer wrote: which objects could be used to make this framebuffer? d. cyrille henry wrote: this was the old way to do (but still working fine). i think it can be faster to render in a framebuffer, and use this framebuffer as a texture to draw in a 2nd framebuffer. and drawing back to the 1st. etc. there are also some example in the glsl section. jack also send a simple exemple somwhere recently. ++ c Derek Holzer a écrit : Thanks much! [pix_snap2tex] is exactly the starting point I needed. D. cyrille henry wrote: look at gem exemple 07.feedback in 07.texture directory and also at "self similar" performance by Ben bogart (2004) : http://www.ekran.org/ben/wp/?page_id=101 ++ c Derek Holzer a écrit : The other night I watched a very nice lecture from Paul Prudence (dataisnature.com). He uses to make audio-responsive video feedback, where a single shape (a square) is recursively displayed, causing very complex structures to arise. The relevant parts of the lecture are here: http://www.vimeo.com/2930699 http://www.vimeo.com/3003040 although I would encourage people to go through the whole thing (11 parts on Vimeo) if they have time + interest. I'd at a loss to think of how something similar, i.e. the recursive feedback, could be done in GEM or PDP. Any suggestions? best! Derek -- ::: derek holzer ::: http://blog.myspace.com/macumbista ::: http://www.vimeo.com/macumbista ::: ---Oblique Strategy # 53: "Do something boring" ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Re: [PD] recursive video feedback in GEM or PDP?
Derek Holzer a écrit : which objects could be used to make this framebuffer? gemframebuffer. here is the patch jack send recently on the list. cyrille d. cyrille henry wrote: this was the old way to do (but still working fine). i think it can be faster to render in a framebuffer, and use this framebuffer as a texture to draw in a 2nd framebuffer. and drawing back to the 1st. etc. there are also some example in the glsl section. jack also send a simple exemple somwhere recently. ++ c Derek Holzer a écrit : Thanks much! [pix_snap2tex] is exactly the starting point I needed. D. cyrille henry wrote: look at gem exemple 07.feedback in 07.texture directory and also at "self similar" performance by Ben bogart (2004) : http://www.ekran.org/ben/wp/?page_id=101 ++ c Derek Holzer a écrit : The other night I watched a very nice lecture from Paul Prudence (dataisnature.com). He uses to make audio-responsive video feedback, where a single shape (a square) is recursively displayed, causing very complex structures to arise. The relevant parts of the lecture are here: http://www.vimeo.com/2930699 http://www.vimeo.com/3003040 although I would encourage people to go through the whole thing (11 parts on Vimeo) if they have time + interest. I'd at a loss to think of how something similar, i.e. the recursive feedback, could be done in GEM or PDP. Any suggestions? best! Derek #N canvas 493 62 756 595 10; #X obj 139 250 translateXYZ 0 0 -4; #X obj 139 279 pix_texture; #X obj 273 279 pix_texture; #X obj 273 307 color 1 1 1; #X obj 19 75 gemwin; #X msg 30 49 0 \, destroy; #X obj 9 250 translateXYZ 0 0 -4; #X obj 9 279 color 1 0 0; #X obj 273 338 rectangle 4 4; #X obj 139 307 rectangle 4 4; #X obj 9 117 gemhead 5; #X obj 421 304 pix_texture; #X obj 421 337 rectangle 4 4; #X obj 30 149 bng 15 250 50 0 empty empty empty 17 7 0 10 -262144 -1 -1; #X obj 9 306 circle 1; #X obj 9 215 gemframebuffer; #X obj 139 215 gemframebuffer; #X obj 273 215 gemframebuffer; #X msg 179 124 quality 1; #X msg 19 27 create \, 1; #X obj 308 54 loadbang; #X text 50 147 <- push !; #X msg 308 77 dimen 512 512; #X obj 273 250 translateXYZ 0 0 -4.2; #X floatatom 396 186 5 0 0 0 - - -; #X text 510 335 <- get the result in a rectangle; #X obj 179 13 gemhead; #X msg 179 35 1; #X obj 179 59 change; #X msg 179 82 1000; #X obj 179 103 delay; #X obj 396 219 - 4; #X text 439 185 <- change the value with shift key; #X obj 139 151 gemhead 6; #X obj 273 151 gemhead 7; #X obj 421 265 gemhead 8; #N canvas 0 0 450 300 once 0; #X obj 37 32 inlet; #X obj 37 107 t a b; #X obj 37 159 outlet; #X obj 37 75 spigot 0; #X msg 69 129 0; #X msg 131 51 1; #X obj 131 27 inlet; #X connect 0 0 3 0; #X connect 1 0 2 0; #X connect 1 1 4 0; #X connect 3 0 1 0; #X connect 4 0 3 1; #X connect 5 0 3 1; #X connect 6 0 5 0; #X restore 9 180 pd once; #X floatatom 400 144 5 0 0 0 - - -; #X connect 0 0 1 0; #X connect 1 0 9 0; #X connect 2 0 3 0; #X connect 2 1 11 1; #X connect 3 0 8 0; #X connect 5 0 4 0; #X connect 6 0 7 0; #X connect 7 0 14 0; #X connect 10 0 36 0; #X connect 11 0 12 0; #X connect 13 0 36 1; #X connect 15 0 6 0; #X connect 15 1 1 1; #X connect 16 0 0 0; #X connect 16 1 2 1; #X connect 17 0 23 0; #X connect 17 1 1 1; #X connect 18 0 1 0; #X connect 18 0 2 0; #X connect 19 0 4 0; #X connect 20 0 22 0; #X connect 22 0 16 0; #X connect 22 0 15 0; #X connect 22 0 17 0; #X connect 23 0 2 0; #X connect 24 0 31 0; #X connect 26 0 27 0; #X connect 27 0 28 0; #X connect 28 0 29 0; #X connect 29 0 30 0; #X connect 30 0 18 0; #X connect 31 0 23 3; #X connect 33 0 16 0; #X connect 34 0 17 0; #X connect 35 0 11 0; #X connect 36 0 15 0; #X connect 37 0 23 1; ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Re: [PD] recursive video feedback in GEM or PDP?
Thanks. I know that it is inherent in the system, but is there a way to control the "fuzziness" of each iteration, so that the image loses its alpha value but retains the sharpness of it's outlines? D. cyrille henry wrote: Derek Holzer a écrit : which objects could be used to make this framebuffer? gemframebuffer. here is the patch jack send recently on the list. cyrille d. cyrille henry wrote: this was the old way to do (but still working fine). i think it can be faster to render in a framebuffer, and use this framebuffer as a texture to draw in a 2nd framebuffer. and drawing back to the 1st. etc. there are also some example in the glsl section. jack also send a simple exemple somwhere recently. ++ c Derek Holzer a écrit : Thanks much! [pix_snap2tex] is exactly the starting point I needed. D. cyrille henry wrote: look at gem exemple 07.feedback in 07.texture directory and also at "self similar" performance by Ben bogart (2004) : http://www.ekran.org/ben/wp/?page_id=101 ++ c Derek Holzer a écrit : The other night I watched a very nice lecture from Paul Prudence (dataisnature.com). He uses to make audio-responsive video feedback, where a single shape (a square) is recursively displayed, causing very complex structures to arise. The relevant parts of the lecture are here: http://www.vimeo.com/2930699 http://www.vimeo.com/3003040 although I would encourage people to go through the whole thing (11 parts on Vimeo) if they have time + interest. I'd at a loss to think of how something similar, i.e. the recursive feedback, could be done in GEM or PDP. Any suggestions? best! Derek -- ::: derek holzer ::: http://blog.myspace.com/macumbista ::: http://www.vimeo.com/macumbista ::: ---Oblique Strategy # 48: "Discover your formulas and abandon them" ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Re: [PD] pd book sprint
On Mar 31, 2009, at 4:34 AM, Frank Barknecht wrote: Hallo, Alexandre Porres hat gesagt: // Alexandre Porres wrote: you know, yeah, but the thing is that phasor is not actually an oscilator at all !!! the name actually refers to phase, and not sawtooth. And a [triangle~] may be used as a ping-pong looping [phasor~]. The objects Pd provides are building blocks - they generally are designed on a level that allows and encourages multiple uses. A square wave going from 0 to 1 can be used as a logical signal that switches another signal on and off. In fact, a trivial square or saw without bandlimit should generally not be used as an "oscillator" in the analog synth sense - it should be bandlimited first, and while you do that you may as well make them have a DC of 0. (Bandlimiting triangle waves is not *that* urgent, as corners don't add so many alias components.) I think the key to this discussion of -1 to 1 vs 0 to 1 is what people are most likely going to use them for, and what makes the most sense in that context. Of course, ideally, it wouldn't create arbitrary restrictions either. For example, Cyrille and I make basically everything 0 to 1 in the mapping library since it makes things really easy to do without sacrificing much flexibility. If you start with, or end up with different ranges, you can do the scaling math at the input or output ends of the patch, and keep everything in between 0 to 1. I think the two ranges for this discussion separate signals versus controls. A sawtooth~ is a signal that is meant to be listened to, so it would good from -1 to 1. A phasor~ is the exact same shape as a sawtooth~, but it is meant to be a control, so it is 0 to 1. You could easily switch the two with some basic math, but most of the time, you'll want your controls to be 0 to 1 and your signals -1 to 1. A similar pair would be square~ (signal) and pwm~ (control). .hc Terrorism is not an enemy. It cannot be defeated. It's a tactic. It's about as sensible to say we declare war on night attacks and expect we're going to win that war. We're not going to win the war on terrorism.- retired U.S. Army general, William Odom ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Re: [PD] recursive video feedback in GEM or PDP?
There is a nice one included in pdmtl called gems.win.feedback .hc On Mar 31, 2009, at 11:51 AM, Derek Holzer wrote: Thanks. I know that it is inherent in the system, but is there a way to control the "fuzziness" of each iteration, so that the image loses its alpha value but retains the sharpness of it's outlines? D. cyrille henry wrote: Derek Holzer a écrit : which objects could be used to make this framebuffer? gemframebuffer. here is the patch jack send recently on the list. cyrille d. cyrille henry wrote: this was the old way to do (but still working fine). i think it can be faster to render in a framebuffer, and use this framebuffer as a texture to draw in a 2nd framebuffer. and drawing back to the 1st. etc. there are also some example in the glsl section. jack also send a simple exemple somwhere recently. ++ c Derek Holzer a écrit : Thanks much! [pix_snap2tex] is exactly the starting point I needed. D. cyrille henry wrote: look at gem exemple 07.feedback in 07.texture directory and also at "self similar" performance by Ben bogart (2004) : http://www.ekran.org/ben/wp/?page_id=101 ++ c Derek Holzer a écrit : The other night I watched a very nice lecture from Paul Prudence (dataisnature.com). He uses to make audio- responsive video feedback, where a single shape (a square) is recursively displayed, causing very complex structures to arise. The relevant parts of the lecture are here: http://www.vimeo.com/2930699 http://www.vimeo.com/3003040 although I would encourage people to go through the whole thing (11 parts on Vimeo) if they have time + interest. I'd at a loss to think of how something similar, i.e. the recursive feedback, could be done in GEM or PDP. Any suggestions? best! Derek -- ::: derek holzer ::: http://blog.myspace.com/macumbista ::: http://www.vimeo.com/macumbista ::: ---Oblique Strategy # 48: "Discover your formulas and abandon them" ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list If nature has made any one thing less susceptible than all others of exclusive property, it is the action of the thinking power called an idea, which an individual may exclusively possess as long as he keeps it to himself; but the moment it is divulged, it forces itself into the possession of everyone, and the receiver cannot dispossess himself of it.- Thomas Jefferson ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Re: [PD] Pdpedia and random generation
2009/3/31 olsen wolf : > the server space & the maintenance is currently done by claudio the > sys-admin at the school here in zürich where the wiki is hostet atm. > so far he's been trying to maintain it as much as possible - sometimes > certain request take more time - queuing up on other things that need > to be done. but so far ev'rything should be on the line. recently > php-admin was installed for user management & should be up & > functional. the spam issue we've discussed on the list & i got the > consensus to clean up the mess by hand. I don't know what you mean by "clean it up by hand" but if you just mean users deleting spam edits then this is not sustainable. The spam edits are automated and so they will win any editwar. To combat spam, we need something systematic: block the spam IPs, use MediaWiki Spam Blacklist, or require users to create an account before they can edit. The first solution could be implemented by creating more wiki admins with the power to block IPs. Obviously said people would need to be active and trusted. The other options require changing the mediawiki settings which can presumably only be done by the site admin. > So if there's any lack regarding the hosting or enhancements please > let me know & i'll forward it. -- "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 ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Re: [PD] Pdpedia and random generation
Hallo! I don't know what you mean by "clean it up by hand" but if you just mean users deleting spam edits then this is not sustainable. The spam edits are automated and so they will win any editwar. To combat spam, +1 we need something systematic: block the spam IPs, use MediaWiki Spam Blacklist, or require users to create an account before they can edit. Yes, or use at least captchas (if we don't want to force people to make an account) ... LG Georg ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Re: [PD] recursive video feedback in GEM or PDP?
hello, and so is there a way to work with pdp only to do this ??? thx david -- TNTB t'es in t'es bat 7 place Favier 13210 St Remy de Provence T/: 04 90 26 95 09 P/: 06 86 86 12 19 + http://www.tntb.net === ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Re: [PD] recursive video feedback in GEM or PDP?
http://www.yourmachines.org/tutorials/pdvideolan.html t'es in t'es bat wrote: hello, and so is there a way to work with pdp only to do this ??? thx david -- TNTB t'es in t'es bat 7 place Favier 13210 St Remy de Provence T/: 04 90 26 95 09 P/: 06 86 86 12 19 + http://www.tntb.net === -- ::: derek holzer ::: http://blog.myspace.com/macumbista ::: http://www.vimeo.com/macumbista ::: ---Oblique Strategy # 60: "Don't be afraid of things because they're easy to do" ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Re: [PD] [OT] Re: DIY GSoC: getting those projects done
On Mon, Mar 30, 2009 at 11:28:40AM -0400, Mathieu Bouchard wrote: > On Sat, 28 Mar 2009, Chris McCormick wrote: > >> When I was thinking about writing a general purpose dataflow programming >> language which addresses some of Pd's shortcomings, I did a lot of thinking >> about the hot and cold inlet paradigm. What I came up with was the following [snip] >> conditions are met: >> * Every cold inlet has been pinged (receives data) >> * Any hot inlet has been pinged (receives data) >> * Inlets cache their last received data if no new data arrives. >> In Pd, DSP inlets act like the 'cold' inlets above > > Well, perhaps you should rename 'neutral' inlets to 'cold' and find > another name for what you call 'cold'. Even then, DSP inlets still don't > work like your 'cold' inlets because of how they combine together a > fan-in (several wires to one inlet) and because of how they handle a > non-connected inlet. Ah yes. In this hypothetical dataflow language in my head, whenever you try and fan cables either in or out, the patcher would automatically turn the fan into a sort of 'bus' of connections like Pd's [t] object. In other words, in this language it would not be possible to fan connections. A default behaviour for incoming fans would be to sum inputs (like DSP fans do now), but this would be easily configurable to 'replace' instead of 'add' as current message in-fanning does. Hmm, maybe I haven't thought that through enough. >> I like the idea of this behaviour being defined by the class author, but >> (re)configurable by the user. > > Then this would need a special 'run' method to be defined in t_class, > preferably outside of the normal method-list. At first thought I think > I'm in favour of reconfigurable inlets, but I'd like to see a > proof-of-concept first. I don't think all the features I'd like in a general purpose dataflow language can even be added to Pd without serious mangling. For a start I'd like the basic data types that all modern languages support like associative arrays, strings, etc. Then I'd like the DSP stuff not to be a special case, but rather a library you can import. Next I would like it if the graphs were represented by a data structure that doesn't suck (e.g. an associative array not a textfile) so that it would be possible to pass the network definition (e.g. the patch) itself through another network to dynamically create and modify patches. This new representation of a patch should be serialisable as JSON or similar so that it's easy to modify by hand and to parse, and to save to disk, or send across a network. JSON would be nice as it's supported by web frameworks, whcih means you could do super-cool stuff like websites which read/write/modify/run patches in your browser, or build patches that use a website to share data between multiple connected clients. Netpd would be really nice in this new language. Lastly, it should feature multi-processing out of the box. Not asking for much, am I? :) I've thought many times about starting to code this language, and have actually hesitantly started a couple of times, but very quickly I realise what a massive undertaking it is and stop. I have too much other work. I guess it would be possible to build the kernel of the lgnaguage with no GUI quite easily, but the hard bit would be the 'batteries included'. Chris. --- http://mccormick.cx ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Re: [PD] [OT] Re: DIY GSoC: getting those projects done
On Mon, Mar 30, 2009 at 06:36:04PM +0100, Claude Heiland-Allen wrote: > Mathieu Bouchard wrote: >> At first thought I think I'm in favour of reconfigurable inlets, but >> I'd like to see a proof-of-concept first. > > IIRC the [lexpr] pdlua example has reconfigurable hot/cold inlets, but > that's implemented "by hand". > > Not sure I like the idea of a "run" method, what if there's more than > one reasonable run action? In Pd terms that means a different action is taken depending on the input, such as float, list, specific symbol, right? So in this hypothetical language the run method could written to do something different depending on the datatype or content of the incoming data, just like it is in Pd. Or maybe I missed your exact meaning? Chris. --- http://mccormick.cx ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Re: [PD] Pdpedia and random generation
so we need :someone" to manage the system, ok, but then I see that this problem is kinda well solved, right? But how do you all see the writting of articles? Is it growing out well? I believe "someone" could also direct how things are going, and that a main team could work on it by fomenting its development and all... right? [] On Tue, Mar 31, 2009 at 9:46 AM, marius schebella < marius.schebe...@gmail.com> wrote: > the "someone" would be in charge of the server space and the > maintainance of the mediawiki (accounts, updates, spam, search > functionality, synchronization with other documentations). this could > also be done by several people, but usually the responsibility is with > one person. all the rest can easily be done by a group of admins or > even be totally open to the public. > > I guess the work that is missing at the moment is not so much about > writing all the articles. > marius. > > 2009/3/31 Alexandre Porres : > > Hi, welll, so "someone" needs to take over? > > I would definately be interested on this. I do, nevertheless, feel I bit > > clueless as I dont know the way to the source of all objects. And cant > > really be an expert on things other than audio/music. > > I also consider rather unfair to be the work of only one ho has taken > over. > > I do believe in forming a team, things like that. > > Anyway, with the convention this year and all, I hope to bring this issue > > into round tables and discussions, make some noise on the list to see if > a > > small group would move a bit their asses to launch this out. > > I could kinda take it over this way. I could definately make the > commitment. > > But I cant be the one and only. I am not even a Native Speaker/Writer of > > English. > > So please help me out here, I also need a partner to guide me and help me > > not getting so bit clueless. > > Cheers > > Alex > > > > ___ > > Pd-list@iem.at mailing list > > UNSUBSCRIBE and account-management -> > > http://lists.puredata.info/listinfo/pd-list > > > > > -- Alexandre Torres Porres cel. (11)8179-6226 Website: http://porres.googlepages.com/home http://www.myspace.com/alexandretorresporres ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Re: [PD] pd book sprint
Hallo, Hans-Christoph Steiner hat gesagt: // Hans-Christoph Steiner wrote: > I think the key to this discussion of -1 to 1 vs 0 to 1 is what people > are most likely going to use them for, and what makes the most sense in > that context. Of course, ideally, it wouldn't create arbitrary > restrictions either. For example, Cyrille and I make basically > everything 0 to 1 in the mapping library since it makes things really > easy to do without sacrificing much flexibility. I think, that's very sensible. > I think the two ranges for this discussion separate signals versus > controls. A sawtooth~ is a signal that is meant to be listened to, so > it would good from -1 to 1. A phasor~ is the exact same shape as a > sawtooth~, but it is meant to be a control, so it is 0 to 1. You could > easily switch the two with some basic math, but most of the time, you'll > want your controls to be 0 to 1 and your signals -1 to 1. A similar > pair would be square~ (signal) and pwm~ (control). I'm with you here except maybe at the object names, but these are just taste-related and maybe educational/language differences - I don't necessarly think of square~ as signal and pwm~ as control (The nusmusk-pwm~ is a "signal", too) I'd just like to add that converting a "control signal" like the phasor~ to a "synth oscillator" takes more than just moving its center to 0, especially bandlimiting. OTOH a bandlimited saw or square generally is useless for control operations because it "wiggles" too much at the jump points. Anyway I've now read the Pd-FLOSS manual page at http://en.flossmanuals.net/PureData/SquarewavesAndLogic and found, that it just tries to explain some general mechanisms to generate square-ish signals from a phasor~. As the basic techniques are the same for "synth oscillators" and "control signals", I think keeping it in a range from 0-1 is sensible. Ciao -- Frank ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Re: [PD] Chicago Patching Circle (Sunday, March 29th 5pm)
Yes, thanks for coming out. I especially liked the Arduino/Sensor demo. I will have to talk with you, Kyle, about how to build one and where you got the parts. And Ben, it would be great to see some of the stuff you are working on, hopefully your moving out of the neighborhood won't deter that... Of course, we could do this again somewhere else. But the idea of hold a small workshop on writing externals would be a great idea. I would be more than happy to share what info I have. An idea for the next meeting. Which bring me to the next question. When is the next meeting? Would you like to try this once a month? More, Less? Thanks again, I would like to see this happen more often. Mike On Mon, Mar 30, 2009 at 11:12 AM, Kyle Klipowicz wrote: > Yeah it was fun to share some meat-space with fellow geeks. > We'll have to plan another one soon, and try to promote it a bit more. > ~Kyle > > On Mon, Mar 30, 2009 at 10:18 AM, Ben Baker-Smith > wrote: >> >> Thanks to Mike for organizing the Chicago meeting yesterday, and to >> Kyle for also showing up. >> >> It was good to connect with some other PD users here, and totally >> interesting to see what you've been working on / have worked on. Even >> (or especially) when it was over my head. >> >> I'd like to do it again some time, assuming that you both haven't >> gotten completely jaded and stopped using PD completely ;) >> I'll be sure to bring some of my own material. >> >> -Ben > > > > -- > - > > - > - -- > http://perhapsidid.wordpress.com > http://myspace.com/kyleklipowicz > -- Rodney Dangerfield - "I haven't spoken to my wife in years. I didn't want to interrupt her." ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Re: [PD] pd book sprint
On Tue, 31 Mar 2009, Hans-Christoph Steiner wrote: I think the two ranges for this discussion separate signals versus controls. A sawtooth~ is a signal that is meant to be listened to, so it would good from -1 to 1. A phasor~ is the exact same shape as a sawtooth~, but it is meant to be a control, so it is 0 to 1. You could easily switch the two with some basic math, but most of the time, you'll want your controls to be 0 to 1 and your signals -1 to 1. A similar pair would be square~ (signal) and pwm~ (control). Those words could be chosen differently. In Pd, signal means both of those things, as it's a single type of wire and a single type of data; and about control... I used to often see the phrase "control object" to mean "message-system object"... but I don't recall whether that was in Pd or in jMax. In any case I think it would be better to say that the 0-to-1 signal is intended as a "multiplicator" or "envelope" whereas the -1-to-1 signal is intended as a... non-multiplicator... or non-envelope... you may have better ideas for names. _ _ __ ___ _ _ _ ... | Mathieu Bouchard - tél:+1.514.383.3801, Montréal, Québec___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Re: [PD] Chicago Patching Circle (Sunday, March 29th 5pm)
Once a month sounds reasonable to me. That feels like enough time for us each to make some progress between meetings. I'm open to whatever though. Definitely interested in a workshop on writing externals. It's an area that I know very little about and feel like an in-person discussion would be a good boost. And I don't mind a bit of traveling, just so long as I can get there by public transportation. -Ben On Tue, Mar 31, 2009 at 2:55 PM, Mike McGonagle wrote: > Yes, thanks for coming out. I especially liked the Arduino/Sensor > demo. I will have to talk with you, Kyle, about how to build one and > where you got the parts. > > And Ben, it would be great to see some of the stuff you are working > on, hopefully your moving out of the neighborhood won't deter that... > Of course, we could do this again somewhere else. > > But the idea of hold a small workshop on writing externals would be a > great idea. I would be more than happy to share what info I have. An > idea for the next meeting. > > Which bring me to the next question. When is the next meeting? Would > you like to try this once a month? More, Less? > > Thanks again, I would like to see this happen more often. > > Mike > > > On Mon, Mar 30, 2009 at 11:12 AM, Kyle Klipowicz wrote: >> Yeah it was fun to share some meat-space with fellow geeks. >> We'll have to plan another one soon, and try to promote it a bit more. >> ~Kyle >> >> On Mon, Mar 30, 2009 at 10:18 AM, Ben Baker-Smith >> wrote: >>> >>> Thanks to Mike for organizing the Chicago meeting yesterday, and to >>> Kyle for also showing up. >>> >>> It was good to connect with some other PD users here, and totally >>> interesting to see what you've been working on / have worked on. Even >>> (or especially) when it was over my head. >>> >>> I'd like to do it again some time, assuming that you both haven't >>> gotten completely jaded and stopped using PD completely ;) >>> I'll be sure to bring some of my own material. >>> >>> -Ben >> >> >> >> -- >> - >> >> - >> - -- >> http://perhapsidid.wordpress.com >> http://myspace.com/kyleklipowicz >> > > > > -- > > Rodney Dangerfield - "I haven't spoken to my wife in years. I didn't > want to interrupt her." > ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Re: [PD] Pdpedia and random generation
2009/3/31 Alexandre Porres : > so we need :someone" to manage the system, ok, but then I see that this > problem is kinda well solved, right? > But how do you all see the writting of articles? Is it growing out well? I > believe "someone" could also direct how things are going, and that a main > team could work on it by fomenting its development and all... > right? Something like a WikiProject on wikipedia? It would be good to have standards on how articles should be formatted and what kind of information should be presented. I see there has been some effort to generate a standard layout for an article on an object, with inlets, outlets, arguments and messages as separate sections; but I can't find a good article to serve as an example for how all articles should look. The best I can find is: http://wiki.puredata.info/en/dac~ http://wiki.puredata.info/en/metro If more articles looked like this, I think pdpedia would be much more useful. Do we want pdpedia to just be a reference manual of objects, or do we also want to include design patterns such as the [pack 0 0 0 0 0]/[unpack 0 0 0 0 0] idiom mentioned elsethread, tutorials, good practices and suchlike? Philip ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Re: [PD] pd book sprint
Hi Frank, in light of what you wrote below, I'd also like to keep the chapters as I have written them, since they are internally consistent. However, one of the first chapters I would like to add would be something like "Improving Audio Signals" which would have two parts: "DC Offset Correction" and "Antialiasing". I think this would be a very vital chapter to add to the Audio Tutorials if anyone wants to pick it up. Otherwise, I will add it myself later on. best! Derek Frank Barknecht wrote: Anyway I've now read the Pd-FLOSS manual page at http://en.flossmanuals.net/PureData/SquarewavesAndLogic and found, that it just tries to explain some general mechanisms to generate square-ish signals from a phasor~. As the basic techniques are the same for "synth oscillators" and "control signals", I think keeping it in a range from 0-1 is sensible. -- ::: derek holzer ::: http://blog.myspace.com/macumbista ::: http://www.vimeo.com/macumbista ::: ---Oblique Strategy # 148: "State the problem in words as clearly as possible" ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Re: [PD] recursive video feedback in GEM or PDP?
Thank you so much for that filter. I was really struggling with figuring out how to utilize [gemframebuffer] and this gives me a place to start. Could this be incorporated into the [gemframebuffer] help patch? That help patch is seriously lacking. Also, if someone could fill me/everyone in about what the [pix_texture] second inlet is for, that would be fantastic. Thanks again, -Ben ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
[PD] PD t-shirts
Hello List, I'm considering designing and selling PD related t-shirts. I haven't totally worked out the logistics. Basically I was inspired by the [Bang( shirts that I've seen online, but which are no longer available as far as I can tell. Anyway, if I did so, I would like to donate all of the proceeds toward further PD development, specifically documentation of poorly documented objects (or example patches, which is basically the same thing). How do you all think would be the best way of going about this? Should I stockpile the money and then offer it to someone as a sort of grant? That's less than ideal in my opinion. I really don't know how to go about this. Any/all input is welcome -Ben ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Re: [PD] recursive video feedback in GEM or PDP?
Ben Baker-Smith wrote: Also, if someone could fill me/everyone in about what the [pix_texture] second inlet is for, that would be fantastic. It's a "texture id" if I remember rightly, so you can have multiple [pix_texture] objects that share the same texture data (so it only needs to be loaded into graphics memory once, saving both space and time). Claude -- http://claudiusmaximus.goto10.org ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Re: [PD] [OT] Re: DIY GSoC: getting those projects done
On Tue, 31 Mar 2009, Chris McCormick wrote:
Then I'd like the DSP stuff not to be a special case, but rather a
library you can import.
It's not much of a feature. It might be a sign of a more modular design,
but what would actually you do with Pd that'd require DSP to be separated
like that?
Next I would like it if the graphs were represented by a data structure
that doesn't suck (e.g. an associative array not a textfile) so that it
would be possible to pass the network definition (e.g. the patch) itself
through another network to dynamically create and modify patches. This
new representation of a patch should be serialisable as JSON or similar
This makes no sense to me. a JSON serialisation is already a textfile, and
the .pd file format is already a serialisation of some data structure.
Actually, that data structure may suck, but it's very replaceable by some
other structure, but that doesn't affect the file format. I have made a
version of Pd that replaces linked-lists by something I called t_boxes
which is defined using a C++ associative array structure:
struct t_boxes : t_gobj {std::map map;}
But really, the file format is the same. I had planned a new file format
but it was 99% compatible with Pd. I don't believe that we'd have to
switch to JSON just before it's newer.
If you're complaining about the format of the IEMGUI constructors, that's
a different problem. This is not part of the .pd format by itself: it's a
subformat. You can abuse another format in the same way, be it JSON, XML,
YAML, LISP data, TCL data, other text formats, binary formats.
The way that IEMGUIs are saved could be fixed without having to change the
Pd format, really. It just needs a bit of imagination. And then, the only
code you'd need to change would be the code of IEMGUIs, just as if they
were still externals. For example, IEMGUIs could save themselves using
Flext-like attributes or GridFlow-like comma-messages, which are two
styles of named-arguments in use in Pd (the latter is actually more like a
[initbang] with a messagebox).
so that it's easy to modify by hand and to parse, and to save to disk,
or send across a network.
Well, you'd have to explain how JSON is going to be any easier to modify,
parse, save and send, because I don't see it. Especially because when you
say JSON, there's nothing that tells me exactly how JSON is going to be
used for that. In any case, the differences between the many ways that you
can use JSON for that, parallel the differences between the many ways Pd's
syntax could be used.
JSON would be nice as it's supported by web frameworks, whcih means you
could do super-cool stuff like websites
Maybe it's just me... I'm not especially web-centric... well, I use the
web a lot, but haven't done any serious web development in this
millenium... so far.
I've thought many times about starting to code this language, and have
actually hesitantly started a couple of times, but very quickly I
realise what a massive undertaking it is and stop.
Well, every person has their favourite way or dream way to encode data,
but it doesn't mean it's enough of a reason to redo things. When I thought
about all those things about format modifications I considered that it's
easier to go "in the direction of the grain", that is, to use the same
parser that is already used all over Pd, and if that's not enough, that
it's still better to make a format 99%-compatible with Pd than 0%.
I have too much other work.
It's also that even if it were not too much work or if you didn't have too
much other work, if you build yourself a small island of software, you are
pretty much alone. You need as many forms of compatibility as you can.
There are several other visual dataflow programming languages that haven't
really taken off because presumably there are not enough plugins for them
and such... a not-so-well-designed programme that is very much used ends
up being much more useful than a lonely programme.
I guess it would be possible to build the kernel of the lgnaguage with
no GUI quite easily, but the hard bit would be the 'batteries included'.
I have no idea what part of the programme is the batteries supposed to
represent.
_ _ __ ___ _ _ _ ...
| Mathieu Bouchard - tél:+1.514.383.3801, Montréal, Québec___
Pd-list@iem.at mailing list
UNSUBSCRIBE and account-management ->
http://lists.puredata.info/listinfo/pd-list
Re: [PD] PD t-shirts
Sounds like a great idea! And some people have been asking me for t- shirts. I have been thinking of a similar thing for Pd-extended. I think the easiest way to handle this would be to set up some kind of fund for the PdConvention. Then who ever is running the Pd Convention would get the funds for the convention. The funds could be used for sponsoring travel, hosting people, food at the conference, space rental, etc. I guess the tricky part is where to collect the money. We've talked about this in the past, it shouldn't get too bogged down in the possibilities. For example, I think it would be ok to have a paypal account that a couple people had access too. It could be something like don...@puredata.info. .hc On Mar 31, 2009, at 10:10 PM, Ben Baker-Smith wrote: Hello List, I'm considering designing and selling PD related t-shirts. I haven't totally worked out the logistics. Basically I was inspired by the [Bang( shirts that I've seen online, but which are no longer available as far as I can tell. Anyway, if I did so, I would like to donate all of the proceeds toward further PD development, specifically documentation of poorly documented objects (or example patches, which is basically the same thing). How do you all think would be the best way of going about this? Should I stockpile the money and then offer it to someone as a sort of grant? That's less than ideal in my opinion. I really don't know how to go about this. Any/all input is welcome -Ben ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list http://at.or.at/hans/ ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Re: [PD] PD t-shirts
Hi Ben, all, We did the last batch of t's as a fundraiser for the Convention in Montréal. We managed to pay for another 1/2 plane ticket with the proceeds :-). Maybe the same could be done for São Paulo? The super folks from Graz sent the file they used for the original t's I should still have it if you want. À bientôt, Alexandre > Hello List, > > I'm considering designing and selling PD related t-shirts. I haven't > totally worked out the logistics. Basically I was inspired by the > [Bang( shirts that I've seen online, but which are no longer available > as far as I can tell. > > Anyway, if I did so, I would like to donate all of the proceeds toward > further PD development, specifically documentation of poorly > documented objects (or example patches, which is basically the same > thing). > > How do you all think would be the best way of going about this? > > Should I stockpile the money and then offer it to someone as a sort of > grant? That's less than ideal in my opinion. I really don't know how > to go about this. > > Any/all input is welcome > > -Ben > > ___ > 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 t-shirts
On Tue, 31 Mar 2009, Ben Baker-Smith wrote: I'm considering designing and selling PD related t-shirts. I haven't totally worked out the logistics. Basically I was inspired by the [Bang( shirts that I've seen online, but which are no longer available as far as I can tell. Yes, as far as I know, the 2004 batch made in Graz sold out in 2004, and the 2006 batch made in Ottawa sold out in 2006. The latter batch had the same front, but the back is not printed, only had t-shirts, and had different colours. I heard that there is still a good number of t-shirts from the 2007 batch made in Montréal. Those are different, as they feature an excerpt of H-C Steiner's "Solitude" DS score, used as the logo of the 2007 convention. I think that there is some more leftover merchandise as well. _ _ __ ___ _ _ _ ... | Mathieu Bouchard - tél:+1.514.383.3801, Montréal, Québec___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Re: [PD] PD t-shirts
please please please, make one with: [bang( | [until] ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
