Re: [PD] live input
THere is some stuff in the Help Browser in Pd-vanilla and a lot of stuff in the Help Browser in Pd-extended. In the Help menu, choose "Browser", then navigate to these: 3.audio.examples manuals/1.Sound You can also check netpd.org and search the net for "pdmtl abstractions" or try some of these: http://puredata.hurleur.com/sujet-1982-diy2-effects-sample-players- synths-sound-synthesis .hc On Dec 3, 2008, at 4:33 PM, <[EMAIL PROTECTED]> wrote: Hello all, I'm trying PD and I'd like to create some example that allow me to capture the sound from a microphone and then modify it through effects such as filters, delay, fft, pitch shift, etc. Is there a tutorial? Patches? Thank you Massimo ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/ listinfo/pd-list As we enjoy great advantages from inventions of others, we should be glad of an opportunity to serve others by any invention of ours; and this we should do freely and generously. - Benjamin Franklin ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Re: [PD] Chicago Patching Circle (Sunday, December 14th)
I just want to interject... take pictures and post them! I forgot to do it at the last NYC Patching Circle... Doh! There was a good turn out 15-20 people. .hc On Dec 3, 2008, at 6:24 PM, Kyle Klipowicz wrote: I think an informal round table about what our usages of Pd are would be a good start. It would be nice to have some various examples. I'm sure we all do things different ways, so I expect to learn a lot just by seeing someone's project and being able to pepper them with questions/try it out/be humbly amazed. ~Kyle On Tue, Dec 2, 2008 at 10:40 PM, Mike McGonagle <[EMAIL PROTECTED]> wrote: Well, I guess my point was not so much an "emphasis" on a HUMAN type of performance, I would be very interested in hearing the types of things you do for these installations... I guess that is why I really don't know what to expect, but I would find it very dry if all we did was talk about code. Pd is just an means to an end, in my view, and the results are the final product, not the code to get those final results... Not to say that I don't want to hear about the code... Guess that is why I am not really sure what this would entail. Mike On Tue, Dec 2, 2008 at 10:27 PM, Kyle Klipowicz <[EMAIL PROTECTED]> wrote: > Yeah I dunno. I am not so much a performer w/ Pd as a user of it for > installation type events. I could bring along my multi-sensor rig that I > used for a few projects recently, and talk about that. I'm no sage so I > can't be too showy... > > ~Kyle > > On Tue, Dec 2, 2008 at 9:13 PM, Mike McGonagle <[EMAIL PROTECTED]> wrote: >> >> Well, I am open to anything, but I am interested to see what the final >> products that people are creating, or even just works in progress. It >> is one thing to just look at the software, but I think that the whole >> point of using the software is to create something that is MORE than >> just the software? >> >> I mean, it would be cool to do both? The first part would be a kind of >> mini performance, followed by a Q&A thing... and then I guess from >> there there could be more exchanges about the software... >> >> I mean, what is the point of these Patching Circles? Is it only about >> the software? Or what we are doing WITH the software? I know, it is >> one of those double edged swords... as both aspects are interesting, >> or else we wouldn't be working with it. >> >> You all know my idea from the above, so I am completely open to any >> suggestions for the format. >> >> Also, to remind people, if you would like to hook things up to a sound >> system, they have aboard that we could hook up several computers to at >> the same time, I have not looked at the specifics of the sound system, >> but I can get that info and pass it on... >> >> Mike >> >> On Tue, Dec 2, 2008 at 7:35 PM, Jacob Lee <[EMAIL PROTECTED]> wrote: >> > I'm still interested :-). Question about the format, though: Is this >> > going to be more learning-oriented or more performance- oriented? That >> > is, are we planning to sit around a table, show patches, ask for help, >> > etc., or should I be prepared to rock out for 10 minutes or so? Either >> > one is cool, I just need to figure out how best to spend the next two >> > weeks. >> > >> > Thanks, >> > -- >> > Jacob Lee >> > [EMAIL PROTECTED] >> > >> > >> > >> > On Sun, Nov 30, 2008 at 5:26 PM, Mike McGonagle <[EMAIL PROTECTED]> >> > wrote: >> >> Hello all, >> >> >> >> Just a reminder about the patching session. Basically, we are on for >> >> Sunday, December 14th, at 5pm. The location is: >> >> >> >> Red Line Tap >> >> 7006 N Glenwood >> >> Chicago, IL >> >> >> >> If you are going via the EL, go to the Morse Stop, and exit to the >> >> north end of the platform. From there, go northwest on Glenwood, the >> >> Red Line Tap is the first door from the corner. >> >> >> >> If you are driving, there is a parking lot to the north, 2 block. It >> >> is a shared lot with the Trilogy center, at Estes and Glenwood. If you >> >> need a map, you can try google maps. >> >> >> >> If everyone who is interested in showing the work they have in >> >> progress could email me, I would like to put together a small list of >> >> all the participants. >> >> >> >> Thanks, >> >> Mike >> >> >> >> -- >> >> Peace may sound simple—one beautiful word— but it requires everything >> >> we have, every quality, every strength, every dream, every high ideal. >> >> —Yehudi Menuhin (1916–1999), musician >> >> >> >> ___ >> >> Pd-list@iem.at mailing list >> >> UNSUBSCRIBE and account-management -> >> >> http://lists.puredata.info/listinfo/pd-list >> >> >> > >> >> >> >> -- >> Peace may sound simple—one beautiful word— but it requires everything >> we have, every quality, every strength, every dream, every high ideal. >> —Yehudi Menuhin (1916–1999), musician >> >> ___ >> Pd-list@iem.at mailing list >
Re: [PD] svn:externals WAS: an easy way to replay a Pd-session (gui)
On Dec 3, 2008, at 6:19 PM, Chris McCormick wrote: > Hi Hans, > > On Tue, Dec 02, 2008 at 12:41:46PM -0500, Hans-Christoph Steiner > wrote: >> I think it's time to have a IRC meeting about this. How about >> Thursday? I am trying to be in #dataflow as much as possible these >> days, if anyone wants to have an impromptu discussion. > > I am happy to meet on IRC, but it will have to be outside work > hours for > me here at GMT. Otherwise the weekend is good, but I think maybe > this is > something that can be solve on-list. I really think you hit the > nail on > the head with this paragraph: > >> My question remains, what is the problem we are trying to solve using >> svn:externals? If it is to include code that gets built with Pd- >> extended, then svn:externals doesn't work well for that, just >> importing releases works much better. If it is to make a centralized >> place to find all Pd code, then I wonder if there is a better tool >> for this, like a special section of SVN for svn:externals outside of >> trunk or a wiki page. > > Can you answer me this: do you see the primary function of Pd > public SVN > as supporting pd-extended builds? If this is the case, then we need a > different part of the repository where external writers and > abstraction > creators can store their code/patches independent of pd-extended. The > reason we need this is that whilst pd-extended is a wonderful project, > and definately neccessary, not everyone in the Pd world runs it and > probably some people aren't even interested in seeing their work as > part > of pd-extended, but they are definately interested in participating in > the development community of Pd. We can't just have a wiki page as > that > doesn't suffice for people who want their code versioned inside the > world of Pd code but aren't interested in pd-extended. > > What about if SVN was the central place where Pd and related code > lives, > and there was a sub-place within that where pd-extended keeps its > source? Most definately snapshots/tags of the former could be > copied via > standard svn commands into the latter to make them part of pd-extended > at stable release. This would probably help with co-ordinating and > versioning too. You could tell people "we are coming up for a > pd-extended release, please copy your latest tags into the pd-extended > folder" or do this yourself for code that you maintain. I guess the > crux > of what I'm saying is that I don't see the Pd svn trunk as being == to > pd-extended. I see pd-extended as being a part of the ecosystem living > in the svn trunk. I don't think it's fair for one project to be > 100% the > boss of trunk. In fact, I find it kind of annoying that once upon a > time > I could check out people's code from the svn and compile it > independently, whereas last time I tried I couldn't do it as a > bunch of > environment variables weren't set and stuff. I had to hack giant > complicated makefiles just to compile one simple external. > > Please excuse me if I've missed anything obvious or said anything > stupid, and feel free to correct me if I am misguided or wrong > about the > position of pd-extended in the repository. Maybe it's all just > semantics. But I guess semantics are important in human communities. > > Loving the broken paradise, :) I don't think anyone is saying that pure-data SVN == pd-extended, plus I don't think anyone is saying that it should be that way. My objection to svn:externals comes from the fact that I have to do a lot of annoying work to manage the Pd-extended builds, and so far svn:externals has only made that worse. I don't know about svn --ignore-externals, anyone care to expand on that? (yes, I can RTFM, but I am talking real world experience as related to Pd, which TFM will not tell me) What about the idea of having a separate section like /pure-data/svn-externals? If people object to having the imported releases in trunk, I can easily manage that in the pd-extended branch. .hc > > Chris. > > --- > http://mccormick.cx 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] list-sort
Hi, Yeah, the [table]-based version is much much faster than the list-based version, so it can replace the old one; the upside is that it's also more transparent. I don't know about resizing tables either, so I agree to err on the side of caution. 100 seems appropriate. Attached a version which will resize the table up to the nearest hundred, and it will stay that way until it receives a list that's larger than the current table at which point it will add another hundred... that way it will adapt to list sizes in case it gets many lists in a row with more than 100 elements. It's still called [list-shellsort-tab] for clarity on the list. Matt > Date: Wed, 3 Dec 2008 22:30:09 +0100 > From: Frank Barknecht <[EMAIL PROTECTED]> > Subject: Re: [PD] list-sort > To: pd-list@iem.at > Message-ID: <[EMAIL PROTECTED]> > Content-Type: text/plain; charset=us-ascii > > Hallo, > Matt Barber hat gesagt: // Matt Barber wrote: > >> I had attached one to the last post I sent -- look for list-shellsort-tab.pd > > Seems I had deleted that one by mistake - but I got it from the > archives. That's very cool! Do you think I should replace the version in > the SVN with the table version? > > I'm just not quite sure if resizing the table should be a bit more > conservative, as I believe, resizing tables is a bit costly in Pd (and > it may lead to dsp-chain reorderings, but I don't know much about that > topic.) > > Probably we can get away with just keeping the default table size of 100 > elements and only resize and free if the lists are longer than that. > > Ciao > -- > Frank #N canvas 686 156 469 402 10; #X obj 26 -25 inlet; #X obj 26 222 outlet; #N canvas 416 392 593 257 \$0-gap-loop 0; #X obj 137 66 / 2; #X obj 137 89 int; #X obj 34 122 until; #X obj 34 49 t b f; #X obj 189 105 sel 0; #X obj 137 142 t f f; #X obj 59 159 f; #X obj 34 26 inlet; #X obj 59 213 outlet; #X text 91 22 Start with a gap of floor(n/2) \, continue to decrease gap by powers of 1/2.; #X obj 59 181 t f f; #X text 118 182 <== order doesn't matter here \, but we force each iteration of this loop to finish before going on to the next... this seems to save time.; #X connect 0 0 1 0; #X connect 1 0 5 0; #X connect 2 0 6 0; #X connect 3 0 2 0; #X connect 3 1 0 0; #X connect 4 0 2 1; #X connect 5 0 6 1; #X connect 5 1 4 0; #X connect 6 0 10 0; #X connect 7 0 3 0; #X connect 10 0 8 0; #X connect 10 1 0 0; #X restore 174 151 pd \$0-gap-loop; #N canvas 584 66 594 302 \$0-increment-loop 0; #X obj 41 56 inlet; #X obj 222 111 inlet; #X obj 41 113 until; #X obj 41 83 t b f; #X obj 100 130 f; #X obj 150 132 + 1; #X obj 100 182 moses; #X obj 168 199 t b; #X obj 100 218 outlet; #X obj 100 159 t f f; #X text 41 16 Iterate over all the pairs whose indices are related by the current gap size.; #X text 173 155 <== order doesn't matter here \, but we force each iteration of this loop to finish before going on to the next... this seems to save time.; #X obj 168 222 s \$0-stop-inc-loop; #X obj 86 83 r \$0-stop-inc-loop; #X connect 0 0 3 0; #X connect 1 0 6 1; #X connect 2 0 4 0; #X connect 3 0 2 0; #X connect 3 1 4 1; #X connect 4 0 9 0; #X connect 5 0 4 1; #X connect 6 0 8 0; #X connect 6 1 7 0; #X connect 7 0 12 0; #X connect 9 0 6 0; #X connect 9 1 5 0; #X connect 13 0 2 1; #X restore 174 196 pd \$0-increment-loop; #X obj 174 126 t f f; #X obj 174 174 t f f; #N canvas 183 142 507 640 \$0-test-swap-loop 0; #X obj 82 90 inlet; #X obj 299 96 inlet; #X obj 82 113 -; #X obj 284 174 +; #X obj 82 449 >; #X obj 82 473 sel 0 1; #X obj 257 499 f; #X obj 290 499 f; #X obj 82 178 until; #X obj 174 241 moses 0; #X obj 174 216 f; #X obj 207 216 -; #X obj 82 134 t b f; #X obj 227 454 t b b; #X obj 213 263 s \$0-idx; #X obj 311 135 r \$0-idx; #X obj 272 442 r \$0-idx; #X obj 97 335 r \$0-idx; #X obj 284 195 s \$0-idx+gap; #X obj 305 466 r \$0-idx+gap; #X obj 220 322 r \$0-idx+gap; #N canvas 468 185 584 529 swap? 0; #X obj 40 52 inlet; #X obj 153 52 inlet; #X obj 40 272 spigot 1; #X obj 256 272 spigot; #X obj 361 224 unpack 0 0; #X msg 361 178 1 0; #X msg 412 196 0 1; #X obj 463 93 select 0; #X obj 361 71 select asc desc; #X obj 40 437 outlet; #X obj 153 437 outlet; #X obj 256 300 swap; #X obj 153 271 spigot 1; #X obj 317 273 spigot; #X obj 361 45 r \$0-direction; #X connect 0 0 2 0; #X connect 0 0 3 0; #X connect 1 0 12 0; #X connect 1 0 13 0; #X connect 2 0 9 0; #X connect 3 0 11 0; #X connect 4 0 2 1; #X connect 4 0 12 1; #X connect 4 1 3 1; #X connect 4 1 13 1; #X connect 5 0 4 0; #X connect 6 0 4 0; #X connect 7 0 5 0; #X connect 7 1 6 0; #X connect 8 0 5 0; #X connect 8 1 6 0; #X connect 8 2 7 0; #X connect 11 0 9 0; #X connect 11 1 10 0; #X connect 12 0 10 0; #X connect 13 0 11 1; #X connect 14 0 8 0; #X restore 82 426 pd swap?; #X obj 82 542 s \$0-stop-test-loop; #X obj 174 285 s \$0-stop-test-loop; #X obj 130 136 r \$0-stop-test-loop; #X obj 82 517 t b; #X obj 174 262 t b; #X text 74 13 If current pair is out of order \, swap them. Then \, if after the swap the values at the lef
Re: [PD] Remove top menu-bar on MACosX
if it is for GEM on fullscreen mode (or not) you can send [menubar 0 ( to [gemwin]. ++ Jack Le 4 déc. 08 à 01:48, Carlos Caires a écrit : Hi, anybody know if there is a way (pd objet or message) to remove the top menu-bar from the MacOS desktop??? thks, Carlos. Esta mensagem (incluindo quaisquer anexos) pode conter informação confidencial ou legalmente protegida para uso exclusivo do destinatário. Se não for o destinatário pretendido da mesma, não deverá fazer uso, copiar, distribuir ou revelar o seu conteúdo (incluindo quaisquer anexos) a terceiros, sem a devida autorização. Se recebeu esta mensagem por engano, por favor informe o emissor, por e-mail, e elimine-a imediatamente. Obrigado. This message may contain confidential information or privileged material, and is intended only for de individual(s) named. If you are not in the named addressee, you should not disseminate, distribute or copy this e-mail. Please notify the sender immediately by e-mail if you have received this e-mail by mistake and delete this e-mail from your system. ___ 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] Remove top menu-bar on MACosX
Hi, anybody know if there is a way (pd objet or message) to remove the top menu-bar from the MacOS desktop??? thks, Carlos. Esta mensagem (incluindo quaisquer anexos) pode conter informação confidencial ou legalmente protegida para uso exclusivo do destinatário. Se não for o destinatário pretendido da mesma, não deverá fazer uso, copiar, distribuir ou revelar o seu conteúdo (incluindo quaisquer anexos) a terceiros, sem a devida autorização. Se recebeu esta mensagem por engano, por favor informe o emissor, por e-mail, e elimine-a imediatamente. Obrigado.This message may contain confidential information or privileged material, and is intended only for de individual(s) named. If you are not in the named addressee, you should not disseminate, distribute or copy this e-mail. Please notify the sender immediately by e-mail if you have received this e-mail by mistake and delete this e-mail from your system. ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Re: [PD] Chicago Patching Circle (Sunday, December 14th)
I think an informal round table about what our usages of Pd are would be a good start. It would be nice to have some various examples. I'm sure we all do things different ways, so I expect to learn a lot just by seeing someone's project and being able to pepper them with questions/try it out/be humbly amazed. ~Kyle On Tue, Dec 2, 2008 at 10:40 PM, Mike McGonagle <[EMAIL PROTECTED]> wrote: > Well, I guess my point was not so much an "emphasis" on a HUMAN type > of performance, I would be very interested in hearing the types of > things you do for these installations... I guess that is why I really > don't know what to expect, but I would find it very dry if all we did > was talk about code. Pd is just an means to an end, in my view, and > the results are the final product, not the code to get those final > results... Not to say that I don't want to hear about the code... > > Guess that is why I am not really sure what this would entail. > > Mike > > > On Tue, Dec 2, 2008 at 10:27 PM, Kyle Klipowicz <[EMAIL PROTECTED]> > wrote: > > Yeah I dunno. I am not so much a performer w/ Pd as a user of it for > > installation type events. I could bring along my multi-sensor rig that I > > used for a few projects recently, and talk about that. I'm no sage so I > > can't be too showy... > > > > ~Kyle > > > > On Tue, Dec 2, 2008 at 9:13 PM, Mike McGonagle <[EMAIL PROTECTED]> wrote: > >> > >> Well, I am open to anything, but I am interested to see what the final > >> products that people are creating, or even just works in progress. It > >> is one thing to just look at the software, but I think that the whole > >> point of using the software is to create something that is MORE than > >> just the software? > >> > >> I mean, it would be cool to do both? The first part would be a kind of > >> mini performance, followed by a Q&A thing... and then I guess from > >> there there could be more exchanges about the software... > >> > >> I mean, what is the point of these Patching Circles? Is it only about > >> the software? Or what we are doing WITH the software? I know, it is > >> one of those double edged swords... as both aspects are interesting, > >> or else we wouldn't be working with it. > >> > >> You all know my idea from the above, so I am completely open to any > >> suggestions for the format. > >> > >> Also, to remind people, if you would like to hook things up to a sound > >> system, they have aboard that we could hook up several computers to at > >> the same time, I have not looked at the specifics of the sound system, > >> but I can get that info and pass it on... > >> > >> Mike > >> > >> On Tue, Dec 2, 2008 at 7:35 PM, Jacob Lee <[EMAIL PROTECTED]> wrote: > >> > I'm still interested :-). Question about the format, though: Is this > >> > going to be more learning-oriented or more performance-oriented? That > >> > is, are we planning to sit around a table, show patches, ask for help, > >> > etc., or should I be prepared to rock out for 10 minutes or so? Either > >> > one is cool, I just need to figure out how best to spend the next two > >> > weeks. > >> > > >> > Thanks, > >> > -- > >> > Jacob Lee > >> > [EMAIL PROTECTED] > >> > > >> > > >> > > >> > On Sun, Nov 30, 2008 at 5:26 PM, Mike McGonagle <[EMAIL PROTECTED]> > >> > wrote: > >> >> Hello all, > >> >> > >> >> Just a reminder about the patching session. Basically, we are on for > >> >> Sunday, December 14th, at 5pm. The location is: > >> >> > >> >> Red Line Tap > >> >> 7006 N Glenwood > >> >> Chicago, IL > >> >> > >> >> If you are going via the EL, go to the Morse Stop, and exit to the > >> >> north end of the platform. From there, go northwest on Glenwood, the > >> >> Red Line Tap is the first door from the corner. > >> >> > >> >> If you are driving, there is a parking lot to the north, 2 block. It > >> >> is a shared lot with the Trilogy center, at Estes and Glenwood. If > you > >> >> need a map, you can try google maps. > >> >> > >> >> If everyone who is interested in showing the work they have in > >> >> progress could email me, I would like to put together a small list of > >> >> all the participants. > >> >> > >> >> Thanks, > >> >> Mike > >> >> > >> >> -- > >> >> Peace may sound simple—one beautiful word— but it requires everything > >> >> we have, every quality, every strength, every dream, every high > ideal. > >> >> —Yehudi Menuhin (1916–1999), musician > >> >> > >> >> ___ > >> >> Pd-list@iem.at mailing list > >> >> UNSUBSCRIBE and account-management -> > >> >> http://lists.puredata.info/listinfo/pd-list > >> >> > >> > > >> > >> > >> > >> -- > >> Peace may sound simple—one beautiful word— but it requires everything > >> we have, every quality, every strength, every dream, every high ideal. > >> —Yehudi Menuhin (1916–1999), musician > >> > >> ___ > >> Pd-list@iem.at mailing list > >> UNSUBSCRIBE and account-management -> > >> http://lists.puredata.info/listinfo/pd-lis
Re: [PD] svn:externals WAS: an easy way to replay a Pd-session (gui)
Hi Hans, On Tue, Dec 02, 2008 at 12:41:46PM -0500, Hans-Christoph Steiner wrote: > I think it's time to have a IRC meeting about this. How about > Thursday? I am trying to be in #dataflow as much as possible these > days, if anyone wants to have an impromptu discussion. I am happy to meet on IRC, but it will have to be outside work hours for me here at GMT. Otherwise the weekend is good, but I think maybe this is something that can be solve on-list. I really think you hit the nail on the head with this paragraph: > My question remains, what is the problem we are trying to solve using > svn:externals? If it is to include code that gets built with Pd- > extended, then svn:externals doesn't work well for that, just > importing releases works much better. If it is to make a centralized > place to find all Pd code, then I wonder if there is a better tool > for this, like a special section of SVN for svn:externals outside of > trunk or a wiki page. Can you answer me this: do you see the primary function of Pd public SVN as supporting pd-extended builds? If this is the case, then we need a different part of the repository where external writers and abstraction creators can store their code/patches independent of pd-extended. The reason we need this is that whilst pd-extended is a wonderful project, and definately neccessary, not everyone in the Pd world runs it and probably some people aren't even interested in seeing their work as part of pd-extended, but they are definately interested in participating in the development community of Pd. We can't just have a wiki page as that doesn't suffice for people who want their code versioned inside the world of Pd code but aren't interested in pd-extended. What about if SVN was the central place where Pd and related code lives, and there was a sub-place within that where pd-extended keeps its source? Most definately snapshots/tags of the former could be copied via standard svn commands into the latter to make them part of pd-extended at stable release. This would probably help with co-ordinating and versioning too. You could tell people "we are coming up for a pd-extended release, please copy your latest tags into the pd-extended folder" or do this yourself for code that you maintain. I guess the crux of what I'm saying is that I don't see the Pd svn trunk as being == to pd-extended. I see pd-extended as being a part of the ecosystem living in the svn trunk. I don't think it's fair for one project to be 100% the boss of trunk. In fact, I find it kind of annoying that once upon a time I could check out people's code from the svn and compile it independently, whereas last time I tried I couldn't do it as a bunch of environment variables weren't set and stuff. I had to hack giant complicated makefiles just to compile one simple external. Please excuse me if I've missed anything obvious or said anything stupid, and feel free to correct me if I am misguided or wrong about the position of pd-extended in the repository. Maybe it's all just semantics. But I guess semantics are important in human communities. Loving the broken paradise, :) Chris. --- http://mccormick.cx ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
[PD] live input
Hello all, I'm trying PD and I'd like to create some example that allow me to capture the sound from a microphone and then modify it through effects such as filters, delay, fft, pitch shift, etc. Is there a tutorial? Patches? Thank you Massimo ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Re: [PD] list-sort
Hallo, Matt Barber hat gesagt: // Matt Barber wrote: > I had attached one to the last post I sent -- look for list-shellsort-tab.pd Seems I had deleted that one by mistake - but I got it from the archives. That's very cool! Do you think I should replace the version in the SVN with the table version? I'm just not quite sure if resizing the table should be a bit more conservative, as I believe, resizing tables is a bit costly in Pd (and it may lead to dsp-chain reorderings, but I don't know much about that topic.) Probably we can get away with just keeping the default table size of 100 elements and only resize and free if the lists are longer than that. Ciao -- Frank ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Re: [PD] [PD-announce] reware howto video
On Dec 3, 2008, at 5:34 AM, Steffen Juul wrote: > >>> On Mon, Dec 1, 2008 at 6:54 PM, Hans-Christoph Steiner >>> <[EMAIL PROTECTED]> wrote: >>> >>> old devices and run new software on them. We now have our first >>> Reware HOWTO video, showing the basics of how to use a Reware image >>> yourself, then it illustrates some of the Pd patches we've made: > > That's one well made demo video. Thanks for that. > > Insight on how it was recorded/edited would be cool. I'm guessing you > recorded the screen(action/"cast") in parallel with the other video > shot > by a camera also recording the audio? But how did you get the > syncing in > the cuts so tight? Albert Wilking made the video, he's the pro. So it was shot on a "real" camera, with some basic lighting. He was good about pushing me to get organized, speak slowly, stage shots, etc. It also helps that I have already made some other simple videos like this, and have given tons of demos recently, so I could do the demos more or less on auto-pilot. The sync is good because we ran the screen capture at the same time as filming. The screen capture was done with recordmydesktop on Ubuntu Hardy. It's in synaptic, it's super easy to use, and works well. It's funny, because screencasting is actually far and away easier on Ubuntu than Mac OS X or Windows, from my experience. Yay free software! He edited the video on Final Cut Pro, but its a pretty simple edit, so other software would work. I am learning Open Movie Editor currently. .hc There is no way to peace, peace is the way. -A.J. Muste ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Re: [PD] Open alternative to RJDJ?
Hey, I don't know if you have been following the Reware project, but that is a core idea of it. Check out our first HOWTO for an intro: http://www.youtube.com/watch?v=tMnIh2lWB6M We got some Palms and iPaqs going, then there is the Nokia Webtablets, iPods, and the BeagleBoard. Gumstix are also possible, I have one, but I haven't had a chance to work on it yet. Our core idea is to make a whole linux distro with Pd, Python, and Lua that has nothing at all running, except your code. Something like Arduino for hacking PDAs. It is also possible to install Pd-anywhere packages on a number of existing distros, like Maemo, Familiar, Angstrom, etc. .hc On Dec 3, 2008, at 7:15 AM, Derek Holzer wrote: > I'm gathering information currently for a potential exhibition > involving > mobile sound devices for 2010. My criteria are as follows: > > 1) Gathering and processing of environmental sounds > 2) Open source software and open and/or accessible hardware > 3) Doesn't make only techno music! ;-) > > and optional: > > 4) User's location and/or movement become processing criteria > 5) Ability to network with other devices to share sounds and > information > > The RJDJ project sounds like it fits the first and fourth, I don't > know > about the others. I agree with several of the posters on this list who > were suspicious of a project using free software but geared only > towards > expensive hardware like iPhones. But I don't want to totally discredit > the momentum that's gone into this project. So my questions are: > > 1) Can RJDJ "scenes" run on other platforms (Palm, iPaq, Gumstix, > Linux > iPod, whatever?) > 2) Is anyone working on an RJDJ-like/compatible platform which is > actually open and accessible? > > I will drop by the Berlin RJDJ sprint with these kind of questions in > mind in case anyone wants to discuss them in person. > > best! > Derek > > -- > derek holzer ::: http://www.umatic.nl ::: http://blog.myspace.com/ > macumbista > ---Oblique Strategy # 160: > "Towards the insignificant" > > ___ > Pd-list@iem.at mailing list > UNSUBSCRIBE and account-management -> http://lists.puredata.info/ > listinfo/pd-list As we enjoy great advantages from inventions of others, we should be glad of an opportunity to serve others by any invention of ours; and this we should do freely and generously. - Benjamin Franklin ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Re: [PD] svn:externals WAS: an easy way to replay a Pd-session (gui)
Hans-Christoph Steiner wrote: >> >> i think such "workflow" does more harm than not. > > If you don't like this workflow you don't have to use it. For what the...? i am describing a real-world problem and the only answer you have to it is: "if you don't like it, don't use it"? > Pd-extended, there needs to be little changes to makes sure everything > works together, so svn:externals does not work for that. If you don't > care about Pd-extended, then you don't need to import code into the SVN > there. where? into Pd-extended? i don't- > I think a reasonable solution to this is to make a section of the svn, > like pure-data/svn-externals, where everyone is free to add links to > there repos. That way people use svn-externals as much as they want, > and changes in their repos don't break the automatic nightly builds. people who can add links to external repositories can as well add broken code directly, so this is no argument. the only real drawback about svn:externals is (and we've had this already), that people are using self-signed certificates which stops the build-process (because you cannot tell svn to blindly accept an invalid certificate) oh, btw, if you don't like svn:externals, just don't check them out: luckily there is the "--ignore-externals" flag. fgmasr IOhannes > > .hc ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Re: [PD] list-sort
I had attached one to the last post I sent -- look for list-shellsort-tab.pd > > But a [table]-based implementation of sorting is tempting, as we only do > float-sorting anyway. > > Ciao > -- > Frank ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Re: [PD] beginnings of 'framesync' library
On Dec 3, 2008, at 11:38 AM, IOhannes m zmölnig wrote: > patrick wrote: >> hi hans, >> >> i know almost nothing about pd svn, but i was looking at framesync >> and >> there is no external (.pd_linux, .pd_darwin, .dll). > > no generated file (e.g. binaries which are generated by compiling > source-code) should ever be under version control. > >> should it be in >> abstractions instead? >> > > i think on the long run all ./abstractions should be moved to ./ > externals > i did not do it yet because i haven't taken the time yet, to ask the > relevant authors whether this would be fine for them. My thoughts exactly... but I don't think it is worth it to just move 'abstractions' to 'externals'. We should probably have a more comprehensive reorg. Yeah, it does seem to be political... .hc > > fgmadr > IOhannes > > ___ > Pd-list@iem.at mailing list > UNSUBSCRIBE and account-management -> http://lists.puredata.info/ > listinfo/pd-list If you are not part of the solution, you are part of the problem. ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Re: [PD] svn:externals WAS: an easy way to replay a Pd-session (gui)
On Dec 3, 2008, at 11:56 AM, IOhannes m zmölnig wrote: > Hans-Christoph Steiner wrote: >> On Dec 2, 2008, at 6:36 AM, Chris McCormick wrote: > is there any chance to sync the two repositories? (personally i would still suggest an svn:externals link; but let's keep this for later :-)) > > sorry for re-starting the flame-war. > it was not my intention but couldn't keep my mouth shut. > >> I really don't want to dictate here, but I think we need to decide on >> how we use the SVN. svn:externals create more annoying work in >> regards to getting Pd-extended builds out, but that is not the only >> use of the SVN. I can accept more annoying work, but there needs to >> be a good reason. >> >> My question remains, what is the problem we are trying to solve using >> svn:externals? If it is to include code that gets built with Pd- >> extended, then svn:externals doesn't work well for that, just >> importing releases works much better. > > this is the main point where i disagree. > most Pd-libraries seem to have stopped doing a regular release-cycle. > for those included in Pd-extended, this is most likely due to their > inclusion in Pd-extended. > other libraries do not have a release cycle too, esp. if they are > under > some kind of public avaible version control system. the reason remains > unknown, but i guess for most of these their upstream author consider > release cycles for a "minor" library to much of a hazzle. > > i totally understand e.g. chris, if he doesn't want to re-import a new > version of s-abstractions just because he has added 2 objects. > (this is jut my interpretation) > > but nevertheless: s-abstractions are in our svn, chris pointed me to > s-totalrecall.pd which i thought (rightfully) to be part of > s-abstractions (without having ever had a look at this library), i > checked whether this lib is in my checkout of the repo (which it > is) and > i couldn't find the very object. > assuming that chris hadn't made fun of me, i checked the logfiles of > s-abstractions and noted that there was only a initial submit. > i decided to search for the library on other places (using google) and > eventually found the upstream repository. > > i think such "workflow" does more harm than not. If you don't like this workflow you don't have to use it. For Pd- extended, there needs to be little changes to makes sure everything works together, so svn:externals does not work for that. If you don't care about Pd-extended, then you don't need to import code into the SVN there. I think a reasonable solution to this is to make a section of the svn, like pure-data/svn-externals, where everyone is free to add links to there repos. That way people use svn-externals as much as they want, and changes in their repos don't break the automatic nightly builds. .hc >> I think it's time to have a IRC meeting about this. How about >> Thursday? I am trying to be in #dataflow as much as possible these >> days, if anyone wants to have an impromptu discussion. > > i'm at piksel right now, so i will not be able to attend any > meeting in > this week, > >> > > > mfga.r > IOhannes > > ___ > Pd-list@iem.at mailing list > UNSUBSCRIBE and account-management -> http://lists.puredata.info/ > listinfo/pd-list "It is convenient to imagine a power beyond us because that means we don't have to examine our own lives.", from "The Idols of Environmentalism", by Curtis White ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
[PD] [OT] Hardware suggestions - Webcam for GEM/pdp/Linux
Hey List! I'm looking for a webcam wich I can use with [EMAIL PROTECTED], preferable with v4l (v4l2 support is still difficult with some apps), usb preferred. It has to be a camera with ccd (no cmos chip). maybe there are *no* cameras with v4l and [EMAIL PROTECTED] - perhaps someone knows? Did anyone try a philips spc900nc camera? It should support 90fps at lower resolutions but I didn't find one single positive mention about that with linux. not that important, but nice to have: it would be great if the infrared blocking filter was removable when the camera is opened, because I have to use it in IR range for tracking. If it's not removable it doesn't really matter because usually it's possible to unscrew and replace the lens with an IR-compatible lens from other webcams. I already tried 2 cams: Logitech Quickcam Pro 5000: [EMAIL PROTECTED], very low latency, v4l2 driver (no v4l compatibility), raw-mode with 640x480 or 640x380 (didn't get other resolutions to work), lot of dead pixels (10 dead pixels on 2 different models each, seems to be a secret linux-feature, hidden on windows-driver), not very crisp but usable image quality, IR-Filter not removable from Lens, whole Lens can be easily unscrewed when camera is opened, easy to open, no adjustable focus when not opened. Philips Vesta Pro (PCVC680K): [EMAIL PROTECTED], v4l driver, slow, less light sensitive than quickcam but nice crisp image, old (only few used models available), removable IR-Filter (pop off the first "ring" on the object lens to remove), tripod mount, rugged housing. both lens-mounts are compatible, seems to be an undefined "standard" sorry for posting that much - perhaps it's useful for someone? kind regards, and thanks... Martin ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
[PD] [PD-announce] NIME concert @ Exit Art NYC, Monday, Dec 15th
Come see some Pd instruments in action: > NIME @ Exit Art > http://itp.nyu.edu/nime/show/ > 475 Tenth Avenue > New York, NY > > Monday, December 15, 2008 > Performances 8PM-11PM > Doors open at 7PM > > NIME: New Interfaces for Musical Expression. > NIME: creating new performance tools for digital music. > NIME: a graduate course at NYU’s Interactive Telecommunications > Program (ITP). > > In the seventh annual NIME end-of-semester performance, students > will perform on a series of newly designed electronic instruments > that aim to keep the “live” in live performance of digital music. > The NIME performances are presented by ITP instructor Hans- > Christoph Steiner. > > Computer music is usually played with a keyboard and mouse. Laptop > musicians often sit at a desk and give performances that are little > more than watching someone engage in “office gestures.” The idea > behind NIME is to go beyond the mouse and keyboard, beyond even > piano keyboards and drum pads, and develop performance tools that > make the most out of the new opportunities that digital music > offers. NIME students answer questions like: > - "What will the next generation of musical instruments look like?" > - "What will they be able to do that traditional instruments can’t > already do?" > - "What aspects of traditional instruments will we want to retain > in digital instruments?" > > Over the course of this year’s 14-week course, students are > developing projects such as a collection of autonomous solar- > powered robots, a augmented flutist, plate-spinning sampler, sing- > along animatronics, and a host of others. > > NIME at ITP > http://itp.nyu.edu/nime > Hans-Christoph Steiner, +1-718-360-4872, [EMAIL PROTECTED] > > ITP > http://itp.nyu.edu > George Agudow +1-212-998-1891, [EMAIL PROTECTED] > > EXIT ART > 475 Tenth Avenue (at 36th Street) > New York, NY 10018 > (212) 966-7745 > [EMAIL PROTECTED] > http://www.exitart.org Computer science is no more related to the computer than astronomy is related to the telescope. -Edsger Dykstra ___ Pd-announce mailing list [EMAIL PROTECTED] 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] Peripheral USB devices
if you device is not hid but use libusb, then you can have a look at externals/hardware/multio.c - of course you will need to adjust it (vendor_id, product_id). pat ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Re: [PD] list-sort
Hallo, Matt Barber hat gesagt: // Matt Barber wrote: > Very fast, but what I like about list-abs is its pedagogical potential > for students who will never look at C-code but might be interested to > see things go in Pd. You've got the point here. For list-abs, externals are not allowed. That's the whole point of it: Provide a common interface for list operations that run on every vanilla Pd without externals. *However*: That should not stop anyone from making alternative implementations of the same interface. In fact, my personal [list-drip] is just a wrapper around zexy's [drip]. I put it in my pd-path before the list-abs path so it gets loaded instead. For sorting you could for example use zexy's [sort] inside of [list-sort] and have a very fast sorting. Or write one in Lua and sort symbols as well. Etc. But a [table]-based implementation of sorting is tempting, as we only do float-sorting anyway. Ciao -- Frank ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Re: [PD] list-sort
Very fast, but what I like about list-abs is its pedagogical potential for students who will never look at C-code but might be interested to see things go in Pd. But yeah, a set of externals for production purposes might be neat. Matt On Wed, Dec 3, 2008 at 12:25 PM, Martin Peach <[EMAIL PROTECTED]> wrote: > Matt Barber wrote: >> >> So instead, actually implement it in an array and sort it in place! >> >> Very fast. >> > > (Of course it works for lists of numbers only). It would be even faster to > have coded externals that operate on tables like that. I have made one, > [mrpeach/tabfind], that gives the nth index of a number or list of numbers > found in a table. This follows Miller's suggestion that tables are the right > way to manipulate strings without adding them to the symbol table. An > external that sorted a table in place would be very fast. > > > Martin > > > > > > >> >> On Tue, Dec 2, 2008 at 10:16 PM, Matt Barber <[EMAIL PROTECTED]> wrote: >> > Also, I find it extremely tempting to think of a list of numbers as an >> > array[ ], but this analogy won't hold because you can't operate on the >> > list in-place -- I'm sure a lot of the overhead is in feeding entire >> > lists back and forth and around to the different parts of the patches. >> > Maybe the algorithm with the fewest total [list] operations sometimes >> > wins out over the algorithm that's in general more efficient. >> > >> > Matt >> > >> > >> > >> > On Tue, Dec 2, 2008 at 10:01 PM, Matt Barber <[EMAIL PROTECTED]> >> > wrote: >> >> For what it's worth, >> >> >> >> I just ran one possible benchmark on the [list-*sort] abstractions >> >> submitted recently, using [list-random] and [realtime]. >> >> >> >> I think overall the overhead for [list-sort] is much less than for >> >> [list-shellsort] -- for short lists (<100) it takes about half the >> >> time. [list-shellsort] is a bit quicker when the variance of the >> >> elements is smaller (which makes sense because the more alike the >> >> elements are the less the innermost loop will have to run) -- but >> >> [list-sort] still beats it. I have a feeling that some of the >> >> overhead in [list-shellsort] is in the [list-swap] function and other >> >> list-abs objects, which are a little too feature-rich and/or >> >> idiot-proof for this particular use. =o) >> >> >> >> >> >> However, after some trial and error with [list-sort] I found I am >> >> unable to sort a list of more than exactly 121 elements without >> >> freezing Pd -- 122 and up will freeze it. This is because the main >> >> loop is not controlled with an [until] -- I think you can see the >> >> structure of [list-drip] for similar reasoning (the [until] is not >> >> "needed" logically, but helps with long lists to do it in steps). >> >> After implementing the [until] loop, I found that [list-sort] is even >> >> quicker than before, but the efficiency of the [list-shellsort] >> >> algorithm take over for list sizes >450 -- above that [list-shellsort] >> >> is substantially quicker (and quicker yet if the variance is low). It >> >> beats [list-sort] by half for a list about 1300-1400 elements long or >> >> so (but not within reason -- it still takes about 2 seconds!). >> >> >> >> >> >> I attached the new [list-sort] and the goofy little diagnostic. >> >> >> >> Matt >> >> >> >> >> >>> Date: Tue, 2 Dec 2008 13:59:08 +0100 >> >>> From: Frank Barknecht <[EMAIL PROTECTED]> >> >>> Subject: Re: [PD] list-sort >> >>> To: pd-list@iem.at >> >>> Message-ID: <[EMAIL PROTECTED]> >> >>> Content-Type: text/plain; charset="us-ascii" >> >>> >> >>> Hallo, >> >>> >> >>> oh, and I also now committed two more abstractions that Matt Barber >> >>> sent me offlist, of which one is a sorting abstraction as well. Matt's >> >>> [list-shellsort] uses the Shell sorting algorithm: >> >>> http://en.wikipedia.org/wiki/Shell_sort which generally is a bit >> >>> faster than insertion sort, but I didn't benchmark the two Pd >> >>> implementations (the speed in Pd of course also depends on how much >> >>> element shuffling and list-dripping is needed) >> >>> >> >>> Anyway, currently list-shellsort only does ascending sorting, so I >> >>> just decided to include both Michal's list-sort, which probably is >> >>> easier to understand, and Matt's list-shellsort in the current SVN's >> >>> [list]-abs collection. Choose your poison. ;) >> >>> >> >>> Ciao >> >>> -- >> >>> Frank >> >>> >> >>> Michal Seta hat gesagt: // Michal Seta wrote: >> >>> >> Hi all, >> >> It is amazing how we take things for granted. Most programming >> languages provide some sort of list sorting function/method. >> Surprisingly (or not) pd does not (or my search skills are null, or I >> am not bleeding edge enough). I needed a solution that works with a >> vanilla pd. >> >> I was almost going to do the academia move and announce a pd exam, >> and >> have little pd-bees come up with a solution but I needed it *now* >> else >> >>>
Re: [PD] list-sort
Matt Barber wrote: > >So instead, actually implement it in an array and sort it in place! > >Very fast. > (Of course it works for lists of numbers only). It would be even faster to have coded externals that operate on tables like that. I have made one, [mrpeach/tabfind], that gives the nth index of a number or list of numbers found in a table. This follows Miller's suggestion that tables are the right way to manipulate strings without adding them to the symbol table. An external that sorted a table in place would be very fast. Martin > >On Tue, Dec 2, 2008 at 10:16 PM, Matt Barber <[EMAIL PROTECTED]> wrote: > > Also, I find it extremely tempting to think of a list of numbers as an > > array[ ], but this analogy won't hold because you can't operate on the > > list in-place -- I'm sure a lot of the overhead is in feeding entire > > lists back and forth and around to the different parts of the patches. > > Maybe the algorithm with the fewest total [list] operations sometimes > > wins out over the algorithm that's in general more efficient. > > > > Matt > > > > > > > > On Tue, Dec 2, 2008 at 10:01 PM, Matt Barber <[EMAIL PROTECTED]> >wrote: > >> For what it's worth, > >> > >> I just ran one possible benchmark on the [list-*sort] abstractions > >> submitted recently, using [list-random] and [realtime]. > >> > >> I think overall the overhead for [list-sort] is much less than for > >> [list-shellsort] -- for short lists (<100) it takes about half the > >> time. [list-shellsort] is a bit quicker when the variance of the > >> elements is smaller (which makes sense because the more alike the > >> elements are the less the innermost loop will have to run) -- but > >> [list-sort] still beats it. I have a feeling that some of the > >> overhead in [list-shellsort] is in the [list-swap] function and other > >> list-abs objects, which are a little too feature-rich and/or > >> idiot-proof for this particular use. =o) > >> > >> > >> However, after some trial and error with [list-sort] I found I am > >> unable to sort a list of more than exactly 121 elements without > >> freezing Pd -- 122 and up will freeze it. This is because the main > >> loop is not controlled with an [until] -- I think you can see the > >> structure of [list-drip] for similar reasoning (the [until] is not > >> "needed" logically, but helps with long lists to do it in steps). > >> After implementing the [until] loop, I found that [list-sort] is even > >> quicker than before, but the efficiency of the [list-shellsort] > >> algorithm take over for list sizes >450 -- above that [list-shellsort] > >> is substantially quicker (and quicker yet if the variance is low). It > >> beats [list-sort] by half for a list about 1300-1400 elements long or > >> so (but not within reason -- it still takes about 2 seconds!). > >> > >> > >> I attached the new [list-sort] and the goofy little diagnostic. > >> > >> Matt > >> > >> > >>> Date: Tue, 2 Dec 2008 13:59:08 +0100 > >>> From: Frank Barknecht <[EMAIL PROTECTED]> > >>> Subject: Re: [PD] list-sort > >>> To: pd-list@iem.at > >>> Message-ID: <[EMAIL PROTECTED]> > >>> Content-Type: text/plain; charset="us-ascii" > >>> > >>> Hallo, > >>> > >>> oh, and I also now committed two more abstractions that Matt Barber > >>> sent me offlist, of which one is a sorting abstraction as well. Matt's > >>> [list-shellsort] uses the Shell sorting algorithm: > >>> http://en.wikipedia.org/wiki/Shell_sort which generally is a bit > >>> faster than insertion sort, but I didn't benchmark the two Pd > >>> implementations (the speed in Pd of course also depends on how much > >>> element shuffling and list-dripping is needed) > >>> > >>> Anyway, currently list-shellsort only does ascending sorting, so I > >>> just decided to include both Michal's list-sort, which probably is > >>> easier to understand, and Matt's list-shellsort in the current SVN's > >>> [list]-abs collection. Choose your poison. ;) > >>> > >>> Ciao > >>> -- > >>> Frank > >>> > >>> Michal Seta hat gesagt: // Michal Seta wrote: > >>> > Hi all, > > It is amazing how we take things for granted. Most programming > languages provide some sort of list sorting function/method. > Surprisingly (or not) pd does not (or my search skills are null, or I > am not bleeding edge enough). I needed a solution that works with a > vanilla pd. > > I was almost going to do the academia move and announce a pd exam, >and > have little pd-bees come up with a solution but I needed it *now* >else > I would not sleep or have terrible nightmares. So here it is. Thank > heavens (but give your offerings to fbar's footils shrine) for > list-abs. > > Busy pd-bees, should you care to improve on my solution, please be my > guest, I am sure there are better ways of accomplishing this trivial > task. In any case, go forth and sort the world around (or within) > you. > > ./MiS > >> > > ><< li
Re: [PD] gem pix_texture crashes PD
altern wrote: > hi > > the machine has a special graphic card, it is a matrox Parhelia LX, from > matrox millenium P-Series. I think it is used for stereoscopy or > something like that. Could it be that graphics card and Gem do no like > each other? possible but who knows... it would be interesting to: get a logfile of what Pd has to say before it crashes. (something like: "pd.com -stderr -lib Gem 2>bla.log") also the output of "glewinfo.exe" [1] could help. finally: could it be the [pix_image] object or is it definitely the [pix_texture] object? fgmadsr IOhannes [1] http://glew.sourceforge.net/ ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Re: [PD] list-sort
So instead, actually implement it in an array and sort it in place! Very fast. On Tue, Dec 2, 2008 at 10:16 PM, Matt Barber <[EMAIL PROTECTED]> wrote: > Also, I find it extremely tempting to think of a list of numbers as an > array[ ], but this analogy won't hold because you can't operate on the > list in-place -- I'm sure a lot of the overhead is in feeding entire > lists back and forth and around to the different parts of the patches. > Maybe the algorithm with the fewest total [list] operations sometimes > wins out over the algorithm that's in general more efficient. > > Matt > > > > On Tue, Dec 2, 2008 at 10:01 PM, Matt Barber <[EMAIL PROTECTED]> wrote: >> For what it's worth, >> >> I just ran one possible benchmark on the [list-*sort] abstractions >> submitted recently, using [list-random] and [realtime]. >> >> I think overall the overhead for [list-sort] is much less than for >> [list-shellsort] -- for short lists (<100) it takes about half the >> time. [list-shellsort] is a bit quicker when the variance of the >> elements is smaller (which makes sense because the more alike the >> elements are the less the innermost loop will have to run) -- but >> [list-sort] still beats it. I have a feeling that some of the >> overhead in [list-shellsort] is in the [list-swap] function and other >> list-abs objects, which are a little too feature-rich and/or >> idiot-proof for this particular use. =o) >> >> >> However, after some trial and error with [list-sort] I found I am >> unable to sort a list of more than exactly 121 elements without >> freezing Pd -- 122 and up will freeze it. This is because the main >> loop is not controlled with an [until] -- I think you can see the >> structure of [list-drip] for similar reasoning (the [until] is not >> "needed" logically, but helps with long lists to do it in steps). >> After implementing the [until] loop, I found that [list-sort] is even >> quicker than before, but the efficiency of the [list-shellsort] >> algorithm take over for list sizes >450 -- above that [list-shellsort] >> is substantially quicker (and quicker yet if the variance is low). It >> beats [list-sort] by half for a list about 1300-1400 elements long or >> so (but not within reason -- it still takes about 2 seconds!). >> >> >> I attached the new [list-sort] and the goofy little diagnostic. >> >> Matt >> >> >>> Date: Tue, 2 Dec 2008 13:59:08 +0100 >>> From: Frank Barknecht <[EMAIL PROTECTED]> >>> Subject: Re: [PD] list-sort >>> To: pd-list@iem.at >>> Message-ID: <[EMAIL PROTECTED]> >>> Content-Type: text/plain; charset="us-ascii" >>> >>> Hallo, >>> >>> oh, and I also now committed two more abstractions that Matt Barber >>> sent me offlist, of which one is a sorting abstraction as well. Matt's >>> [list-shellsort] uses the Shell sorting algorithm: >>> http://en.wikipedia.org/wiki/Shell_sort which generally is a bit >>> faster than insertion sort, but I didn't benchmark the two Pd >>> implementations (the speed in Pd of course also depends on how much >>> element shuffling and list-dripping is needed) >>> >>> Anyway, currently list-shellsort only does ascending sorting, so I >>> just decided to include both Michal's list-sort, which probably is >>> easier to understand, and Matt's list-shellsort in the current SVN's >>> [list]-abs collection. Choose your poison. ;) >>> >>> Ciao >>> -- >>> Frank >>> >>> Michal Seta hat gesagt: // Michal Seta wrote: >>> Hi all, It is amazing how we take things for granted. Most programming languages provide some sort of list sorting function/method. Surprisingly (or not) pd does not (or my search skills are null, or I am not bleeding edge enough). I needed a solution that works with a vanilla pd. I was almost going to do the academia move and announce a pd exam, and have little pd-bees come up with a solution but I needed it *now* else I would not sleep or have terrible nightmares. So here it is. Thank heavens (but give your offerings to fbar's footils shrine) for list-abs. Busy pd-bees, should you care to improve on my solution, please be my guest, I am sure there are better ways of accomplishing this trivial task. In any case, go forth and sort the world around (or within) you. ./MiS >> > #N canvas 917 330 453 562 10; #X obj 26 -25 inlet; #X obj 45 379 outlet; #N canvas 416 392 593 257 \$0-gap-loop 0; #X obj 137 66 / 2; #X obj 137 89 int; #X obj 34 122 until; #X obj 34 49 t b f; #X obj 189 105 sel 0; #X obj 137 142 t f f; #X obj 59 159 f; #X obj 34 26 inlet; #X obj 59 213 outlet; #X text 91 22 Start with a gap of floor(n/2) \, continue to decrease gap by powers of 1/2.; #X obj 59 181 t f f; #X text 118 182 <== order doesn't matter here \, but we force each iteration of this loop to finish before going on to the next... this seems to save time.; #X connect 0 0 1 0; #X connect 1 0 5 0; #X connect 2 0 6 0; #X connect 3 0 2 0; #X connect 3 1 0 0; #X connect 4 0
Re: [PD] svn:externals WAS: an easy way to replay a Pd-session (gui)
Hans-Christoph Steiner wrote: > On Dec 2, 2008, at 6:36 AM, Chris McCormick wrote: >>> is there any chance to sync the two repositories? >>> (personally i would still suggest an svn:externals link; but let's >>> keep >>> this for later :-)) sorry for re-starting the flame-war. it was not my intention but couldn't keep my mouth shut. > I really don't want to dictate here, but I think we need to decide on > how we use the SVN. svn:externals create more annoying work in > regards to getting Pd-extended builds out, but that is not the only > use of the SVN. I can accept more annoying work, but there needs to > be a good reason. > > My question remains, what is the problem we are trying to solve using > svn:externals? If it is to include code that gets built with Pd- > extended, then svn:externals doesn't work well for that, just > importing releases works much better. this is the main point where i disagree. most Pd-libraries seem to have stopped doing a regular release-cycle. for those included in Pd-extended, this is most likely due to their inclusion in Pd-extended. other libraries do not have a release cycle too, esp. if they are under some kind of public avaible version control system. the reason remains unknown, but i guess for most of these their upstream author consider release cycles for a "minor" library to much of a hazzle. i totally understand e.g. chris, if he doesn't want to re-import a new version of s-abstractions just because he has added 2 objects. (this is jut my interpretation) but nevertheless: s-abstractions are in our svn, chris pointed me to s-totalrecall.pd which i thought (rightfully) to be part of s-abstractions (without having ever had a look at this library), i checked whether this lib is in my checkout of the repo (which it is) and i couldn't find the very object. assuming that chris hadn't made fun of me, i checked the logfiles of s-abstractions and noted that there was only a initial submit. i decided to search for the library on other places (using google) and eventually found the upstream repository. i think such "workflow" does more harm than not. > I think it's time to have a IRC meeting about this. How about > Thursday? I am trying to be in #dataflow as much as possible these > days, if anyone wants to have an impromptu discussion. i'm at piksel right now, so i will not be able to attend any meeting in this week, > mfga.r IOhannes ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Re: [PD] beginnings of 'framesync' library
patrick wrote: > hi hans, > > i know almost nothing about pd svn, but i was looking at framesync and > there is no external (.pd_linux, .pd_darwin, .dll). no generated file (e.g. binaries which are generated by compiling source-code) should ever be under version control. > should it be in > abstractions instead? > i think on the long run all ./abstractions should be moved to ./externals i did not do it yet because i haven't taken the time yet, to ask the relevant authors whether this would be fine for them. fgmadr IOhannes ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
[PD] gem pix_texture crashes PD
hi i was testing a gem patch on a computer from a university i am giving a workshop, this is supposed to be a good machine for graphics. When i import a texture and open the gem window it crashes inmediately. The machine is running win XP with latest PD 0.40.3 extended. i used the Gem's pix_texture help patch to try different settings with "quality" and "mode" also tried different images. Same problem always. I run pd from console and it did not print any error message at all, just quits. the machine has a special graphic card, it is a matrox Parhelia LX, from matrox millenium P-Series. I think it is used for stereoscopy or something like that. Could it be that graphics card and Gem do no like each other? Ah, I tried with two different machines with same card, same problem in both. thanks enrike ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Re: [PD] Peripheral USB devices
I think you can see [hid] to start. ++ Jack Le 3 déc. 08 à 16:07, Andrew Faraday a écrit : Okay, this is probably quite basic. But I want to use signals from unrelated USB devices (such as the controllers for the PS2 game buzz) to control PD. How would I go about recognising these devices and logging commands from them? Take your friends with you with Mobile Messenger. Click Here! ___ 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] Peripheral USB devices
[hid] is the usual route. There's a good help file for it. Plug in your controller and do lsusb at the command line. You will probably see the name listed. In the [hid] help patch, advance the [open( message until you see it appear in the Pd console. Set the poll to 20ms and you should see buttons and joysticks cause some output in Pd. On Wed, 3 Dec 2008 15:07:42 + Andrew Faraday <[EMAIL PROTECTED]> wrote: > > Okay, this is probably quite basic. But I want to use signals from unrelated > USB devices (such as the controllers for the PS2 game buzz) to control PD. > How would I go about recognising these devices and logging commands from them? > > _ > Are you a PC? Upload your PC story and show the world > http://clk.atdmt.com/UKM/go/122465942/direct/01/ -- Use the source ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
[PD] Peripheral USB devices
Okay, this is probably quite basic. But I want to use signals from unrelated USB devices (such as the controllers for the PS2 game buzz) to control PD. How would I go about recognising these devices and logging commands from them? _ Are you a PC? Upload your PC story and show the world http://clk.atdmt.com/UKM/go/122465942/direct/01/___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Re: [PD] Peak envelope follower?
[pvu~] from iemlib1 or iemlib in pd-extended. cheers, Thomas Musil Zitat von "Bill Gribble" <[EMAIL PROTECTED]>: > Is there a way within pd-extended to do the equivalent of [env~], but > following peak value rather than RMS? > > I have pulled my hair out trying to implement this with patching but I > have had no luck. > > Thanks, > Bill Gribble > > > > > ___ > Pd-list@iem.at mailing list > UNSUBSCRIBE and account-management -> > http://lists.puredata.info/listinfo/pd-list > > This message was sent using IMP, the Internet Messaging Program. ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Re: [PD] Anyone using Lua also using other Lua extentions?
Hi Mike, Frank, all, Frank Barknecht wrote: > Hallo, > Mike McGonagle hat gesagt: // Mike McGonagle wrote: > >> I have been wondering about what I would need to do to use other Lua >> extentions along with [lua]? Is it just a matter of compiling those >> linked libraries, and then doing a require "my-extention'' in the >> code? Does anything in the C portions of PdLua need to be recompiled? > > Lua itself can be compiled with or without the capabilty to load other > modules. Generally it is compiled with a default of enabling modules, so > you will be fine. > > Other than that it's only a matter of letting pdlua find the modules. > It's fine if you install your modules globally, i.e. in /usr/lib/lua. To > be able to load modules in the current patch's directory, on older Pd > versions some fiddling with the Lua search path may be needed (search > the archives). On newer Pds (I think starting with 0.40 or 0.41) pdlua > can add the current directory to the search path itself. > > After all that it's indeed just a simple: require"Box2D" or so. I haven't tested this in depth - so I'm not sure if it works so easily - I remember there are two search paths in Lua, one for .lua files and one for compiled files, and I can't remember right now if I added support for the compiled file path (I have a hunch that I didn't, because I wasn't sure how to get it to work cleanly with the .so vs .dll file name stuff...). I also can't remember if I added the require path hooks for plain .lua packages to both the Lua loader and the [luax] object. So, it might require (sorry for the pun..) some fiddling to get it to work, maybe modifications/recompilation of the C part of pdlua, etc - patches welcome, but I'll get around to testing it thoroughly soon, and probably rewrite that part of the code completely (if I remember correctly I used Lua's C api when using Lua scripting would be easier to maintain...). Expect a new release of pdlua when I'm confident that the require stuff is all working satisfactorily. > Ciao Thanks, Claude -- http://claudiusmaximus.goto10.org ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Re: [PD] Open alternative to RJDJ?
Derek Holzer wrote: > hi Derek, the long-term plan with RjDj is to take it on to other platforms, both open and closed. the iPhone was chosen as an initial platform for a number of reasons, one of the strongest being a built-in 12-million user market, its position as the strongest selling smartphone in the US at least, and a clearly defined, efficient, and effective application distribution system. but by no means is the system to be closed and restricted. most of the developers are as unhappy with Apple about their closed-ness as anyone else here might be, and the plan is certainly to take it to more open platforms. what's more, it is possible for anyone with a non-jailbroken iPhone to install their own homebrew scenes onto the phone. due to Apple's draconian content controls and restrictions, at the moment it's not possible to directly transfer scenes from your computer to the phone, so you need to be able to host them on a website somewhere, but if this is done you can simply provide an rjdj:// url (eg rjdj://www.mysite.com/scenes/blahlbah.rj), and by browsing to this url in the iPhone's web browser you can install any scene you want. > 1) Can RJDJ "scenes" run on other platforms (Palm, iPaq, Gumstix, Linux > iPod, whatever?) since an RjDj 'scene' is nothing more than a straightforward Pd patch (with a few abstractions and externals to handle playback control and basic audio analysis), and since the RjDj application itself is nothing more than pdlib with a scene-selection GUI, then yes, RjDj 'scenes' will run on any hardware that can run Pd. > 2) Is anyone working on an RJDJ-like/compatible platform which is > actually open and accessible? at the moment, there is nothing that i know of. as i mentioned, though, the plan for RjDj is to port the application to other platforms, at which time the player code for these new platforms (especially for open platforms like the OpenMoko) will be released under the GPL. releasing the iPhone codebase under the GPL is also planned, but this step is still in the future. > I will drop by the Berlin RJDJ sprint with these kind of questions in > mind in case anyone wants to discuss them in person. please do, i'm sure Michael will be more than happy to talk about it. cheers d -- damian stewart | skype: damiansnz | [EMAIL PROTECTED] frey | live art with machines | http://www.frey.co.nz ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
[PD] Fwd: probability table ?
sorry, this was not intended to go to you privately, but to the list. could resolve one issue. list-wrandom and list-random load fine in pd 0.39.3-extended after adding them to the extra folder (they were missing before). but they weren't missing in the pd 0.40.3 version. i can't get this version to load any other externals. after startup i get "creb: can't load library cxc: can't load library iemlib: can't load library list-abs: can't load library mapping: can't load library markex: can't load library maxlib: can't load library ..." so one question remains: isn't the package contents automatically part of pd's search path? if not, how can i change the search path, as with the pd preferences menu i can't seem to navigate inside an application folder? well, actually pd seems to find the libraries, but it can't load them... what could cause this error? thanks for any pointers. volker. Begin forwarded message: > From: volker böhm <[EMAIL PROTECTED]> > Date: Wed 3 Dec 2008 13:16:58 GMT+01:00 > To: Frank Barknecht <[EMAIL PROTECTED]> > Subject: Re: [PD] probability table ? > > > On 02 Dec 2008, at 18:25, Frank Barknecht wrote: >> Hallo, >> volker b?hm hat gesagt: // volker b?hm wrote: >> >>> i'm looking again for a max equivalent in pd. >>> when sending a bang to a table object in max you can use it as a >>> probability table*. >>> >>> is there something similar in pd? >> >> [list-wrandom] from the [list]-abs collection is similar. >> >> Use [list-tabdump] or Zexy's [tabdump] to get the values from a table >> into a list to feed into [list-wrandom]. >> > > thanks, frank, that's what i'm looking for. > > but i ran into some strange filepath issue again on my computer > (osx 10.4.11, pd 0.39.3-extended). > i can't instantiate the list-wrandom abstraction, although it's > sitting in the right place (inside the pd package in resources/ > extra/list-abs) > funny thing is, i can load all the other list-abs, but not list- > random and list-wrandom. > > why would that be? > isn't the package contents automatically part of pd's search path? > if not, how can i change the search path, as with the pd > preferences menu i can't seem to navigate inside an application > folder? > > if i copy the abstraction with its helpfile to some folder and load > the help file, pd finds and loads the abstraction. > so the current folder is part of the search path. > > any help would be appreciated. > volker. > > ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
[PD] Open alternative to RJDJ?
I'm gathering information currently for a potential exhibition involving mobile sound devices for 2010. My criteria are as follows: 1) Gathering and processing of environmental sounds 2) Open source software and open and/or accessible hardware 3) Doesn't make only techno music! ;-) and optional: 4) User's location and/or movement become processing criteria 5) Ability to network with other devices to share sounds and information The RJDJ project sounds like it fits the first and fourth, I don't know about the others. I agree with several of the posters on this list who were suspicious of a project using free software but geared only towards expensive hardware like iPhones. But I don't want to totally discredit the momentum that's gone into this project. So my questions are: 1) Can RJDJ "scenes" run on other platforms (Palm, iPaq, Gumstix, Linux iPod, whatever?) 2) Is anyone working on an RJDJ-like/compatible platform which is actually open and accessible? I will drop by the Berlin RJDJ sprint with these kind of questions in mind in case anyone wants to discuss them in person. best! Derek -- derek holzer ::: http://www.umatic.nl ::: http://blog.myspace.com/macumbista ---Oblique Strategy # 160: "Towards the insignificant" ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
[PD] Gem: pix_write and pix_multiimage
it's a pity pix_write and pix_multiimage don't follow the same file naming paradigm. pix write makes image like this: image0.jpg to image9.jpg while pix_multiimage does: image0.jpg to image9.jpg stoptrick.pd Description: Binary data ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Re: [PD] [PD-announce] reware howto video
>> On Mon, Dec 1, 2008 at 6:54 PM, Hans-Christoph Steiner >> <[EMAIL PROTECTED]> wrote: >> >> old devices and run new software on them. We now have our first >> Reware HOWTO video, showing the basics of how to use a Reware image >> yourself, then it illustrates some of the Pd patches we've made: That's one well made demo video. Thanks for that. Insight on how it was recorded/edited would be cool. I'm guessing you recorded the screen(action/"cast") in parallel with the other video shot by a camera also recording the audio? But how did you get the syncing in the cuts so tight? ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Re: [PD] list-sort
Hallo, Matt Barber hat gesagt: // Matt Barber wrote: > [list-sort] still beats it. I have a feeling that some of the > overhead in [list-shellsort] is in the [list-swap] function and other > list-abs objects, which are a little too feature-rich and/or > idiot-proof for this particular use. =o) Attached is a variant of [list-idx] called [list-nth] that probably is a lot faster. It doesn't handle negative indices, however. It's based on modifying a message box to get the element by index, which should reduce the memory load with long lists. Ciao -- Frank BarknechtDo You RjDj.me? _ __footils.org__ list-nth-help.pd Description: application/puredata list-nth.pd Description: application/puredata ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Re: [PD] Anyone using Lua also using other Lua extentions?
Hallo, Mike McGonagle hat gesagt: // Mike McGonagle wrote: > I have been wondering about what I would need to do to use other Lua > extentions along with [lua]? Is it just a matter of compiling those > linked libraries, and then doing a require "my-extention'' in the > code? Does anything in the C portions of PdLua need to be recompiled? Lua itself can be compiled with or without the capabilty to load other modules. Generally it is compiled with a default of enabling modules, so you will be fine. Other than that it's only a matter of letting pdlua find the modules. It's fine if you install your modules globally, i.e. in /usr/lib/lua. To be able to load modules in the current patch's directory, on older Pd versions some fiddling with the Lua search path may be needed (search the archives). On newer Pds (I think starting with 0.40 or 0.41) pdlua can add the current directory to the search path itself. After all that it's indeed just a simple: require"Box2D" or so. Ciao -- Frank ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Re: [PD] Pd-list Digest, Vol 45, Issue 15
That is so cool, I will surely use it! Peaks at 45% on my 300MHz g3 ibook (ubuntu,) so 1-2% on a 21st century machine sounds reasonable. Message: 12 Date: Wed, 3 Dec 2008 01:38:38 +0900 From: "hard off" <[EMAIL PROTECTED]> Subject: Re: [PD] emulating an acoustic hi-hat pedal To: pd-list@iem.at Message-ID: <[EMAIL PROTECTED]> Content-Type: text/plain; charset="iso-8859-1" i just followed the basics from dan stowell's page, and built a reasonable sounding hihat in pd. it has 100 resonating bandpass filters connected, and so for some reason needs a couple of 'hits' until all those filters let it work properly. also needs a couple of hits to get things working right when changing between presets. pd's cpu meter tells me it's only using 1-2% here, but i am having trouble believing that. anyway, runs ok here. ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
