Re: [PD] Call for GSoC mentors! March 9th deadline!
Hallo! i added my name to two existing projects matching my competences. Just in case Georg is too busy with all the other ones he is part of. Yes of course, feel free to add you to the projects ! I think we should have at least two mentors for each project, at least for the application now. LG Georg ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] Call for GSoC mentors! March 9th deadline!
Hans-Christoph Steiner wrote: The Google Summer of Code ((http://code.google.com/soc/) application is due very soon, March 9th, and we need mentors! At this point, you just need to put down your name. Then once the projects are in, we'll choose projects and who will mentor them. Every pd developer who wants to support the project but is not student anymore is invited to join as mentor, since the number of sponsored projects by google depends on the number of mentors and students. Andy, Claude, Frank, Marius, Mathieu, Roman where are you guys? add your names, hurry! :) http://puredata.info/dev/summer-of-code/GSoCOrganizationApp2009 @both Chris's and Derek your names and gmail account are missing!! ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] Pd/GEM and camera for tracking
Hello David, Thanx for all this informations using an analogue camera. It's good to know there is FireWire extensions, but it is very expensive (245 pound sterling !). If i understand, the system is like this : Analogue camera with BNC - BNC baluns with power - cat 5 cable - composite baluns with power - composite to FireWire400 converter - FireWire400 to FireWire800 cable - MacMini - Pd/GEM ? I know that analogues cameras are good solutions, but with all this stuff, there is no risk of noise ? ;) (tell me if i'm wrong). ++` Jack Le 7 mars 09 à 06:18, David Kirkpatrick a écrit : Hi Jack, I've done a fair bit of this sort of thing before. The most useful setup i've found is: 1) Analogue monochrome CCTV camera. (Preferably with around 700 horizontal lines or so, very low lux, and self syncing) I use these. http://www.allthings.com.au/Catalogue/CCS/monochrome% 20low%20light%20cctv%20dsp%20video%20camera.html You can then buy a C or CS lens that is the right angle for your situation. For roof mounted stuff I use an ultra-wide angle varifocal set to just before it noticably fisheyes. 2) Cat 5 balun connected to CCTV camera's analogue video output and power input. This allows signal to be sent, and power to be recieved via a single cheap UTP Cat 5 lead (i've gone 30 metres with no noticable image quality loss, supposedly you can go much further). Removes the need to run a mains power lead or coax lead to the camera so setup is quick and easy, and reduces time spent dangling from ladders. You can get sets of cat 5 baluns really cheap on ebay. 3) Second cat 5 balun, on the other end of the cat 5 lead, placed next to computer. Connect to a suitable power supply for your video camera, and connect signal to a near zero latency industrial firewire capture device such as a DFG/1394-1e. http:// www.theimagingsource.com/en_US/products/converters/dfg13941e/ This allows you to hook up to a to a desktop or laptop, including a mac mini. Then you're done. Just set Pd to listen to the DFG/1394-1e. Image will be clean and roughly equivalent to 720x576 res. This setup can also be modified to work with near infra-red light instead of visible light if you want to avoid detecting lighting changes as movement. Just tape three squares of primary red and congo blue gel in front of the camera lens. Set up a few PAR56s to flood the space with light. Add the same gel to the 56's as you did to the camera and it will block almost all visible light. People will glow bright white when viewed through the camera, but most other stuff in the space will be close to invisible. Alternately, if you want to use a firewire board camera, you can get something like a Lindy CAT5 FireWire Extender. They aren't cheap but they extend the maximum length of a firewire run from around 5m to 70m without quality loss. Regards, David Kirkpatrick Find car news, reviews and more Looking to change your car this year? ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] Pd/GEM and camera for tracking
Hi Jack, Yep, your chain is right. A minor difference is that I use two BNC baluns (one with a BNC to composite adaptor attached), but it should make very little difference. I also used a UTP cat 6 cable instead of cat 5, but I used cat 5 baluns. I've used this chain in multiple theatrical projects without noise issues, even with moving lights messing up the ambient light levels. Obviously you would have a dodgy signal if you ran the UTP cat 5 or 6 alongside a 3 phase lead or something, but apart from that you should be fine. I had the cat 6 lead running through a lighting grid full of 240V and it didn't degrade. It actually seemed cleaner than doing everything with coaxial cable. David Kirkpatrick CC: pd-list@iem.at From: j...@rybn.org Subject: Re: [PD] Pd/GEM and camera for tracking Date: Sat, 7 Mar 2009 13:15:16 +0100 To: djk_1...@hotmail.com Hello David, Thanx for all this informations using an analogue camera. It's good to know there is FireWire extensions, but it is very expensive (245 pound sterling !). If i understand, the system is like this : Analogue camera with BNC - BNC baluns with power - cat 5 cable - composite baluns with power - composite to FireWire400 converter - FireWire400 to FireWire800 cable - MacMini - Pd/GEM ? I know that analogues cameras are good solutions, but with all this stuff, there is no risk of noise ? ;) (tell me if i'm wrong). ++` Jack Le 7 mars 09 à 06:18, David Kirkpatrick a écrit : Hi Jack, I've done a fair bit of this sort of thing before. The most useful setup i've found is: 1) Analogue monochrome CCTV camera. (Preferably with around 700 horizontal lines or so, very low lux, and self syncing) I use these. http://www.allthings.com.au/Catalogue/CCS/monochrome%20low%20light%20cctv%20dsp%20video%20camera.html You can then buy a C or CS lens that is the right angle for your situation. For roof mounted stuff I use an ultra-wide angle varifocal set to just before it noticably fisheyes. 2) Cat 5 balun connected to CCTV camera's analogue video output and power input. This allows signal to be sent, and power to be recieved via a single cheap UTP Cat 5 lead (i've gone 30 metres with no noticable image quality loss, supposedly you can go much further). Removes the need to run a mains power lead or coax lead to the camera so setup is quick and easy, and reduces time spent dangling from ladders. You can get sets of cat 5 baluns really cheap on ebay. 3) Second cat 5 balun, on the other end of the cat 5 lead, placed next to computer. Connect to a suitable power supply for your video camera, and connect signal to a near zero latency industrial firewire capture device such as a DFG/1394-1e. http://www.theimagingsource.com/en_US/products/converters/dfg13941e/ This allows you to hook up to a to a desktop or laptop, including a mac mini. Then you're done. Just set Pd to listen to the DFG/1394-1e. Image will be clean and roughly equivalent to 720x576 res. This setup can also be modified to work with near infra-red light instead of visible light if you want to avoid detecting lighting changes as movement. Just tape three squares of primary red and congo blue gel in front of the camera lens. Set up a few PAR56s to flood the space with light. Add the same gel to the 56's as you did to the camera and it will block almost all visible light. People will glow bright white when viewed through the camera, but most other stuff in the space will be close to invisible. Alternately, if you want to use a firewire board camera, you can get something like a Lindy CAT5 FireWire Extender. They aren't cheap but they extend the maximum length of a firewire run from around 5m to 70m without quality loss. Regards, David Kirkpatrick Find car news, reviews and more Looking to change your car this year? _ View photos of singles in your area. Click Here http://a.ninemsn.com.au/b.aspx?URL=http%3A%2F%2Fdating%2Eninemsn%2Ecom%2Eau%2Fchannel%2Findex%2Easpx%3Ftrackingid%3D1046247_t=773166080_r=Hotmail_Endtext_m=EXT ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] Call for GSoC mentors! March 9th deadline!
On Sat, 2009-03-07 at 11:26 +0100, Enrique Erne wrote: Hans-Christoph Steiner wrote: The Google Summer of Code ((http://code.google.com/soc/) application is due very soon, March 9th, and we need mentors! At this point, you just need to put down your name. Then once the projects are in, we'll choose projects and who will mentor them. Every pd developer who wants to support the project but is not student anymore is invited to join as mentor, since the number of sponsored projects by google depends on the number of mentors and students. Andy, Claude, Frank, Marius, Mathieu, Roman where are you guys? add your names, hurry! :) yo, i am happy to add my name, but i guess it only makes sense for me to take a mentorship of a project, that is about patching and not c coding. from what i have seen, there is only one project - undead - which seems to be about patching. derek holzer is already proposed as a mentor. does it make sense to propose more then one mentor for a project? roman ___ Telefonate ohne weitere Kosten vom PC zum PC: http://messenger.yahoo.de ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] Call for GSoC mentors! March 9th deadline!
Hi Roman, actually GEMVeeJay is also a patching project. But yes, either propose a new project (the more the better!!!) or sign up as proposed mentor for Undead or GEMVeeJay. Having spare mentor shouldn't be a problem, I think the idea was to have two possible mentors for each one... best, D. Roman Haefeli wrote: On Sat, 2009-03-07 at 11:26 +0100, Enrique Erne wrote: Hans-Christoph Steiner wrote: The Google Summer of Code ((http://code.google.com/soc/) application is due very soon, March 9th, and we need mentors! At this point, you just need to put down your name. Then once the projects are in, we'll choose projects and who will mentor them. Every pd developer who wants to support the project but is not student anymore is invited to join as mentor, since the number of sponsored projects by google depends on the number of mentors and students. Andy, Claude, Frank, Marius, Mathieu, Roman where are you guys? add your names, hurry! :) yo, i am happy to add my name, but i guess it only makes sense for me to take a mentorship of a project, that is about patching and not c coding. from what i have seen, there is only one project - undead - which seems to be about patching. derek holzer is already proposed as a mentor. does it make sense to propose more then one mentor for a project? roman ___ Telefonate ohne weitere Kosten vom PC zum PC: http://messenger.yahoo.de ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list -- derek holzer ::: http://www.umatic.nl ::: http://blog.myspace.com/macumbista ---Oblique Strategy # 109: Lost in useless territory ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] Pd/GEM and camera for tracking
Good ! Thanx a lot David. ++ Jack Le 7 mars 09 à 15:40, David Kirkpatrick a écrit : Hi Jack, Yep, your chain is right. A minor difference is that I use two BNC baluns (one with a BNC to composite adaptor attached), but it should make very little difference. I also used a UTP cat 6 cable instead of cat 5, but I used cat 5 baluns. I've used this chain in multiple theatrical projects without noise issues, even with moving lights messing up the ambient light levels. Obviously you would have a dodgy signal if you ran the UTP cat 5 or 6 alongside a 3 phase lead or something, but apart from that you should be fine. I had the cat 6 lead running through a lighting grid full of 240V and it didn't degrade. It actually seemed cleaner than doing everything with coaxial cable. David Kirkpatrick CC: pd-list@iem.at From: j...@rybn.org Subject: Re: [PD] Pd/GEM and camera for tracking Date: Sat, 7 Mar 2009 13:15:16 +0100 To: djk_1...@hotmail.com Hello David, Thanx for all this informations using an analogue camera. It's good to know there is FireWire extensions, but it is very expensive (245 pound sterling !). If i understand, the system is like this : Analogue camera with BNC - BNC baluns with power - cat 5 cable - composite baluns with power - composite to FireWire400 converter - FireWire400 to FireWire800 cable - MacMini - Pd/GEM ? I know that analogues cameras are good solutions, but with all this stuff, there is no risk of noise ? ;) (tell me if i'm wrong). ++` Jack Le 7 mars 09 à 06:18, David Kirkpatrick a écrit : Hi Jack, I've done a fair bit of this sort of thing before. The most useful setup i've found is: 1) Analogue monochrome CCTV camera. (Preferably with around 700 horizontal lines or so, very low lux, and self syncing) I use these. http://www.allthings.com.au/Catalogue/CCS/monochrome% 20low%20light%20cctv%20dsp%20video%20camera.html You can then buy a C or CS lens that is the right angle for your situation. For roof mounted stuff I use an ultra-wide angle varifocal set to just before it noticably fisheyes. 2) Cat 5 balun connected to CCTV camera's analogue video output and power input. This allows signal to be sent, and power to be recieved via a single cheap UTP Cat 5 lead (i've gone 30 metres with no noticable image quality loss, supposedly you can go much further). Removes the need to run a mains power lead or coax lead to the camera so setup is quick and easy, and reduces time spent dangling from ladders. You can get sets of cat 5 baluns really cheap on ebay. 3) Second cat 5 balun, on the other end of the cat 5 lead, placed next to computer. Connect to a suitable power supply for your video camera, and connect signal to a near zero latency industrial firewire capture device such as a DFG/1394-1e. http:// www.theimagingsource.com/en_US/products/converters/dfg13941e/ This allows you to hook up to a to a desktop or laptop, including a mac mini. Then you're done. Just set Pd to listen to the DFG/1394-1e. Image will be clean and roughly equivalent to 720x576 res. This setup can also be modified to work with near infra-red light instead of visible light if you want to avoid detecting lighting changes as movement. Just tape three squares of primary red and congo blue gel in front of the camera lens. Set up a few PAR56s to flood the space with light. Add the same gel to the 56's as you did to the camera and it will block almost all visible light. People will glow bright white when viewed through the camera, but most other stuff in the space will be close to invisible. Alternately, if you want to use a firewire board camera, you can get something like a Lindy CAT5 FireWire Extender. They aren't cheap but they extend the maximum length of a firewire run from around 5m to 70m without quality loss. Regards, David Kirkpatrick Find car news, reviews and more Looking to change your car this year? _ View photos of singles in your area. Click Here http://a.ninemsn.com.au/b.aspx?URL=http%3A%2F%2Fdating%2Eninemsn% 2Ecom%2Eau%2Fchannel%2Findex%2Easpx%3Ftrackingid% 3D1046247_t=773166080_r=Hotmail_Endtext_m=EXT ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] Call for GSoC mentors! March 9th deadline!
On Sat, 7 Mar 2009, Enrique Erne wrote: Andy, Claude, Frank, Marius, Mathieu, Roman where are you guys? Where should I be? add your names, hurry! :) Why should I add my name? _ _ __ ___ _ _ _ ... | 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] Call for GSoC mentors! March 9th deadline!
Enrique Erne wrote: Hans-Christoph Steiner wrote: The Google Summer of Code ((http://code.google.com/soc/) application is due very soon, March 9th, and we need mentors! At this point, you just need to put down your name. Then once the projects are in, we'll choose projects and who will mentor them. Every pd developer who wants to support the project but is not student anymore is invited to join as mentor, since the number of sponsored projects by google depends on the number of mentors and students. Andy, Claude, Frank, Marius, Mathieu, Roman where are you guys? I am over here, banging my head against the wall, because I am working on too many things at the same time... marius. add your names, hurry! :) http://puredata.info/dev/summer-of-code/GSoCOrganizationApp2009 @both Chris's and Derek your names and gmail account are missing!! ___ 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] Call for GSoC mentors! March 9th deadline!
Sorry for the silence, I am quite busy at the moment, but to explain the situation viz GSoC mentoring, Google unilaterally and without warning disabled my account. Attempts to contact Google to remedy this result in a cul-de-sac web form that refuses to accept the email I registered with. I would very much like to offer my help to mentor students on Pd projects, but I don't have time to bang my head against a wall of listless corporate ambivalence. If any students want help on Pd audio related matters, as per normal please don't hesitate to contact me at the usual address. On Sat, 7 Mar 2009 10:27:39 -0500 (EST) Mathieu Bouchard ma...@artengine.ca wrote: On Sat, 7 Mar 2009, Enrique Erne wrote: Andy, Claude, Frank, Marius, Mathieu, Roman where are you guys? Where should I be? add your names, hurry! :) Why should I add my name? _ _ __ ___ _ _ _ ... | Mathieu Bouchard - tél:+1.514.383.3801, Montréal, Québec -- Use the source ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] Call for GSoC mentors! March 9th deadline!
chris clepper wrote: My own suggestion for a GEM project would be to create a tutorial and accompanying manual that covers the basic operation. I was planning to do this for years now, adding to dereks FLOSS Documentation or just as a separate project. there are a lot of unsorted patches on my drive, but as someone mentioned in a response to this email, documentation is not part of GSoC... The other idea involves making the more advanced features like GLSL and framebuffer rendering easier to use. I started to port vade's old v001 last year, including abstractions to easily chain several shaders together. not finished yet because with relation to GLSL stuff, I think I am just too stupid to get it... marius. These are mainly documentation projects, but also have some Pd, and possible C++ coding as well. On Fri, Mar 6, 2009 at 11:43 AM, Derek Holzer de...@umatic.nl mailto:de...@umatic.nl wrote: That's great, let's see what happens ;-) d. chris clepper wrote: I added my name to the VeeJay project to advise on how the low level stuff affects performance and stability. I don't know if a project can have more than one mentor though. On Fri, Mar 6, 2009 at 6:31 AM, Derek Holzer de...@umatic.nl mailto:de...@umatic.nl mailto:de...@umatic.nl mailto:de...@umatic.nl wrote: Since I'm completely uninterested in touching anything C, C++, TclTk or otherwise related, I submitted two Pd patching projects which should be general enough to attract students, yet quite intensive to work on. Feedback welcome. http://puredata.info/dev/summer-of-code/Undead http://puredata.info/dev/summer-of-code/GEMVeeJay Anyone want to take up 2007's PluggoPd idea? best, D. -- derek holzer ::: http://www.umatic.nl ::: http://blog.myspace.com/macumbista ---Oblique Strategy # 194: Steal a solution. ___ Pd-list@iem.at mailto:Pd-list@iem.at mailto:Pd-list@iem.at mailto:Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list -- derek holzer ::: http://www.umatic.nl ::: http://blog.myspace.com/macumbista ---Oblique Strategy # 83: How would someone else do it? ___ 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] Call for GSoC mentors! March 9th deadline!
Mathieu Bouchard wrote: On Sat, 7 Mar 2009, Enrique Erne wrote: Andy, Claude, Frank, Marius, Mathieu, Roman where are you guys? Where should I be? add your names, hurry! :) Why should I add my name? you could be mentor for a project. how about LibPDEngine? :) ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] Call for GSoC mentors! March 9th deadline!
On Sat, 7 Mar 2009, Enrique Erne wrote: Mathieu Bouchard wrote: Why should I add my name? you could be mentor for a project. I mean, why should I be mentor for a project? how about LibPDEngine? :) That's not really related to anything I do. Well, I did a quick test of making and using libpd.so in DD, but I didn't have any real use for this in mind. _ _ __ ___ _ _ _ ... | 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
[PD] [PD-announce] Pd Demo @ Art and Code, CMU, Pittsburgh, PA March 7-9
This is quite last minute, so I am just emailed out about it now. At the Art And Code conference at CMU in Pittsburgh, PA, I'll be giving a talk about Pd on Sunday and a demo/workshop on Monday. You have to be registered for the talk part, but I think that the demo on monday is more or less open. http://artandcode.ning.com/ .hc Computer science is no more related to the computer than astronomy is related to the telescope. -Edsger Dykstra ___ Pd-announce mailing list pd-annou...@iem.at http://lists.puredata.info/listinfo/pd-announce ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] Call for GSoC mentors! March 9th deadline!
Mathieu Bouchard wrote: On Sat, 7 Mar 2009, Enrique Erne wrote: how about LibPDEngine? :) That's not really related to anything I do. Well, I did a quick test of making and using libpd.so in DD, but I didn't have any real use for this in mind. is there any reason why you shouldn't be a mentor for a project? it's easy to setup a gmail account :) what about MoreGUIs since that is kind of related to DD, isn't it? even though it has already 2 mentors... the more the better right? i just picked randomly a few names of people, who are pretty active on this list and have great knowledge. it seems a pretty opportunity to add a project of your choice and add yourself as a mentor. you can only win or not? eni ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] [PD-announce] Pd Demo @ Art and Code, CMU, Pittsburgh, PA March 7-9
Have fun there- say hello to Golan. Greg On Sat, Mar 7, 2009 at 11:18 AM, Hans-Christoph Steiner h...@eds.org wrote: This is quite last minute, so I am just emailed out about it now. At the Art And Code conference at CMU in Pittsburgh, PA, I'll be giving a talk about Pd on Sunday and a demo/workshop on Monday. You have to be registered for the talk part, but I think that the demo on monday is more or less open. http://artandcode.ning.com/ .hc Computer science is no more related to the computer than astronomy is related to the telescope. -Edsger Dykstra ___ Pd-announce mailing list pd-annou...@iem.at http://lists.puredata.info/listinfo/pd-announce ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
[PD] new [tcpserver] (was: pd and tcp: what to do against crashes?)
hi again a new stupid little problem occured. when working with [tcpserver], i usually identify the clients by their socket number and not by their client number; for two reasons: when a message is received or a new client connects, you can only know the socket number of it (since there is a dedicated socket outlet), but not the client id. the other reason is that socket numbers are persistent, while client numbers might change, if one or more clients disconnect or get disconnected. my problem is, that the new status outlet and also the method to set internal buffersize is based on the client number. it's not a that big problem, since whenever i sent a message to a socket number i will know the client number as well. but when receiving messages, you don't know which client it came from. i though about building a look-up table in order to look up a socket for its client number, but this is not very feasible, since the client id might not be valid anymore after one or more disconnects. what i want to say, that it is currently not handy to use the new features, because you are forced to work in both domains, client and socket, at the same time. personally, i would prefer if everything would be socket based and i think, if you want to change it, then better now than later. another solution (though uglier, imho) would be to implement an internal look-up: 'get_client_id socket' - [tcpserver] - 'client_id client' to the status outlet. what do you think? roman ___ Der frühe Vogel fängt den Wurm. Hier gelangen Sie zum neuen Yahoo! Mail: http://mail.yahoo.de ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] new [tcpserver] (was: pd and tcp: what to do against crashes?)
On Sat, 2009-03-07 at 19:54 +0100, Roman Haefeli wrote: hi again a new stupid little problem occured. when working with [tcpserver], i usually identify the clients by their socket number and not by their client number; for two reasons: when a message is received or a new client connects, you can only know the socket number of it (since there is a dedicated socket outlet), but not the client id. the other reason is that socket numbers are persistent, while client numbers might change, if one or more clients disconnect or get disconnected. my problem is, that the new status outlet and also the method to set internal buffersize is based on the client number. it's not a that big problem, since whenever i sent a message to a socket number i will know the client number as well. but when receiving messages, you don't know which client it came from. i though about building a look-up table in order to look up a socket for its client number, but this is not very feasible, since the client id might not be valid anymore after one or more disconnects. what i want to say, that it is currently not handy to use the new features, because you are forced to work in both domains, client and socket, at the same time. personally, i would prefer if everything would be socket based and i think, if you want to change it, then better now than later. another solution (though uglier, imho) would be to implement an internal look-up: 'get_client_id socket' - [tcpserver] - 'client_id client' to the status outlet. what do you think? i just found out, that there is already something as a look-up table: when i send 'client' or 'client client-id' to [tcpserver], i actually get all necessary information. sorry for the noise. roman ___ Telefonate ohne weitere Kosten vom PC zum PC: http://messenger.yahoo.de ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] new [tcpserver]
Roman Haefeli wrote: On Sat, 2009-03-07 at 19:54 +0100, Roman Haefeli wrote: hi again a new stupid little problem occured. when working with [tcpserver], i usually identify the clients by their socket number and not by their client number; for two reasons: when a message is received or a new client connects, you can only know the socket number of it (since there is a dedicated socket outlet), but not the client id. the other reason is that socket numbers are persistent, while client numbers might change, if one or more clients disconnect or get disconnected. my problem is, that the new status outlet and also the method to set internal buffersize is based on the client number. it's not a that big problem, since whenever i sent a message to a socket number i will know the client number as well. but when receiving messages, you don't know which client it came from. i though about building a look-up table in order to look up a socket for its client number, but this is not very feasible, since the client id might not be valid anymore after one or more disconnects. what i want to say, that it is currently not handy to use the new features, because you are forced to work in both domains, client and socket, at the same time. personally, i would prefer if everything would be socket based and i think, if you want to change it, then better now than later. another solution (though uglier, imho) would be to implement an internal look-up: 'get_client_id socket' - [tcpserver] - 'client_id client' to the status outlet. what do you think? i just found out, that there is already something as a look-up table: when i send 'client' or 'client client-id' to [tcpserver], i actually get all necessary information. sorry for the noise. That's ok, but I've noticed that socket numbers are always in the hundreds while client numbers count up from 1. It would be easy enough to add a bit of code so that if the first number in a [send( message didn't match a client, it would be interpreted as a socket. Do you ever get overlap with client numbers and socket numbers? Martin ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] new [tcpserver]
Martin Peach wrote: Roman Haefeli wrote: On Sat, 2009-03-07 at 19:54 +0100, Roman Haefeli wrote: hi again a new stupid little problem occured. when working with [tcpserver], i usually identify the clients by their socket number and not by their client number; for two reasons: when a message is received or a new client connects, you can only know the socket number of it (since there is a dedicated socket outlet), but not the client id. the other reason is that socket numbers are persistent, while client numbers might change, if one or more clients disconnect or get disconnected. my problem is, that the new status outlet and also the method to set internal buffersize is based on the client number. it's not a that big problem, since whenever i sent a message to a socket number i will know the client number as well. but when receiving messages, you don't know which client it came from. i though about building a look-up table in order to look up a socket for its client number, but this is not very feasible, since the client id might not be valid anymore after one or more disconnects. what i want to say, that it is currently not handy to use the new features, because you are forced to work in both domains, client and socket, at the same time. personally, i would prefer if everything would be socket based and i think, if you want to change it, then better now than later. another solution (though uglier, imho) would be to implement an internal look-up: 'get_client_id socket' - [tcpserver] - 'client_id client' to the status outlet. what do you think? i just found out, that there is already something as a look-up table: when i send 'client' or 'client client-id' to [tcpserver], i actually get all necessary information. sorry for the noise. That's ok, but I've noticed that socket numbers are always in the hundreds while client numbers count up from 1. It would be easy enough to add a bit of code so that if the first number in a [send( message didn't match a client, it would be interpreted as a socket. Do you ever get overlap with client numbers and socket numbers? Actually if you use a [send( with [tcpserver] the first number is the socket number. If you use a [client( message the first number is a client number. I guess I meant to say that when you send a message containing only floats the first number is supposed to be a socket number, but it could also be a client number if the clients are always under 100 and the sockets are over 100. Also the 'sent' output could easily give the socket as well as the client. Martin ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] new [tcpserver]
On Sat, 2009-03-07 at 14:30 -0500, Martin Peach wrote: Roman Haefeli wrote: On Sat, 2009-03-07 at 19:54 +0100, Roman Haefeli wrote: hi again a new stupid little problem occured. when working with [tcpserver], i usually identify the clients by their socket number and not by their client number; for two reasons: when a message is received or a new client connects, you can only know the socket number of it (since there is a dedicated socket outlet), but not the client id. the other reason is that socket numbers are persistent, while client numbers might change, if one or more clients disconnect or get disconnected. my problem is, that the new status outlet and also the method to set internal buffersize is based on the client number. it's not a that big problem, since whenever i sent a message to a socket number i will know the client number as well. but when receiving messages, you don't know which client it came from. i though about building a look-up table in order to look up a socket for its client number, but this is not very feasible, since the client id might not be valid anymore after one or more disconnects. what i want to say, that it is currently not handy to use the new features, because you are forced to work in both domains, client and socket, at the same time. personally, i would prefer if everything would be socket based and i think, if you want to change it, then better now than later. another solution (though uglier, imho) would be to implement an internal look-up: 'get_client_id socket' - [tcpserver] - 'client_id client' to the status outlet. what do you think? i just found out, that there is already something as a look-up table: when i send 'client' or 'client client-id' to [tcpserver], i actually get all necessary information. sorry for the noise. That's ok, but I've noticed that socket numbers are always in the hundreds while client numbers count up from 1. It would be easy enough to add a bit of code so that if the first number in a [send( message didn't match a client, it would be interpreted as a socket. Do you ever get overlap with client numbers and socket numbers? yes, i do. depending on the box, where the server runs, i get socket numbers starting from 4 (debian lenny) or 8 (ubuntu hardy), though on windows xp they seem to start at 432. roman ___ Telefonate ohne weitere Kosten vom PC zum PC: http://messenger.yahoo.de ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] Call for GSoC mentors! March 9th deadline!
On Sat, 7 Mar 2009, Enrique Erne wrote: what about MoreGUIs since that is kind of related to DD, isn't it? Due to the GUI API being used by that project proposal, no, it's probably less related to DD than most any other GSoC submission. I mean, it's negatively related, whereas other proposals are just neutral towards it. even though it has already 2 mentors... the more the better right? Well, after 2 applicants, it doesn't really matter. It's not like both are going to desist. Only one gets to be the mentor, in the end. it seems a pretty opportunity to add a project of your choice and add yourself as a mentor. you can only win or not? I have no idea what I could submit, that could be reasonably accepted and that could be reasonably completed by an unspecified student. So, what was the outcome of the previously accepted projects? Were the goals completed? How did it happen? I don't really recall reading about this. How do students get chosen? _ _ __ ___ _ _ _ ... | 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
[PD] I am the harbinger of crashing
Sigh, here's another : ) This seems to have something to do with my MPD24 drum pads... whenever they're connected and I enter the MIDI preferences of Pd, I get the attached crash. It also occurs if they're configured (via .pdrc or the plist) as a default device. This started occurring on the newest builds of Pd-E as well as on Pd-0.42-4. It does not occur of my build of 0.40.3-extended. Anyone have any ideas? Best Luke Process: pd [19061] Path: /Users/lukeiannini/Desktop/Pd-0.42-4.app/Contents/Resources/Scripts/../bin/pd Identifier: pd Version: ??? (???) Code Type: X86 (Native) Parent Process: Pd [19060] Date/Time: 2009-03-07 17:18:35.904 -0800 OS Version: Mac OS X 10.5.6 (9G55) Report Version: 6 Exception Type: EXC_BAD_ACCESS (SIGBUS) Exception Codes: KERN_PROTECTION_FAILURE at 0x Crashed Thread: 0 Thread 0 Crashed: 0 com.apple.CoreFoundation0x90502e33 __CFStrConvertBytesToUnicode + 51 1 com.apple.CoreFoundation0x904f5536 CFStringCompareWithOptionsAndLocale + 3542 2 com.apple.CoreFoundation0x904f6455 CFStringCompareWithOptions + 53 3 pd 0x000868fb EndpointName + 315 (pmmacosxcm.c:692) 4 pd 0x00086ae3 cm_get_full_endpoint_name + 227 (pmmacosxcm.c:757) 5 pd 0x00086e18 pm_macosxcm_init + 472 (pmmacosxcm.c:901) 6 pd 0x00087781 Pm_Initialize + 49 (portmidi.c:293) 7 pd 0x00087802 Pm_CountDevices + 18 (portmidi.c:139) 8 pd 0x00077a99 midi_getdevs + 41 (s_midi_pm.c:289) 9 pd 0x00050d2c glob_midi_properties + 92 (s_midi.c:670) 10 pd 0x0003e972 pd_typedmess + 1026 (m_class.c:748) 11 pd 0x000425f1 binbuf_eval + 1121 12 pd 0x0004a155 socketreceiver_read + 949 13 pd 0x000490b9 sys_domicrosleep + 409 14 pd 0x00046c1a m_mainloop + 490 (m_sched.c:511) 15 pd 0x00048e9b sys_main + 1803 16 pd 0x22e6 start + 54 Thread 1: 0 libSystem.B.dylib 0x92b1b1c6 mach_msg_trap + 10 1 libSystem.B.dylib 0x92b229bc mach_msg + 72 2 com.apple.CoreFoundation0x904d20ae CFRunLoopRunSpecific + 1790 3 com.apple.CoreFoundation0x904d2d34 CFRunLoopRun + 84 4 com.apple.DVCPROHDMuxer 0x003120fb AVS::DestroyAVCDeviceController(AVS::AVCDeviceController*) + 297 5 libSystem.B.dylib 0x92b4c095 _pthread_start + 321 6 libSystem.B.dylib 0x92b4bf52 thread_start + 34 Thread 2: 0 libSystem.B.dylib 0x92b1b20e semaphore_wait_signal_trap + 10 1 libSystem.B.dylib 0x92b4d206 _pthread_cond_wait + 1267 2 libSystem.B.dylib 0x92b92539 pthread_cond_wait + 48 3 com.grame.JackRouter0x004953f9 CAGuard::Wait() + 73 4 com.grame.JackRouter0x004a1779 HP_Device::ExecuteAllCommands() + 57 5 com.grame.JackRouter0x004999ee CommandThread::ThreadEntry(CommandThread*) + 30 6 com.grame.JackRouter0x00495f89 CAPThread::Entry(CAPThread*) + 121 7 libSystem.B.dylib 0x92b4c095 _pthread_start + 321 8 libSystem.B.dylib 0x92b4bf52 thread_start + 34 Thread 3: 0 libSystem.B.dylib 0x92b1b1c6 mach_msg_trap + 10 1 libSystem.B.dylib 0x92b229bc mach_msg + 72 2 com.apple.CoreFoundation0x904d20ae CFRunLoopRunSpecific + 1790 3 com.apple.CoreFoundation0x904d2cd8 CFRunLoopRunInMode + 88 4 com.apple.audio.CoreAudio 0x9231b5dc HALRunLoop::OwnThread(void*) + 160 5 com.apple.audio.CoreAudio 0x9231b464 CAPThread::Entry(CAPThread*) + 96 6 libSystem.B.dylib 0x92b4c095 _pthread_start + 321 7 libSystem.B.dylib 0x92b4bf52 thread_start + 34 Thread 4: 0 libSystem.B.dylib 0x92b1b226 semaphore_timedwait_signal_trap + 10 1 libSystem.B.dylib 0x92b4d1ef _pthread_cond_wait + 1244 2 libSystem.B.dylib 0x92b4ea73 pthread_cond_timedwait_relative_np + 47 3 com.apple.audio.CoreAudio 0x9232abc3 CAGuard::WaitFor(unsigned long long) + 213 4 com.apple.audio.CoreAudio 0x9232c77e CAGuard::WaitUntil(unsigned long long) + 70 5 com.apple.audio.CoreAudio 0x9232af23 HP_IOThread::WorkLoop() + 759 6 com.apple.audio.CoreAudio 0x9232ac27 HP_IOThread::ThreadEntry(HP_IOThread*) + 17 7 com.apple.audio.CoreAudio 0x9231b464 CAPThread::Entry(CAPThread*) + 96 8 libSystem.B.dylib
Re: [PD] Call for GSoC mentors! March 9th deadline!
ola, Well, after 2 applicants, it doesn't really matter. It's not like both are going to desist. Only one gets to be the mentor, in the end. hey you're almost as a bad as as me. i would say 'fuck off corporate google collaborating on censorship in china', and 'you're still in a mentor/students relationship model, wow, 18th century' oops, can i ask to noone to make pdp run on windows ? and to windows to run a bulldozer, thanks sevy ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] Call for GSoC mentors! March 9th deadline!
oh sorry, have to add we had a good laugh with alexei shulguin once saying 'Google is GOD' i find it more accurate now xiaoo, sevy ydego...@gmail.com wrote: ola, Well, after 2 applicants, it doesn't really matter. It's not like both are going to desist. Only one gets to be the mentor, in the end. hey you're almost as a bad as as me. i would say 'fuck off corporate google collaborating on censorship in china', and 'you're still in a mentor/students relationship model, wow, 18th century' oops, can i ask to noone to make pdp run on windows ? and to windows to run a bulldozer, thanks sevy ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] Call for GSoC mentors! March 9th deadline!
On Sun, 8 Mar 2009, ydego...@gmail.com wrote: hey you're almost as a bad as as me. I didn't want any of your mail, I don't want any of your mail, and I won't want any of your mail. that's all. _ _ __ ___ _ _ _ ... | 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] Call for GSoC mentors! March 9th deadline!
sorry, the subject of the mail was : 'why should i collaborate with google?' not : 'why should i speak to señor bouchard?' right? ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
