Re: [PD] pd-extended font paths
Oh, Gem, of course. So when I'm not using Gem, I can safely do without those eight path elements, then? Also, while I'm being a whinging pest...it's impossible to add a path element that lives inside the pd-extended.app folder using the path dialog. This is because OS X makes the .app package not look like a folder, I suppose, but it's unfortunate nevertheless. Off to edit the .plist, I go. Thanks, Hans. Phil Hans-Christoph Steiner wrote: Well, it makes it easier to find fonts. That's the reason. I suppose most people aren't using fonts much with Pd. If [declare -path] works for Gem fonts, then I would consider removing some from the default prefs. .hc On Mar 26, 2009, at 9:23 PM, Phil Stone wrote: Do there really need to be eight different font-related entries in the path list for Pd-extended on OS X? If so, why? Phil ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list Computer science is no more related to the computer than astronomy is related to the telescope. -Edsger Dykstra ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] agenda for upcoming book sprint?[GEM sprint]
that's where the joke is, that floss manuals cover software that should also run on windows yes, you've always been a joker man, you know that xiaoo, sevy Derek Holzer wrote: Hi guys, As the facilitator of this project, I will post a list of sprint targets quite soon. GEM section is definitely on my list, however I do want to keep to things which are both included in PD-Extended and are cross platform. For now, this excludes PDP and Gridflow. Maybe if someone wanted to make a separate section which includes installation/configuration info (following the template in the Install chapters of the existing Pd FLOSS Manual), then a section on one of these might be relevant. But as they are both essentially Linux only, by virtue of either being uncompilable or nearly unusable on other platforms, I'd rather keep focus someplace else. As for GEM, I'd like to see some stuff on the following (in order of priority): 1) Basic VJ mixer (2 x [gemhead]-[pix_film]-[alpha]-[colorRGB]-[pix_texture]-[rectangle] with an alpha-crossfader)(+ platform specific codec info) 2) Live camera input (same as VJ mixer but with [pix_video], with platform specific info on USB/firewire inputs--what works what doesn't) 3) VJ effects (using the various pix objects) 4) Basic 3D (that actually does something interesting, rather than just show a sphere or a cube) 5) Basic movement tracking w/ [pix_blob] 6) GEM/video optimization/troubleshooting tips (see Troubleshooting section of existing Pd FLOSS Manual)(Chris Clepper, are you in the house?) I have some tutorial patches which could be used as the basis for most of this, let me know if you are interested. Full target list coming soon, I'll make sure to include this GEM section. best, Derek marius schebella wrote: Hans-Christoph Steiner wrote: Hey all, I hope I am not jumping the gun or stepping on anyone's toes. I just wanted to open up the discussion about what people are planning on working on during the upcoming book sprint. Currently, I am pretty open to topics, but I was thinking that Gem/PDP/Gridflow could really use a section. There are lots of examples for them, but they lack a good intro to the concepts. I am in for a gem sprint. marius. ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] pd-extended font paths
Well, it makes it easier to find fonts. That's the reason. I suppose most people aren't using fonts much with Pd. If [declare -path] works for Gem fonts, then I would consider removing some from the default prefs. .hc On Mar 26, 2009, at 9:23 PM, Phil Stone wrote: Do there really need to be eight different font-related entries in the path list for Pd-extended on OS X? If so, why? Phil ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list Computer science is no more related to the computer than astronomy is related to the telescope. -Edsger Dykstra ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] Delay effect without clicks
I think what you are talking about is zipper noise --- when you change the value sent to [vd~] what you are hearing is a discontinuity in the audio caused by the discontinuity between the new value and the previous value sent to [vd~]. Smooth your trip between the values with [line~]. Try something like this: delaytime | [$1 100( | [line~] | [vd~ testname] Play with the 2nd parameter in the message sent to line (shown as 100 above). I don't know how much doppler effect you are going to want to replace your clicks. -John Bjørn Nielsen wrote: Hey Marius Thanks for the quick reply. I have now tried vd~, but I still encounter clicks noises when I change delay time. audiosignal | [delwrite testname 2000] delaytime | [sig~] | [vd~ testname] | audioout+back to delwrite Do the click noises has something to do with the samplelength in delwrite~? (and can it at all be changed on the fly?) /Bjørn On Fri, Mar 27, 2009 at 00:13, marius schebella marius.schebe...@gmail.com wrote: hi Bjørn, maybe vd~ (variable delay) is what you're looking for? marius. Bjørn Nielsen wrote: Hey PD list This is my first mail to the list and I am a newbie in PD, so please bear with me. I am trying to make a patch that simulates the delay effects I use as a stompbox for my guitar. I.e. a signal delay line, with a parameter of feedback and a parameter of delay time. While changing the delay time parameter the ongoing sampled part should change pitch. My first attempt (as in the attached patch) is to use delread~/delwrite~, but changing the lenght of the sampled part in delread~ makes a lot of clicks noises (which can be fun, but not what I intended) and it do not change pitch. My max/msp friend said I should instead of clipping the sample, make it run faster. So I tried to figure if that was possible with delread~, vd~ or using arrays instead with tabread(4)~, but I have not found the golden key yet. I would be very happy if somebody could lead me in right direction. Thanks, Bjørn ___ 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 -- John Harrison http://alumni.media.mit.edu/~harrison ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] Delay effect without clicks
Thanks Marius, Frank John I got rid of the click noises now by doing this [numberbox\ | [pack $f1 50] | [line~] | [vd~ testreadname] But the pitch shifting it does while changing delay time is quite weird, so I think I will look into Franks example of doing this. / Bjørn On Fri, Mar 27, 2009 at 07:08, marius schebella marius.schebe...@gmail.com wrote: hi again, vd~ allows you to be controlled via a dsp signal (as opposed to a message inlet which only gets updated every 1,6 ms or so) and thus allows you to smoothly change the delay time. but you have to do do an interpolation between the messages you are feeding into it, and the best way to do this is with [line~]. [numberbox\ | [line $1 100( | [vd~ del] marius. Bjørn Nielsen wrote: Hey Marius Thanks for the quick reply. I have now tried vd~, but I still encounter clicks noises when I change delay time. audiosignal | [delwrite testname 2000] delaytime | [sig~] | [vd~ testname] | audioout+back to delwrite Do the click noises has something to do with the samplelength in delwrite~? (and can it at all be changed on the fly?) /Bjørn On Fri, Mar 27, 2009 at 00:13, marius schebella marius.schebe...@gmail.com wrote: hi Bjørn, maybe vd~ (variable delay) is what you're looking for? marius. Bjørn Nielsen wrote: Hey PD list This is my first mail to the list and I am a newbie in PD, so please bear with me. I am trying to make a patch that simulates the delay effects I use as a stompbox for my guitar. I.e. a signal delay line, with a parameter of feedback and a parameter of delay time. While changing the delay time parameter the ongoing sampled part should change pitch. My first attempt (as in the attached patch) is to use delread~/delwrite~, but changing the lenght of the sampled part in delread~ makes a lot of clicks noises (which can be fun, but not what I intended) and it do not change pitch. My max/msp friend said I should instead of clipping the sample, make it run faster. So I tried to figure if that was possible with delread~, vd~ or using arrays instead with tabread(4)~, but I have not found the golden key yet. I would be very happy if somebody could lead me in right direction. Thanks, Bjørn ___ 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] Purple/Green Flickering With GEM
I don't know the details, but I remember hearing its related to buggy video card drivers. Things that work fine on some cards cause this on others. Check the archives for details, I think there are also a bug report that migh tbe related, if so, you should add your details there: https://sourceforge.net/tracker/?func=detailaid=1839973group_id=64325atid=507079 .hc On Mar 26, 2009, at 11:39 PM, james murray wrote: Common? Really? Is there any sort of good explanation for this? After testing it for a few hours it's definitely only occurring after I select restart and never happening when I shut the computer down and then restart manually I guess I'm curious about why this would be happening, and is there anything out there more informative than the pd forums for snafus like this? I spent a good chunk of my day trying to find different ways to describe the error but could get no useful search results in there... Thanks so much for the input Hans-Christoph, it's really appreciated, I'll give the workaround you suggested a shot in the morning and see what happens. J On Thu, Mar 26, 2009 at 6:49 PM, Hans-Christoph Steiner h...@eds.org wrote: Yeah, its pretty common. If you are using [pix_movie], try using: [pix_film] | [pix_texture] .hc On Mar 26, 2009, at 1:18 PM, chris clepper wrote: Need some more info: Video card model, what the piece uses in GEM, does any other app have problems? Maybe post a pic or video of the screens too. On Thu, Mar 26, 2009 at 12:52 PM, james murray james.n.mur...@gmail.com wrote: Hello List I've got a two screen GEM piece running on Plasma displays that has recently started to, on reboot, begin flickering the GEM screen in a neon purple/green mode. I'm wondering about whether the video card in my G5 tower is on the way out, and as a result, this glitch is occurring... It seems more prone to enter into this green/purple rave when the computer reboots, and less/never has occurred if we do a hard shutdown followed by startup. Any ideas? Confirmations? Counter-arguments... this is a new one for me, and insight would be grand. J ___ 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 News is what people want to keep hidden and everything else is publicity. - Bill Moyers News is what people want to keep hidden and everything else is publicity. - Bill Moyers ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] agenda for upcoming book sprint?[GEM sprint]
ydego...@gmail.com wrote: that's where the joke is, that floss manuals cover software that should also run on windows yes, you've always been a joker man, you know that sorry i that seemed agressive, i just meant you're a reactionary force, cos don't document ardour, supercollider and others if they don't run on windblows ... anyway i wouldn't read it gute nacht! sevy xiaoo, sevy Derek Holzer wrote: Hi guys, As the facilitator of this project, I will post a list of sprint targets quite soon. GEM section is definitely on my list, however I do want to keep to things which are both included in PD-Extended and are cross platform. For now, this excludes PDP and Gridflow. Maybe if someone wanted to make a separate section which includes installation/configuration info (following the template in the Install chapters of the existing Pd FLOSS Manual), then a section on one of these might be relevant. But as they are both essentially Linux only, by virtue of either being uncompilable or nearly unusable on other platforms, I'd rather keep focus someplace else. As for GEM, I'd like to see some stuff on the following (in order of priority): 1) Basic VJ mixer (2 x [gemhead]-[pix_film]-[alpha]-[colorRGB]-[pix_texture]-[rectangle] with an alpha-crossfader)(+ platform specific codec info) 2) Live camera input (same as VJ mixer but with [pix_video], with platform specific info on USB/firewire inputs--what works what doesn't) 3) VJ effects (using the various pix objects) 4) Basic 3D (that actually does something interesting, rather than just show a sphere or a cube) 5) Basic movement tracking w/ [pix_blob] 6) GEM/video optimization/troubleshooting tips (see Troubleshooting section of existing Pd FLOSS Manual)(Chris Clepper, are you in the house?) I have some tutorial patches which could be used as the basis for most of this, let me know if you are interested. Full target list coming soon, I'll make sure to include this GEM section. best, Derek marius schebella wrote: Hans-Christoph Steiner wrote: Hey all, I hope I am not jumping the gun or stepping on anyone's toes. I just wanted to open up the discussion about what people are planning on working on during the upcoming book sprint. Currently, I am pretty open to topics, but I was thinking that Gem/PDP/Gridflow could really use a section. There are lots of examples for them, but they lack a good intro to the concepts. I am in for a gem sprint. marius. ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] Delay effect without clicks
hi again, vd~ allows you to be controlled via a dsp signal (as opposed to a message inlet which only gets updated every 1,6 ms or so) and thus allows you to smoothly change the delay time. but you have to do do an interpolation between the messages you are feeding into it, and the best way to do this is with [line~]. [numberbox\ | [line $1 100( | [vd~ del] marius. Bjørn Nielsen wrote: Hey Marius Thanks for the quick reply. I have now tried vd~, but I still encounter clicks noises when I change delay time. audiosignal | [delwrite testname 2000] delaytime | [sig~] | [vd~ testname] | audioout+back to delwrite Do the click noises has something to do with the samplelength in delwrite~? (and can it at all be changed on the fly?) /Bjørn On Fri, Mar 27, 2009 at 00:13, marius schebella marius.schebe...@gmail.com wrote: hi Bjørn, maybe vd~ (variable delay) is what you're looking for? marius. Bjørn Nielsen wrote: Hey PD list This is my first mail to the list and I am a newbie in PD, so please bear with me. I am trying to make a patch that simulates the delay effects I use as a stompbox for my guitar. I.e. a signal delay line, with a parameter of feedback and a parameter of delay time. While changing the delay time parameter the ongoing sampled part should change pitch. My first attempt (as in the attached patch) is to use delread~/delwrite~, but changing the lenght of the sampled part in delread~ makes a lot of clicks noises (which can be fun, but not what I intended) and it do not change pitch. My max/msp friend said I should instead of clipping the sample, make it run faster. So I tried to figure if that was possible with delread~, vd~ or using arrays instead with tabread(4)~, but I have not found the golden key yet. I would be very happy if somebody could lead me in right direction. Thanks, Bjørn ___ 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] steep filter?
On 27 Mar 2009, at 01:41, João Pais wrote: hm, i'm certainly not against this idea, as i'm not opposed to sharing what i've done, if it is interesting for others. but i don't use pd-extended myself a a lot and actually i don't know the process of getting externals into the system. that is quite easy: contact directly H-C Steiner to get a svn account, then upload your code - or ask him more about how to do it. also, i don't know about the policy of pd-extended or where it's aiming at, but i guess that the externals that get in there, must have somehow proven to be useful to many users. ahhh, there's no policy. anyone who manifests interest in joining in joins in, I guess. there's also no admittance test, so everyone just puts in the code he wants (sometimes even buggy code). which makes the whole a thing not really totally übersichtlich (one of the GSC projects was to organize and catalog the externals on pd-ext). but pd-ext is quite used (only hardcore people/code developers prefer pd-van), and it's the easiest way to make the code available to everyone. of course it can happen that no one notices it's there, because there are around 2000+ files in the /extra folder of pd-ext. not really totally übersichtlich, yeah i had that impression, too :) anyway, thanks for your comments, joão. i'll think about it. volker. ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] Delay effect without clicks
from your first email, it sounds like you are expecting a pitch shift. So how does the pitch shift you are hearing differ from what you are expecting i.e. define weird. I take it you tried different numbers where the 50 is i.e. 500 etc.? Still weird? Yeah I tried different line ramp numbers, and it change the pitch shifting to deeper frequencies the longer the line ramp is. And the longer the ramp is it feels more unresponsive, since the long ramp. But the thing that really differs from an analog delays (with tapes) is that it is only changing pitch when you change the delaytime value at the same time as a sound come through. If you makes a short note, pass it through the delay with a 1sec delay and in the pause between to delayed notes change the delay time to 1/2 sec, it won't change pitch. The sound while it change pitch do not sound very smoothly. It has a definitely digital sound, like a whammy effect. I would like it to have as much analog feeling as possible. It seemed to me that Frank thought you wanted to build a pitch shifter using the delay effect. Maybe he did? But I find the example interesting, because my max/msp friend said that he had made an delay effect that changed delay time smoothly but without pitch change, also with shifting between to delay chains. So I will see if can tweak it around for my purpose. :-) Bjørn Bjørn Nielsen wrote: Thanks Marius, Frank John I got rid of the click noises now by doing this [numberbox\ | [pack $f1 50] | [line~] | [vd~ testreadname] But the pitch shifting it does while changing delay time is quite weird, so I think I will look into Franks example of doing this. / Bjørn On Fri, Mar 27, 2009 at 07:08, marius schebella marius.schebe...@gmail.com wrote: hi again, vd~ allows you to be controlled via a dsp signal (as opposed to a message inlet which only gets updated every 1,6 ms or so) and thus allows you to smoothly change the delay time. but you have to do do an interpolation between the messages you are feeding into it, and the best way to do this is with [line~]. [numberbox\ | [line $1 100( | [vd~ del] marius. Bjørn Nielsen wrote: Hey Marius Thanks for the quick reply. I have now tried vd~, but I still encounter clicks noises when I change delay time. audiosignal | [delwrite testname 2000] delaytime | [sig~] | [vd~ testname] | audioout+back to delwrite Do the click noises has something to do with the samplelength in delwrite~? (and can it at all be changed on the fly?) /Bjørn On Fri, Mar 27, 2009 at 00:13, marius schebella marius.schebe...@gmail.com wrote: hi Bjørn, maybe vd~ (variable delay) is what you're looking for? marius. Bjørn Nielsen wrote: Hey PD list This is my first mail to the list and I am a newbie in PD, so please bear with me. I am trying to make a patch that simulates the delay effects I use as a stompbox for my guitar. I.e. a signal delay line, with a parameter of feedback and a parameter of delay time. While changing the delay time parameter the ongoing sampled part should change pitch. My first attempt (as in the attached patch) is to use delread~/delwrite~, but changing the lenght of the sampled part in delread~ makes a lot of clicks noises (which can be fun, but not what I intended) and it do not change pitch. My max/msp friend said I should instead of clipping the sample, make it run faster. So I tried to figure if that was possible with delread~, vd~ or using arrays instead with tabread(4)~, but I have not found the golden key yet. I would be very happy if somebody could lead me in right direction. Thanks, Bjørn ___ 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 -- John Harrison http://alumni.media.mit.edu/~harrison ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] Delay effect without clicks
from your first email, it sounds like you are expecting a pitch shift. So how does the pitch shift you are hearing differ from what you are expecting i.e. define weird. I take it you tried different numbers where the 50 is i.e. 500 etc.? Still weird? It seemed to me that Frank thought you wanted to build a pitch shifter using the delay effect. -John Bjørn Nielsen wrote: Thanks Marius, Frank John I got rid of the click noises now by doing this [numberbox\ | [pack $f1 50] | [line~] | [vd~ testreadname] But the pitch shifting it does while changing delay time is quite weird, so I think I will look into Franks example of doing this. / Bjørn On Fri, Mar 27, 2009 at 07:08, marius schebella marius.schebe...@gmail.com wrote: hi again, vd~ allows you to be controlled via a dsp signal (as opposed to a message inlet which only gets updated every 1,6 ms or so) and thus allows you to smoothly change the delay time. but you have to do do an interpolation between the messages you are feeding into it, and the best way to do this is with [line~]. [numberbox\ | [line $1 100( | [vd~ del] marius. Bjørn Nielsen wrote: Hey Marius Thanks for the quick reply. I have now tried vd~, but I still encounter clicks noises when I change delay time. audiosignal | [delwrite testname 2000] delaytime | [sig~] | [vd~ testname] | audioout+back to delwrite Do the click noises has something to do with the samplelength in delwrite~? (and can it at all be changed on the fly?) /Bjørn On Fri, Mar 27, 2009 at 00:13, marius schebella marius.schebe...@gmail.com wrote: hi Bjørn, maybe vd~ (variable delay) is what you're looking for? marius. Bjørn Nielsen wrote: Hey PD list This is my first mail to the list and I am a newbie in PD, so please bear with me. I am trying to make a patch that simulates the delay effects I use as a stompbox for my guitar. I.e. a signal delay line, with a parameter of feedback and a parameter of delay time. While changing the delay time parameter the ongoing sampled part should change pitch. My first attempt (as in the attached patch) is to use delread~/delwrite~, but changing the lenght of the sampled part in delread~ makes a lot of clicks noises (which can be fun, but not what I intended) and it do not change pitch. My max/msp friend said I should instead of clipping the sample, make it run faster. So I tried to figure if that was possible with delread~, vd~ or using arrays instead with tabread(4)~, but I have not found the golden key yet. I would be very happy if somebody could lead me in right direction. Thanks, Bjørn ___ 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 -- John Harrison http://alumni.media.mit.edu/~harrison ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] pd-extended font paths
On Thu, 26 Mar 2009, Phil Stone wrote: Oh, Gem, of course. So when I'm not using Gem, I can safely do without those eight path elements, then? Also, while I'm being a whinging pest...it's impossible to add a path element that lives inside the pd-extended.app folder using the path dialog. This is because OS X makes the .app package not look like a folder, I suppose, but it's unfortunate nevertheless. Off to edit the .plist, I go. If Pd-Extended is GPL'd, then it could use some code that I wrote some years ago (mid-2006?) for editing pdrc: http://artengine.ca/desiredata/gallery/pdrc_6.png Except that it would be made to work with Pd's path system instead of reading/writing .pd files. If that part of Pd-Extended is not GPL'd, this is a tiny piece of quite ordinary code really, so, much any adaptation of it will look like it was made by someone else... copyright applies better on bigger or more original chunks of code. So, the add button opens a folder-selection dialogue box for adding a path at the bottom of the list. The remove button removes the currently selected row in the listbox. up and down move the currently selected entry up or down in the list, swapping position with the entry in that direction (to change path priorities). There is no known limit to the number of entries in that listbox. The 2nd listbox could be done away with if Pd-extended doesn't want a dialogue for -helppath. The rest of the dialogue can be ignored, you can do it the way you want. (the example in the screenshot is obsolete... loading that lib now automatically modifies the -path and -helppath in an implicit way) _ _ __ ___ _ _ _ ... | 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] Delay effect without clicks
Hallo, Bj?rn Nielsen hat gesagt: // Bj?rn Nielsen wrote: But the thing that really differs from an analog delays (with tapes) is that it is only changing pitch when you change the delaytime value at the same time as a sound come through. If you makes a short note, pass it through the delay with a 1sec delay and in the pause between to delayed notes change the delay time to 1/2 sec, it won't change pitch. Yeah, that's actually how pitch shifting and delays work. If the delay time is not changing, you also don't hear a pitch change. Only while the delay time changes you get a pitchshifting effect. That's the Doppler effect: If you sit in a police car, you don't hear a pitch change of the horn, but if it passes you, the time the signal needs to reach you is changing with the distance, and that makes the Doppler sound. If you want pitchshifting, check out the example patch, it should do what you want. Ciao -- Frank ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] [equalizer] / [lowshelf] / [highshelf] in purepd!
Hallo, cyrille henry hat gesagt: // cyrille henry wrote: Frank Barknecht a écrit : ... The others are included in the rjdj library as u_lowpass, u_lowpassq, u_highpass, u_highpassq, u_bandpass1, u_bandpass1q, u_bandpass2 and u_bandpass2q. There also is a signal biquad~ as e_beequad available (which just does linear interpolation of parameters, so it's of course not really correct if you do larger jumps). it certainly is obvious, but where can i find them? Here's their home page: http://trac.rjdj.me/wiki/RjLibnew rsp. $ svn co http://svn.rjdj.me/scenes/trunk/rjlib/ (They are GPL, but not yet tagged correctly) Ciao -- Frank ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] Delay effect without clicks
Are you suggesting that you've spent a lot of time in police cars thinking about this! 2009/3/27 Frank Barknecht f...@footils.org: Hallo, Bj?rn Nielsen hat gesagt: // Bj?rn Nielsen wrote: But the thing that really differs from an analog delays (with tapes) is that it is only changing pitch when you change the delaytime value at the same time as a sound come through. If you makes a short note, pass it through the delay with a 1sec delay and in the pause between to delayed notes change the delay time to 1/2 sec, it won't change pitch. ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] Delay effect without clicks
Hallo, Rory Walsh hat gesagt: // Rory Walsh wrote: Are you suggesting that you've spent a lot of time in police cars thinking about this! Uhm, well, let's not talk about that. ;) Ciao -- Frank ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] experiments with fiddle~
Oded Ben-Tal ha scritto: i'm trying to experiment and learn how [fiddle~] works, using it to control You should probably use [sigmund~] instead. It's not working perfectly yet but is the future. thanks, i had a look and it seems nice, i will try using it. As for some technical solutions to event detection the work of Nick Collins (mostly supercollieder and matlab I believe) has some good methods www.informatics.sussex.ac.uk/users/nc81/researchml.php This stuff seems to go deep, maybe too much for me in this period. Saved in bookmarks, and i hope i will have time to read it soon. thanks a lot! athos ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] agenda for upcoming book sprint?[GEM sprint]
I think we definitely should document PDP/PiDIP and Gridflow as well. Do you want to participate and help out? If there aren't any PDP or Gridflow people joining in, then I think it makes the most sense to focus on Gem since it is the most widespread. .hc On Mar 27, 2009, at 12:56 AM, ydego...@gmail.com wrote: that's where the joke is, that floss manuals cover software that should also run on windows yes, you've always been a joker man, you know that xiaoo, sevy Derek Holzer wrote: Hi guys, As the facilitator of this project, I will post a list of sprint targets quite soon. GEM section is definitely on my list, however I do want to keep to things which are both included in PD-Extended and are cross platform. For now, this excludes PDP and Gridflow. Maybe if someone wanted to make a separate section which includes installation/configuration info (following the template in the Install chapters of the existing Pd FLOSS Manual), then a section on one of these might be relevant. But as they are both essentially Linux only, by virtue of either being uncompilable or nearly unusable on other platforms, I'd rather keep focus someplace else. As for GEM, I'd like to see some stuff on the following (in order of priority): 1) Basic VJ mixer (2 x [gemhead]-[pix_film]-[alpha]-[colorRGB]-[pix_texture]-[rectangle] with an alpha-crossfader)(+ platform specific codec info) 2) Live camera input (same as VJ mixer but with [pix_video], with platform specific info on USB/firewire inputs--what works what doesn't) 3) VJ effects (using the various pix objects) 4) Basic 3D (that actually does something interesting, rather than just show a sphere or a cube) 5) Basic movement tracking w/ [pix_blob] 6) GEM/video optimization/troubleshooting tips (see Troubleshooting section of existing Pd FLOSS Manual)(Chris Clepper, are you in the house?) I have some tutorial patches which could be used as the basis for most of this, let me know if you are interested. Full target list coming soon, I'll make sure to include this GEM section. best, Derek marius schebella wrote: Hans-Christoph Steiner wrote: Hey all, I hope I am not jumping the gun or stepping on anyone's toes. I just wanted to open up the discussion about what people are planning on working on during the upcoming book sprint. Currently, I am pretty open to topics, but I was thinking that Gem/PDP/Gridflow could really use a section. There are lots of examples for them, but they lack a good intro to the concepts. I am in for a gem sprint. marius. ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list Access to computers should be unlimited and total. - the hacker ethic ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
[PD] can you help me with this vocoder?
Hi guys, What an amazing resource this list is! Very exciting to me. Anyway, I'm after some help with Miller Puckette's vocoder patch. I've used vocoders before, but I can't see any of the recognizable features in this patch. What I wanna do is use an [adc~] as a modulator signal, a white noise generator as a carrier signal, and simply have a mix slider. I've tried the vocoder help patch, but it didn't help me very much. Anything you guys can offer me would be greatly appreciated-I've attached both patches. Babsyco. _ Need a new place to rent, share or buy? Let ninemsn property help. http://a.ninemsn.com.au/b.aspx?URL=http%3A%2F%2Fninemsn%2Edomain%2Ecom%2Eau%2F%3Fs%5Fcid%3DFDMedia%3ANineMSN%5FHotmail%5FTagline_t=774152450_r=Domain_tagline_m=EXT#N canvas 519 89 539 284 10; #X obj 33 21 inlet~; #X obj 31 231 outlet~; #X obj 82 209 outlet~; #X obj 95 22 inlet~; #X obj 369 59 param.group; #X obj 423 11 loadbang; #X obj 423 35 dollarg; #X obj 343 11 inlet params; #X obj 32 179 mix.wet.stereo~ 1; #X obj 143 153 param.atom wet 127 0 127; #N canvas 376 248 795 617 fft-analysis 0; #X obj 94 511 *~; #X obj 55 511 *~; #X obj 413 356 *~; #X obj 372 356 *~; #X obj 372 379 +~; #X obj 54 183 *~; #X obj 54 158 inlet~; #X obj 54 206 rfft~; #X obj 54 560 *~; #X obj 141 245 *~; #X obj 372 333 rfft~; #X obj 54 535 rifft~; #X obj 54 583 outlet~; #X obj 107 245 *~; #X obj 107 268 +~; #X text 458 408 modulus; #X obj 107 420 *~; #X obj 107 398 clip~; #X obj 87 184 tabreceive~ \$0-hann; #X obj 599 53 loadbang; #X obj 148 346 r squelch; #X obj 147 369 expr 0.01*$f1*$f1; #X obj 107 294 +~ 1e-20; #X obj 108 480 *~ 0.00065; #X obj 87 560 tabreceive~ \$0-hann; #X obj 373 307 *~; #X obj 373 282 inlet~; #X obj 406 308 tabreceive~ \$0-hann; #X obj 107 321 q8_rsqrt~; #X obj 372 402 q8_sqrt~; #X text 458 425 of control; #X text 456 442 amplitude; #X text 196 248 reciprocal; #X text 199 267 modulus of; #X text 195 287 filter input; #X text 196 306 amplitude; #X text 115 159 filter input; #X text 438 282 control source; #X text 434 332 Fourier transform; #X text 28 17 Internal workings of the timbre stamping algorithm. First the filter input is treated as in the compressor patch \, multiplying each channel amplitude by one over its modulus (but limited by the squelch parameter.) It is then multiplied by the modulus of the channel amplitude for the control source (which is Fourier analyzed in parallel with the filter input.); #X text 145 422 multiply the two amplitude; #X text 143 439 factors (for compression; #X text 145 455 and to apply new timbre); #X obj 104 584 outlet~; #X obj 598 7 inlet; #X obj 598 29 switch~ 1024 4; #X msg 599 76 \; window-size 1024 \; squelch 30 \;; #X connect 0 0 11 1; #X connect 1 0 11 0; #X connect 2 0 4 1; #X connect 3 0 4 0; #X connect 4 0 29 0; #X connect 5 0 7 0; #X connect 6 0 5 0; #X connect 7 0 13 0; #X connect 7 0 13 1; #X connect 7 0 1 0; #X connect 7 1 9 0; #X connect 7 1 9 1; #X connect 7 1 0 0; #X connect 8 0 12 0; #X connect 8 0 43 0; #X connect 9 0 14 1; #X connect 10 0 3 0; #X connect 10 0 3 1; #X connect 10 1 2 0; #X connect 10 1 2 1; #X connect 11 0 8 0; #X connect 13 0 14 0; #X connect 14 0 22 0; #X connect 16 0 23 0; #X connect 17 0 16 0; #X connect 18 0 5 1; #X connect 19 0 46 0; #X connect 20 0 21 0; #X connect 21 0 17 2; #X connect 22 0 28 0; #X connect 23 0 0 1; #X connect 23 0 1 1; #X connect 24 0 8 1; #X connect 25 0 10 0; #X connect 26 0 25 0; #X connect 27 0 25 1; #X connect 28 0 17 0; #X connect 29 0 16 1; #X connect 44 0 45 0; #X restore 52 109 pd fft-analysis; #N canvas 0 110 565 454 hann-window 0; #N canvas 0 0 450 300 (subpatch) 0; #X array \$0-hann 1024 float 0; #X coords 0 1 1023 0 300 100 1; #X restore 82 311 graph; #X obj 378 165 osc~; #X obj 378 190 *~ -0.5; #X obj 378 214 +~ 0.5; #X obj 331 247 tabwrite~ \$0-hann; #X obj 37 88 r window-size; #X obj 38 173 /; #X obj 127 142 samplerate~; #X obj 38 251 s window-sec; #X obj 177 204 swap; #X obj 177 228 /; #X obj 177 252 s window-hz; #X obj 49 201 * 1000; #X obj 49 228 s window-msec; #X obj 38 115 t f b f; #X msg 173 92 resize \$1; #X obj 173 116 s \$0-hann; #X obj 330 105 r window-hz; #X msg 382 130 0; #X obj 330 131 t f b; #X text 15 8 calculate Hann window table (variable window size) and constants window-hz (fundamental frequency of analysis) \, window-sec and window-msec (analysis window size in seconds and msec).; #X connect 1 0 2 0; #X connect 2 0 3 0; #X connect 3 0 4 0; #X connect 5 0 14 0; #X connect 6 0 8 0; #X connect 6 0 12 0; #X connect 7 0 6 1; #X connect 7 0 9 1; #X connect 9 0 10 0; #X connect 9 1 10 1; #X connect 10 0 11 0; #X connect 12 0 13 0; #X connect 14 0 6 0; #X connect 14 0 9 0; #X connect 14 1 7 0; #X connect 14 2 15 0; #X connect 15 0 16 0; #X connect 17 0 19 0; #X connect 18 0 1 1; #X connect 19 0 1 0; #X connect 19 1 4 0; #X connect 19 1 18 0; #X restore 171 106 pd hann-window; #X connect 0 0 8 0; #X connect 0 0 10 0; #X connect 3 0
Re: [PD] agenda for upcoming book sprint?[GEM sprint]
My thoughts exactly...document what people actually use most, in a way which helps them to use it. As I said, if someone wants to go through all the trouble of making a separate install guide for PDP or Gridflow, I'd consider including it. As it stands, however, both of these can change at any moment depending on distros and dependencies on top of the fact that they only run well on Linux + x86 architecture (PDP) or cannot be compiled at all except on Linux (Gridflow). For me to accept them into the FLOSS manual, the installation process must be completely and reliably documented as well. No lazy just compile it and cry to the mailing list if it doesn't work instructions which leave newbies lost. Free software is only really free when you don't have to be a computer programmer to get it working. As it stands, I want to focus on accessibility first off. So cross-platform + Pd Extended is the baseline for the FLOSS Manual, as it has been from the beginning. D. Hans-Christoph Steiner wrote: I think it makes the most sense to focus on Gem since it is the most widespread. -- ::: derek holzer ::: http://blog.myspace.com/macumbista ::: http://www.vimeo.com/macumbista ::: ---Oblique Strategy # 30: Change specifics to ambiguities ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] agenda for upcoming book sprint?[GEM sprint]
For what its worth, PDP/PiDiP has been included in Mac OS X and GNU/ Linux Pd-extended since 0.39.3, so no compilation instructions needed. We do still need someone to write the docs. I don't think I know enough to write more than a paragraph. Same goes with Gridflow, in my book. .hc On Mar 27, 2009, at 8:56 PM, Derek Holzer wrote: My thoughts exactly...document what people actually use most, in a way which helps them to use it. As I said, if someone wants to go through all the trouble of making a separate install guide for PDP or Gridflow, I'd consider including it. As it stands, however, both of these can change at any moment depending on distros and dependencies on top of the fact that they only run well on Linux + x86 architecture (PDP) or cannot be compiled at all except on Linux (Gridflow). For me to accept them into the FLOSS manual, the installation process must be completely and reliably documented as well. No lazy just compile it and cry to the mailing list if it doesn't work instructions which leave newbies lost. Free software is only really free when you don't have to be a computer programmer to get it working. As it stands, I want to focus on accessibility first off. So cross- platform + Pd Extended is the baseline for the FLOSS Manual, as it has been from the beginning. D. Hans-Christoph Steiner wrote: I think it makes the most sense to focus on Gem since it is the most widespread. -- ::: derek holzer ::: http://blog.myspace.com/macumbista ::: http://www.vimeo.com/macumbista ::: ---Oblique Strategy # 30: Change specifics to ambiguities ___ 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
