Hi,
In playing around with PD, i'm finding that the patches i'm designing are coming across sounding too pure and clean. Does anyone have any tips for adding some kind of random crustiness to sounds? To get sounds that detune in an authentic analogue style, and filters which distort slightly at the low end etc. I'm trying things out like modulating with brown noise etc. which is working fairly well, but I thought that maybe someone else is into the same aesthetic, and could give me some tips.
Feel free to reply off list if this is not the appropriate forum for this kind of discussion.
Regards,
Chris. ______________________________________________________ Chris McCormick - Systems Developer - PerthWeb Pty Ltd Internet Solutions for your business! Level 9/105 St George's Tc - Perth - Western Australia Ph: (08) 9226 1366 Fax: (08) 9226 1375 Visit Perth online! : www.perthweb.com.au PGP Key = http://www.perthweb.com.au/~chris/public.txt
Hi GEM people,
I've been playing with texture mapping in GEM and I'm a bit confused by the way that the current texture coordinates are maintained or propagated.
That is: the [pix_coordinate] object clears the texture coords after its following list nodes have rendered, but other objects which set the coords namely [pix_movie] and [pix_texture2] do not clear the texture coordinates. Furthermore, the [pix_texture] object doesn't touch the texture coordinates at all. This means that a texture coord mapping created with [pix_movie] or [pix_texture2] but not [pix_coordinate] will apply to textures generated using [pix_texture] that are applied in other gemlists. This isn't useful as far as I can see, in that the textures and images aren't propagated across the gemlists.
Is this deliberate? -OR- Should [pix_texture] clear the texture coords itself before it renders? Should the texture coords be cleared at each gemhead? Should [pix_movie] and [pix_texture2] clear the texture coords after they render?
Obviously, the workaround is just to plonk a [pix_coordinate] in each gemlist, but that should be unnecessary, no?
BTW - I'm still really amazed at how much can be done with GEM. Wow!
Thanks, Daniel
Daniel Heckenberg wrote:
Hi GEM people,
hi daniel!
clearly you have discovered a bug at objects setting the texture-coordinates (namely: [pix_movie] & [pix_texture2]) [pix_texture] behaves as it should.
i will fix this
mfg.ds.sadr iOhannes
On Fri, 7 Jun 2002, IOhannes zmoelnig wrote:
hi daniel!
clearly you have discovered a bug at objects setting the texture-coordinates (namely: [pix_movie] & [pix_texture2]) [pix_texture] behaves as it should.
Actually, why are there two texture objects, is there a reason why this can't be done in one object ?
Guenter
? wrote:
Actually, why are there two texture objects, is there a reason why this can't be done in one object ?
well [pix_texture] does simply load a pixbuffer into texture-ram. it does know nothing about texture-coordinates. (these are handled by [pix_coordinates])
[pix_texture2] does load an image into texture-ram as a sub-texture (of a black master-texture) with coordinates set so it appear as a "normal" (full) texture. thus it enables you to use images that are not power-of-2 as textures without expensive rescaling it is copy'n'pasted from pix_movie.
it might not be that elegant (as would be [pix_subtexture]+[pix_coordinates]) but i think it is easier for handling, since you do not need to know the size of the img.
mfg.cds.adrf IOhannes
Guenter
On Fri, 7 Jun 2002, IOhannes zmoelnig wrote:
? wrote:
Actually, why are there two texture objects, is there a reason why this can't be done in one object ?
well [pix_texture] does simply load a pixbuffer into texture-ram. it does know nothing about texture-coordinates. (these are handled by [pix_coordinates])
[pix_texture2] does load an image into texture-ram as a sub-texture (of a black master-texture) with coordinates set so it appear as a "normal" (full) texture. thus it enables you to use images that are not power-of-2 as textures without expensive rescaling it is copy'n'pasted from pix_movie.
it might not be that elegant (as would be [pix_subtexture]+[pix_coordinates]) but i think it is easier for handling, since you do not need to know the size of the img.
Yes, thats really nice and important, because noone has power of two movies, but it doesn't answer my question.
I am asking if this fact could not be hidden from the user.
I am thinking about a pix_texture that detects the image size and behaves accordingly. Pix_texture2 does that, so why not throw away pix_texture and use pix_texture2 ?
Guenter
You can do some interesting distortion using a transfer function. I've attached an example patch with a sort of tube-like transfer function. Also, you might be interested in LFO_noise~ from iemlib for random modulation, and using a compressor such as zexy's limiter~ (which can dirty a sound if you put some rough reverb through it).
Ben
On Fri, Jun 07, 2002 at 11:06:51AM +0800, Chris McCormick wrote:
Hi,
In playing around with PD, i'm finding that the patches i'm designing are coming across sounding too pure and clean. Does anyone have any tips for adding some kind of random crustiness to sounds? To get sounds that detune in an authentic analogue style, and filters which distort slightly at the low end etc. I'm trying things out like modulating with brown noise etc. which is working fairly well, but I thought that maybe someone else is into the same aesthetic, and could give me some tips.
Feel free to reply off list if this is not the appropriate forum for this kind of discussion.
Regards,
Chris. ______________________________________________________ Chris McCormick - Systems Developer - PerthWeb Pty Ltd Internet Solutions for your business! Level 9/105 St George's Tc - Perth - Western Australia Ph: (08) 9226 1366 Fax: (08) 9226 1375 Visit Perth online! : www.perthweb.com.au PGP Key = http://www.perthweb.com.au/~chris/public.txt
oops, forgot the attachment.. :}
On Fri, Jun 07, 2002 at 12:16:52PM -0800, bsaylor@Macalester.edu wrote:
You can do some interesting distortion using a transfer function. I've attached an example patch with a sort of tube-like transfer function. Also, you might be interested in LFO_noise~ from iemlib for random modulation, and using a compressor such as zexy's limiter~ (which can dirty a sound if you put some rough reverb through it).
Ben
On Fri, Jun 07, 2002 at 11:06:51AM +0800, Chris McCormick wrote:
Hi,
In playing around with PD, i'm finding that the patches i'm designing are coming across sounding too pure and clean. Does anyone have any tips for adding some kind of random crustiness to sounds? To get sounds that detune in an authentic analogue style, and filters which distort slightly at the low end etc. I'm trying things out like modulating with brown noise etc. which is working fairly well, but I thought that maybe someone else is into the same aesthetic, and could give me some tips.
Feel free to reply off list if this is not the appropriate forum for this kind of discussion.
Regards,
Chris. ______________________________________________________ Chris McCormick - Systems Developer - PerthWeb Pty Ltd Internet Solutions for your business! Level 9/105 St George's Tc - Perth - Western Australia Ph: (08) 9226 1366 Fax: (08) 9226 1375 Visit Perth online! : www.perthweb.com.au PGP Key = http://www.perthweb.com.au/~chris/public.txt
On Fri, 7 Jun 2002 12:16:52 -0800 bsaylor@macalester.edu wrote:
You can do some interesting distortion using a transfer function. I've attached an example patch with a sort of tube-like transfer function. Also, you might be interested in LFO_noise~ from iemlib for random modulation, and using a compressor such as zexy's limiter~ (which can dirty a sound if you put some rough reverb through it).
Ben
Thanks a lot, Ben. This is a really nice distortion patch, i can see it coming in very handy. Will check out LFO_noise and limiter.
Chris.
Hi Ben,
I looked at your very nice distortion patch. Is it intentional that multiplication adding and clipping takes place in this order? If gain is != 1, the clipping in the result is not symmetrical. I changed it to clip before the adding and multiplication to keep the symmetry, but maybe that's not what you intend?
Yours, Orm
Am Freitag, den 07. Juni 2002 um 12:16:52 Uhr (-0800) schrieb bsaylor@macalester.edu:
You can do some interesting distortion using a transfer function. I've attached an example patch with a sort of tube-like transfer function. Also, you might be interested in LFO_noise~ from iemlib for random modulation, and using a compressor such as zexy's limiter~ (which can dirty a sound if you put some rough reverb through it).
Ben
The two versions should be equivalent (I tried subtracting them and got silence). Here's an abstraction, and it clips first.. :)
On Sat, Jun 08, 2002 at 10:43:11AM +0200, Orm Finnendahl wrote:
Hi Ben,
I looked at your very nice distortion patch. Is it intentional that multiplication adding and clipping takes place in this order? If gain is != 1, the clipping in the result is not symmetrical. I changed it to clip before the adding and multiplication to keep the symmetry, but maybe that's not what you intend?
Yours, Orm
Hi, Chris McCormick hat gesagt: // Chris McCormick wrote:
In playing around with PD, i'm finding that the patches i'm designing are coming across sounding too pure and clean. Does anyone have any tips for adding some kind of random crustiness to sounds? To get sounds that detune in an authentic analogue style, and filters which distort slightly at the low end etc. I'm trying things out like modulating with brown noise etc. which is working fairly well, but I thought that maybe someone else is into the same aesthetic, and could give me some tips.
You might try to downsample some things a bit with the [block] object. Some early digital synths or sample player didn't do CD-quality as is the default in PD. Then you could build your own distortion with simple waveshaping. An example patch is wsinstr.pd in my waveshaper package from footils.org (not shabby/shaffy, the other one.) The principle is, that you have an oscillator, say [osc~] The output from that osc~ is used to lookup values in a table and the found table-values then get send to the dac~. With different tables you can get simple, but effective distortions.
And feel free to use ready-made plugins depending on your platform (LADSPA/VST) for distortion/detune.
Feel free to reply off list if this is not the appropriate forum for this kind of discussion.
It is a very appropriate forum here ;)
Frank Barknecht _ ______footils.org__