[PD] flip image in glsl
Hello, how is it possible to flip upside down an image in glsl example 05.multitexture I tried to implement this in fragment program: http://stackoverflow.com/questions/9857089/flip-upside-down-vertex-shader-gles but it doesn't work. The only thing I can do is changing texture scale and position, but I couldn't do it with negative values like it would be done in pix_coordinates. In fact when I use pix_multiimage before pix_texture, the image gets flipped, I don't know why... Colet Patrice ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] flip image in glsl
hello, when using rectangular texturing, coordinate goes from 0 to image pixel size. when using rectangle 0 mode, pixel coordinate goes from 0 to 1. (sometimes 1 is for the power of 2 bigger than the image pixel size) so, in rectangular mode, use pixetl_size - image coordinate to flip the image. and 1 - image coordinate in non rectangle mode. Image can be fliped because the fliped flag is not used on the shader. cheers c Le 08/04/2013 09:24, Patrice Colet a écrit : Hello, how is it possible to flip upside down an image in glsl example 05.multitexture I tried to implement this in fragment program: http://stackoverflow.com/questions/9857089/flip-upside-down-vertex-shader-gles but it doesn't work. The only thing I can do is changing texture scale and position, but I couldn't do it with negative values like it would be done in pix_coordinates. In fact when I use pix_multiimage before pix_texture, the image gets flipped, I don't know why... Colet Patrice ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
[PD] sfread~ droupouts / understanding buffer parameter?
Hi list, I have a patch with around 80 sfread~s, who read audio files between 8-16 seconds (each sfread reads always the same file). But I noticed that there are often enough small audio droupouts when running the patch. After adding a buffer value of 1e+6 (like in the help patch) the playback was better, but not yet perfect. So I wanted to ask: how does the buffer parameter work exactly? How can one choose the best value for it? Does someone has an example patch, or something written somewhere? The sfread~s don't work all simultaneously, maybe maximum of 20 sfread~s might be working at the same time. Thanks, jmp ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] sfread~ droupouts / understanding buffer parameter?
On Mon, 2013-04-08 at 10:08 +0200, João Pais wrote: Hi list, I have a patch with around 80 sfread~s, who read audio files between 8-16 seconds (each sfread reads always the same file). But I noticed that there are often enough small audio droupouts when running the patch. After adding a buffer value of 1e+6 (like in the help patch) the playback was better, but not yet perfect. There is no [sfread~] class in current Pd-extended (0.43.4). Do you have an older version of Pd-extended? From which library is that class? I can only find moonlib's [sfread2~] and zexy's [sfplay~] and, of course, the built-in [readsf~]. So I wanted to ask: how does the buffer parameter work exactly? How can one choose the best value for it? Does someone has an example patch, or something written somewhere? At least in the case of [readsf~] it is not that complicated. When opening the file (with the 'open' message), [readsf~] reads as much data from the file as fits into the given buffer. When finally playing the file, it doesn't have to wait for the disk to deliver the data as the data is accessible quickly from random access memory. Does you patch wait between opening the files and playing them? If not, try to open the files a short while before you play them, so that the buffers have time to fill. The sfread~s don't work all simultaneously, maybe maximum of 20 sfread~s might be working at the same time. To me it sounds like your disk is too slow to deliver the requested data in time. I found it is much more efficient to read from - for instance - 4 16-channel files than to read from 64 single-channel files. The latter causes much more seeks as the 64 files might be spread all over the disk. Of course, this is a non-issue if you have a SSD. I don't know about Windows, but in Linux usually recently read files are cached in the free areas of the memory. The second time you read those files, the harddisk isn't involved, provided there is enough free memory available which mitigates problems you describe. IIRC, I never had problems playing 80 channels at the same time, though I haven't tried with 80 separate single-channel files. And this is with a few years old hard-disks. Roman ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
[PD] Bang Your Head
Howdy all, I recently gave a Pd workshop and threw together a few examples with Roman Haefeli's awesome Basics.pd on Github: https://github.com/danomatika/BangYourHead Currently, most of the folders are stubs but I'm interested in adding to this over time. If anyone wants to collaborate on combining stuff, feel free to fork and make a pull request. I'm sure this isn't a new idea, but I'd like to have a simple goto fun example set to hook people that they can just download as a zip. Dan Wilcox @danomatika danomatika.com robotcowboy.com ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] sfread~ droupouts / understanding buffer parameter?
I have a patch with around 80 sfread~s, who read audio files between 8-16 seconds (each sfread reads always the same file). But I noticed that there are often enough small audio droupouts when running the patch. After adding a buffer value of 1e+6 (like in the help patch) the playback was better, but not yet perfect. There is no [sfread~] class in current Pd-extended (0.43.4). Do you have an older version of Pd-extended? From which library is that class? I can only find moonlib's [sfread2~] and zexy's [sfplay~] and, of course, the built-in [readsf~]. stupid, I use readsf~, not sfread~. Should have checked the patch. So I wanted to ask: how does the buffer parameter work exactly? How can one choose the best value for it? Does someone has an example patch, or something written somewhere? At least in the case of [readsf~] it is not that complicated. When opening the file (with the 'open' message), [readsf~] reads as much data from the file as fits into the given buffer. When finally playing the file, it doesn't have to wait for the disk to deliver the data as the data is accessible quickly from random access memory. So I could give as buffersize 705600, which is roughly the bit size of a 8s mono file with cd quality? This would avoid the problem for all smaller files with no prob? Or just set it to 1411200 - 16s, the longest duration? Does you patch wait between opening the files and playing them? If not, try to open the files a short while before you play them, so that the buffers have time to fill. for the time being it doesn't. When I wrote the patch this problem didn't happen before, although I did it in xp - now am using w7 and debian squeeze (the problem exists in both systems). The number of players is dynamic, maximum ~80. But this problem happens also when a different number of players are working. So I can't establish a direct correlation between number of active readsf and audio dropouts. The sfread~s don't work all simultaneously, maybe maximum of 20 sfread~s might be working at the same time. To me it sounds like your disk is too slow to deliver the requested data in time. I found it is much more efficient to read from - for instance - 4 16-channel files than to read from 64 single-channel files. The latter causes much more seeks as the 64 files might be spread all over the disk. Of course, this is a non-issue if you have a SSD. Yes. Restructuring the patch isn't an option in this case, the sound must be saved in different files. I don't know about Windows, but in Linux usually recently read files are cached in the free areas of the memory. The second time you read those files, the harddisk isn't involved, provided there is enough free memory available which mitigates problems you describe. IIRC, I never had problems playing 80 channels at the same time, though I haven't tried with 80 separate single-channel files. And this is with a few years old hard-disks. This is a rec-play piece, so the files should be read only once each time it is performed. Memory isn't a problem at all, as the total space in the disk is around 80Mb. João ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] sfread~ droupouts / understanding buffer parameter?
On Mon, 2013-04-08 at 12:03 +0200, João Pais wrote: I don't know about Windows, but in Linux usually recently read files are cached in the free areas of the memory. The second time you read those files, the harddisk isn't involved, provided there is enough free memory available which mitigates problems you describe. IIRC, I never had problems playing 80 channels at the same time, though I haven't tried with 80 separate single-channel files. And this is with a few years old hard-disks. This is a rec-play piece, so the files should be read only once each time it is performed. Memory isn't a problem at all, as the total space in the disk is around 80Mb. Well, then. I'd try to make the buffer of each [readsf~] instance as big as the file it plays. Give it enough time to pre-load data before playing and see if that helps. If you play the files only at original speed any way, you could alternatively load them to tables and play them with [tabplay~ ]. This way you can also be sure that they are played from memory and not from disk. Getting the tables loaded probably requires some trickery to avoid drop-outs at loading time. Roman ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] netserver issue
On Son, 2013-04-07 at 19:16 +0200, Jeppi Jeppi wrote: Hi all, Is there a limit of about 256 floats that be sent as a single message with [netserver]? I attach an example which makes pd explode as soon as the long message is sent with the client connected or not. [netserver] is from maxlib which has not really a maintainer anymore, as far as I know. This probably makes it unlikely it will get fixed. On the other hand, it's probably an easy fix to increase that buffer. On the long run, I wouldn't recommend using it. There is also [tcpserver] from iemnet which does not speak FUDI, but plain TCP and which is much more mature and still has a maintainer. There are many ways to make [netserver] block Pd completely (if not crash), especially if many clients connect to it - and all those issues are fixed in [iemnet/tcpserver]. Since [tcpserver] deals with plain bytes, you'd need to find a way to encapsulated your float numbers into the byte stream and also a way to delimit the so created packets. This would probably look like this: [osc/packOSC] | [slipenc 16384] | [list prepend send socket-no] | [list trim] | [iemnet/tcpserver port] | [slipdec 16384] | [osc/unpackOSC] This would allow you to send messages like: '/someaddress float1 float2 float3 ... float1000' The first argument given to [slipenc]/[slipdec] would define your maximum packet size. If so, would it be a way to allow for larger buffers? I haven't checked, but probably you'll find some buffersize definition in the source code. You could increase that value and re-compile. If I remember correctly, it is set to 4kB which matches with your experienced limit of 256 float numbers, if they are of the form 0.12345 (count the spaces between the numbers). Roman ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] flip image in glsl
Got it, thanks a lot! Colet Patrice - Mail original - De: Cyrille Henry c...@chnry.net À: Patrice Colet colet.patr...@free.fr Cc: pd-list pd-list@iem.at Envoyé: Lundi 8 Avril 2013 10:05:22 Objet: Re: [PD] flip image in glsl hello, when using rectangular texturing, coordinate goes from 0 to image pixel size. when using rectangle 0 mode, pixel coordinate goes from 0 to 1. (sometimes 1 is for the power of 2 bigger than the image pixel size) so, in rectangular mode, use pixetl_size - image coordinate to flip the image. and 1 - image coordinate in non rectangle mode. Image can be fliped because the fliped flag is not used on the shader. cheers c Le 08/04/2013 09:24, Patrice Colet a écrit : Hello, how is it possible to flip upside down an image in glsl example 05.multitexture I tried to implement this in fragment program: http://stackoverflow.com/questions/9857089/flip-upside-down-vertex-shader-gles but it doesn't work. The only thing I can do is changing texture scale and position, but I couldn't do it with negative values like it would be done in pix_coordinates. In fact when I use pix_multiimage before pix_texture, the image gets flipped, I don't know why... Colet Patrice ___ 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] flip image in glsl
I've implemented all the stuff for flipping horizontaly and verticaly,
there is an attached example, but it's not very elegant, there is warning
messages even if it works good, maybe there is a better way to do it?
Colet Patrice
- Mail original -
De: Patrice Colet colet.patr...@free.fr
À: pd-list pd-list@iem.at
Cc: Cyrille Henry c...@chnry.net
Envoyé: Lundi 8 Avril 2013 16:37:29
Objet: Re: [PD] flip image in glsl
Got it, thanks a lot!
Colet Patrice
- Mail original -
De: Cyrille Henry c...@chnry.net
À: Patrice Colet colet.patr...@free.fr
Cc: pd-list pd-list@iem.at
Envoyé: Lundi 8 Avril 2013 10:05:22
Objet: Re: [PD] flip image in glsl
hello,
when using rectangular texturing, coordinate goes from 0 to image
pixel size.
when using rectangle 0 mode, pixel coordinate goes from 0 to 1.
(sometimes 1 is for the power of 2 bigger than the image pixel
size)
so, in rectangular mode, use pixetl_size - image coordinate to flip
the image.
and 1 - image coordinate in non rectangle mode.
Image can be fliped because the fliped flag is not used on the
shader.
cheers
c
Le 08/04/2013 09:24, Patrice Colet a écrit :
Hello,
how is it possible to flip upside down an image in glsl example
05.multitexture
I tried to implement this in fragment program:
http://stackoverflow.com/questions/9857089/flip-upside-down-vertex-shader-gles
but it doesn't work. The only thing I can do is changing texture
scale and position, but I couldn't do it with negative values
like it would be done in pix_coordinates.
In fact when I use pix_multiimage before pix_texture, the image
gets flipped, I don't know why...
Colet Patrice
___
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
//jack/RYBN 2010
#extension GL_EXT_gpu_shader4 : enable
#extension GL_ARB_texture_rectangle : enable
uniform sampler2DRect Ttex1;
uniform sampler2DRect Ttex2;
uniform sampler2DRect Ttex3;
uniform sampler2DRect tex0;
uniform float style, target;
uniform float mix_factor, mix_color;
uniform float R, G, B, A;
uniform float FlipV1, FlipV2, FlipH1, FlipH2;
varying vec2 texcoord0;
ivec2 size1 = textureSize2DRect(Ttex1, 0);
ivec2 size2 = textureSize2DRect(Ttex2, 0);
ivec2 size3 = textureSize2DRect(Ttex3, 0);
ivec2 size0 = textureSize2DRect(tex0, 0);
vec2 texcoord1,texcoord2;
void main (void)
{
float sizeF1X = float(size1.x)/float(size0.x);
float sizeF1Y = float(size1.y)/float(size0.y);
float sizeF2X = float(size2.x)/float(size0.x);
float sizeF2Y = float(size2.y)/float(size0.y);
float sizeF3X = float(size3.x)/float(size0.x);
float sizeF3Y = float(size3.y)/float(size0.y);
if (FlipV1 == 0.) {
if (FlipH1 == 0.) {
texcoord1 = vec2(texcoord0.s*sizeF1X, texcoord0.t*sizeF1Y);
} else if (FlipH1 == 1.) {
texcoord1 = vec2(float(size1.x) - texcoord0.s*sizeF1X, texcoord0.t*sizeF1Y);
}
} else if (FlipV1 == 1.) {
if (FlipH1 == 0.) {
texcoord1 = vec2(texcoord0.s*sizeF1X,float(size1.y) - texcoord0.t*sizeF1Y);
} else if (FlipH1 == 1.) {
texcoord1 = vec2(float(size1.x) - texcoord0.s*sizeF1X,float(size1.y) - texcoord0.t*sizeF1Y);
}
}
if (FlipV2 == 0.) {
if (FlipH2 == 0.) {
texcoord2 = vec2(texcoord0.s*sizeF2X,texcoord0.t*sizeF2Y);
} else if (FlipH2 == 1.) {
texcoord2 = vec2(float(size2.x) - texcoord0.s*sizeF2X,texcoord0.t*sizeF2Y);
}
} else if (FlipV2 == 1.) {
if (FlipH2 == 0.) {
texcoord2 = vec2(texcoord0.s*sizeF2X,float(size2.y) - texcoord0.t*sizeF2Y);
} else if (FlipH2 == 1.) {
texcoord2 = vec2(float(size2.x) - texcoord0.s*sizeF2X,float(size2.y) - texcoord0.t*sizeF2Y);
}
}
vec4 color1 = texture2DRect(Ttex1, texcoord1);
vec4 color2 = texture2DRect(Ttex2, texcoord2);
vec4 color3 = vec4(R, G, B, A);
if (style == 0.) {
if (target == 0.) {
gl_FragColor = (color1 + color2);
} else if (target == 1.) {
gl_FragColor = (color1 + color3);
}
} else if (style == 1.) {
if (target == 0.) {
gl_FragColor = (color1 - color2);
} else if (target == 1.) {
gl_FragColor = (color1 - color3);
}
} else if (style == 2.) {
if (target == 0.) {
gl_FragColor = abs(color1 - color2);
} else if (target == 1.) {
gl_FragColor = abs(color1 - color3);
}
} else if (style == 3.) {
if (target == 0.) {
gl_FragColor = (color1 * color2);
} else if (target == 1.) {
gl_FragColor = (color1 * color3);
}
} else if (style == 4.) {
gl_FragColor = mix(color1,color2,mix_factor);
} else if (style == 5.) {
gl_FragColor = mix(mix(color1,color2,mix_factor),color3,mix_color);
}
}
//jack/RYBN 2010
varying vec2 texcoord0;
uniform float K1,K2,K3,K4;
void main()
{
texcoord0 =
[PD] Composition/Production Workshop, 4/14/13
Hey pd-list -- For those of you in/around NYC this weekend, this might be of interest: Composition/Production a workshop on the sound of music The Columbia University Computer Music Center is hosting a day-long workshop on issues arising from 'production': the impact of contemporary recording studio and digital-signal processing tools in crafting the sonic presentation of music. We will be especially focussing on the use of these tools, how they influence our musical creativity and the role recording technologies play in shaping the work we do. Towards that end, we have invited a group of musicians and researchers involved in music technology to help lead a community discussion of these issues. All are welcome to participate in this event. Sunday, April 14, 2013; 10:00 AM - 5:00 PM Computer Music Center, Columbia University Prentis Hall; 632 W. 125th Street, NY with: Ted Coffey, UVa Luke DuBois, NYU Tom Erbe, UCSD Brad Garton, CMC Darwin Grosse, Cycling '74 Terry Pender, CMC Todd Reynolds, MSM Gregory Taylor, Cycling '74 contact: gar...@columbia.edu free and open to the public ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
[PD] Control a USB fan from Pd
Hello everyone, Would anyone know how to control a USB fan from Pd? best, Jaime ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
