[PD] Pd-berlin meeting tomorrow, tuesday, 5th Jan

2010-01-04 Thread João Pais

Hello,

tomorrow, tuesday, 5th January, will be the second meeting of Pure Data  
users in Berlin.


For more information, look up
http://puredata.info/community/organization/pd-berlin/pd-berlin-users-group.


Doors are open from 20h-20h15. After that they'll be probably closed, and
you will have to call someone at NK to get in. To get a telephone number
to call or confirm assistance you can write to info_at_minitronics.net.

We would apreciate if you would send us a small mail to
info_at_minitronics.net with your name, Pd experience and interests, so
that we know how many people might be coming. Or put your name in the
pd-berlin wiki page.


We would like to thank the support and willingness of NK in the
organization of these events.

João Pais


--
Friedenstr. 58
10249 Berlin (Deutschland)
Tel +49 30 42020091 | Mob +49 162 6843570
Studio +49 30 69509190
jm...@gmx.net | skype: jmmmpjmmmp

___
Pd-list@iem.at mailing list
UNSUBSCRIBE and account-management - 
http://lists.puredata.info/listinfo/pd-list


[PD] live coding festival in newcastle, uk?

2010-01-04 Thread alex
Hi all and happy new year,

I'm looking into the possibility of running a live coding festival in
Newcastle later this year.  To be supported it would need to be a bit
bigger than previous events dedicated to live coding - 100+ .  It
would include performances, talks and beginners workshops.  So I'm
gauging interest - if you would be interested in coming to such a
thing, please add yourself on this wiki page:

 http://toplap.org/index.php/Newcastle2010

You don't have to sign up to anything - just click 'edit' and add your
name to the list.  You won't be committing to anything, but your
interest would be helping make it happen!

For those unfamiliar with live coding, there's a bit of info here:
 http://toplap.org/uk/about/

Thanks very much,

alex

-- 
http://yaxu.org/

___
Pd-list@iem.at mailing list
UNSUBSCRIBE and account-management - 
http://lists.puredata.info/listinfo/pd-list


[PD] GEM/GLSL how to compute correct texture coordinates for non-power-of-two images

2010-01-04 Thread Matteo Sisti Sette

Hi,

The subject resembles very much that of one recent message of mine but 
it is NOT the same.


I think it's better to start a new thread because the previous one was 
erroneously focused on rectangle textures: I was suggested to use them 
to solve a problem I mentioned, and though I do appreciate very much the 
suggestion, it actually pointed me to the wrong direction.


So, I have learned that when you use an image as a texture (be it loaded 
from file, generated by camera input or by a pixsnap), the texture 
internally has power-of-two dimensions greater than or equal to the 
actual dimensions of the image, the rest being padded with black or 
something.


Then, I've seen that even if I use a shader, I usually don't have to 
worry about that IF the [pix_image] (or [pix_video] or whatever) that 
generates the image is in the same line (of left-inlet connections) as 
the [pix_texture] and the [glsl_program].
That is, when in the shader I use gl_TexCoord[0].st to sample the 
texture, I get the right coordinates.


So, the 01 simple texture patch in the example folder works fine with 
non-power-of-two-sized images with no need to be changed, and without 
using rectangular texture mode.


However, as the attached patch shows, this is no more true if I use a 
uniform variable to tell the shader to use a given texture unit N, which 
correspond to some [pix_texture] object which is connected to another 
separate [gemhead] and which has been sent a [texunit N( message.


So what I understand is that [pix_image] (or any object that creates a 
pix and translates it into a texture) takes care of it by doing some 
kind of OpenGL magic so that the texture coordinates being passed to 
the shader are OK with no need to take care of that in the shader code.


The aritmetical part of this magic is indeed as simple as computing a 
scale factor of W/Nw for width and H/Nh for height, where W and H are 
width and height, and Nw and Nh are the next power of two equal to or 
greater than W and H respectively.


The question is, what's the best way (if there is any) to reproduce 
the magic that the pix objects do, in order to pre-compute this scale 
factor and have the shader receive correctly 'normalized' coordinates?


I mean, I can calculate the scaling factor and pass it through a uniform 
variable to the shader, and have the shader use it to rescale the 
coordinates. This will work fine, but it seems (to me) that [pix_image] 
and other pix objects are able to do this kind of rescaling somehow 
_before_ the shader gets in action, since you don't need to change the 
shader code if such an object (which is generating the image) is present 
in the chain.



I hope I have explained the question clearly.
The attached patch shows the problem quite well I think. I don't attach 
the images to avoid flooding mailboxes; any non-power-of-two different 
sized images with those names will do; by the way I have attached them 
in a recent message of mine.
Compare the behaviour to that of example 01 of the GLSL example folder: 
even with a non-pot-sized image, that example works fine.


Note that no rectangular textures are involved. Rectangular textures 
won't help (indeed I think it gets more complicated): I have the same 
problem because I need to tell the shader the actual size of the 
texture it has to use.



Thanks a lot in advance
m.


P.S. though I can't promise it, it's almost sure that I will post and 
share the final patches, for what it's worth; but I can't do it yet.


--
Matteo Sisti Sette
matteosistise...@gmail.com
http://www.matteosistisette.com
uniform sampler2D curtex;

void main (void)
{
 vec2 xy=gl_TexCoord[0].st;

 vec4 frontcolor = texture2D(curtex, xy);
 
 gl_FragColor = frontcolor;
 
}
// Cyrille Henry 2007
void main()
{
gl_TexCoord[0] = gl_MultiTexCoord0;
gl_Position = ftransform();

}

#N canvas 399 97 925 656 12;
#X obj 441 576 gemwin;
#X msg 437 515 create \, 1;
#X msg 484 547 destroy;
#X obj 58 177 glsl_vertex;
#X obj 59 313 glsl_fragment;
#X obj 143 211 change;
#X obj 160 342 change;
#X obj 155 385 t b f;
#X obj 153 418 pack 0 0;
#X obj 60 490 glsl_program;
#X msg 154 454 link \$1 \$2;
#X obj 60 567 pix_texture;
#X obj 187 69 bng 15 250 50 0 empty empty empty 17 7 0 10 -262144 -1
-1;
#X obj 69 33 gemhead 50;
#X obj 508 77 gemhead 23;
#X obj 511 259 pix_texture;
#X msg 519 221 texunit 1;
#X obj 664 260 pix_texture;
#X obj 661 78 gemhead 24;
#X floatatom 212 525 5 0 0 0 - - -;
#X obj 70 60 t a a;
#X obj 348 384 loadbang;
#X obj 762 53 loadbang;
#X obj 60 600 square 4;
#X obj 565 383 pix_image img1_.jpg;
#X obj 506 163 pix_image img2_.jpg;
#X obj 659 164 pix_image img3_.jpg;
#X msg 278 474 texunit 2;
#X msg 672 222 texunit 0;
#X floatatom 253 333 5 0 0 0 - - -;
#X msg 229 387 curtex \$1;
#X msg 136 99 open trivialshader_norec.vert;
#X msg 114 259 open trivialshader_norec.frag;
#X obj 584 313 gemhead 23;
#X obj 587 495 pix_texture;
#X msg 595 457 texunit 2;
#X obj 185 42 loadbang;
#X connect 1 0 0 0;

Re: [PD] gem/GLSL: how to compute correct coordinates for rectangular textures

2010-01-04 Thread Jack
Le dimanche 03 janvier 2010 à 21:17 +0100, Matteo Sisti Sette a écrit :
 Hi,
 
 I guess if I had a deep understanding of openGL I could find the answer, 
 but I am obviously looking for a shortcut (at the moment) to solve the 
 specific problem I'm facing which should be pretty simple.
 
 In the attached patch I try to use a trivial shader to texture a 
 rectangle with an image; the uniform variable curtex tells the shader 
 which texture to use.
 
 It works fine if all images have the same size; however, if the textures 
 have different sizes, no matter the value of curtex, the texture 
 coords that are computed are correct for the image loaded by the 
 [pix_image] that immediately follows the [glsl_program], but are not 
 correct for other images.
 
 So the question is: how should I change the vertex and/or fragment 
 shader code (or the patch maybe) so that the texture coordinates are 
 computed according to the dimensions of the texture that is actually 
 sampled?
 
 It is important to NOT assume that the textures come from [pix_image] 
 objects, or at least, that they are loaded from image files: actually, 
 in real life, textures may be the video input generated by a [pix_film] 
 or an image captured by a [pix_snap].
What about [pix_resize] after [pix_image] ?
++

Jack


 
 
 Thanks a lot in advance
 
 pièce jointe document texte brut (trivialshader.frag)
 // porcodio
 
 #extension GL_ARB_texture_rectangle : enable
 uniform sampler2DRect curtex;
 
 void main (void)
 {
  vec2 xy=gl_TexCoord[0].st;
 
  vec4 frontcolor = texture2DRect(curtex, xy);
  
  gl_FragColor = frontcolor;
  
 }
 pièce jointe document texte brut (test_trivial_shader.pd)
 #N canvas 443 93 925 656 12;
 #X obj 441 576 gemwin;
 #X msg 437 515 create \, 1;
 #X msg 484 547 destroy;
 #X obj 58 177 glsl_vertex;
 #X obj 59 313 glsl_fragment;
 #X obj 143 211 change;
 #X obj 160 342 change;
 #X obj 155 385 t b f;
 #X obj 153 418 pack 0 0;
 #X obj 60 490 glsl_program;
 #X msg 154 454 link \$1 \$2;
 #X obj 60 567 pix_texture;
 #X obj 188 24 bng 15 250 50 0 empty empty empty 17 7 0 10 -262144 -1
 -1;
 #X obj 69 33 gemhead 50;
 #X obj 508 77 gemhead 23;
 #X obj 511 259 pix_texture;
 #X msg 519 221 texunit 1;
 #X obj 664 260 pix_texture;
 #X obj 661 78 gemhead 24;
 #X floatatom 212 525 5 0 0 0 - - -;
 #X obj 70 60 t a a;
 #X msg 349 409 rectangle 1;
 #X obj 348 384 loadbang;
 #X msg 757 119 rectangle 1;
 #X obj 762 53 loadbang;
 #X msg 136 99 open trivialshader.vert;
 #X msg 114 259 open trivialshader.frag;
 #X obj 60 600 square 4;
 #X obj 46 528 pix_image img1_.jpg;
 #X obj 506 163 pix_image img2_.jpg;
 #X obj 659 164 pix_image img3_.jpg;
 #X msg 278 474 texunit 2;
 #X msg 672 222 texunit 0;
 #X floatatom 253 333 5 0 0 0 - - -;
 #X msg 229 387 curtex \$1;
 #X connect 1 0 0 0;
 #X connect 2 0 0 0;
 #X connect 3 0 4 0;
 #X connect 3 1 5 0;
 #X connect 4 0 9 0;
 #X connect 4 1 6 0;
 #X connect 5 0 8 0;
 #X connect 6 0 7 0;
 #X connect 7 0 8 0;
 #X connect 7 1 8 1;
 #X connect 8 0 10 0;
 #X connect 9 0 28 0;
 #X connect 9 1 19 0;
 #X connect 10 0 9 0;
 #X connect 11 0 27 0;
 #X connect 12 0 25 0;
 #X connect 12 0 26 0;
 #X connect 13 0 20 0;
 #X connect 14 0 29 0;
 #X connect 16 0 15 0;
 #X connect 18 0 30 0;
 #X connect 20 0 3 0;
 #X connect 21 0 11 0;
 #X connect 22 0 21 0;
 #X connect 22 0 31 0;
 #X connect 23 0 17 0;
 #X connect 23 0 15 0;
 #X connect 24 0 23 0;
 #X connect 24 0 32 0;
 #X connect 24 0 16 0;
 #X connect 25 0 3 0;
 #X connect 26 0 4 0;
 #X connect 28 0 11 0;
 #X connect 29 0 15 0;
 #X connect 30 0 17 0;
 #X connect 31 0 11 0;
 #X connect 32 0 17 0;
 #X connect 33 0 34 0;
 #X connect 34 0 9 0;
 ___
 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] Which pd-extended on Jaunty (64)?

2010-01-04 Thread Hans-Christoph Steiner


I don't think anyone really likes dealing with build issues, but  
someone has to do it :-D.  I was thinking that we should make a pd- 
extended PPA on Ubuntu's Launchpad.  Then we can get i386, amd64, and  
lpia builds from their servers.  That means making a Pd-extended  
Debian source package.  Anyone want to take it on?


.hc

On Jan 3, 2010, at 12:58 PM, András Murányi wrote:


Hi All,

After my Odyssey (with your support) to compile extended on amd64 I  
still had some basic problems with it, namely:

- Didn't like each other with the gui-rewrite
- The GUI was very slow!
...so I decided to try an i386 autobuild, but Pd-0.42.5-extended- 
ubuntu-jaunty-i386.deb throws this error:


Application initialization failed: Can't find a usable init.tcl in  
the following directories:
/usr/lib/pd/tcl/library /usr/share/tcltk/tcl8.5 ./lib/tcl8.5 ./ 
lib/tcl8.5 ./library ./library ./tcl8.5.0/library ./tcl8.5.0/library


/usr/share/tcltk/tcl8.5/init.tcl: version conflict for package  
Tcl: have 8.5.0, need exactly 8.5.6

version conflict for package Tcl: have 8.5.0, need exactly 8.5.6
while executing
package require -exact Tcl 8.5.6
(file /usr/share/tcltk/tcl8.5/init.tcl line 20)
invoked from within
source /usr/share/tcltk/tcl8.5/init.tcl
(uplevel body line 1)
invoked from within
uplevel #0 [list source $tclfile]

This probably means that Tcl wasn't installed properly.

Now my Tcl is 8.5.6, had even reinstalled it.

To tell you the truth, I'm not so much into compiling or doing  
tricks now*, I just want to get my hands on a well working copy and  
make music.


Can you give me some advice? Jaunty, amd64.

Thanks, Andras

*because I got the cold :o/
___
Pd-list@iem.at mailing list
UNSUBSCRIBE and account-management - 
http://lists.puredata.info/listinfo/pd-list






The arc of history bends towards justice. - Dr. Martin Luther  
King, Jr.



___
Pd-list@iem.at mailing list
UNSUBSCRIBE and account-management - 
http://lists.puredata.info/listinfo/pd-list


[PD] Minimize Pure Data under Linux

2010-01-04 Thread tep
Hi,
is there a simple way to tell Pure Data to minimize in system tray under
Linux ?

-- 
Nico / tep
___
Pd-list@iem.at mailing list
UNSUBSCRIBE and account-management - 
http://lists.puredata.info/listinfo/pd-list


Re: [PD] Minimize Pure Data under Linux

2010-01-04 Thread patrick

not in system tray, but minimize yes:

[loadbang]
|
[wm iconify .
|
[sys_gui]

___
Pd-list@iem.at mailing list
UNSUBSCRIBE and account-management - 
http://lists.puredata.info/listinfo/pd-list


Re: [PD] Minimize Pure Data under Linux

2010-01-04 Thread Hans-Christoph Steiner


Using a mouse click on the minimize button?  Or do you mean using a Pd  
message?


.hc

On Jan 4, 2010, at 4:36 PM, tep wrote:


Hi,
is there a simple way to tell Pure Data to minimize in system tray  
under Linux ?


--
Nico / tep
___
Pd-list@iem.at mailing list
UNSUBSCRIBE and account-management - 
http://lists.puredata.info/listinfo/pd-list






The arc of history bends towards justice. - Dr. Martin Luther  
King, Jr.




___
Pd-list@iem.at mailing list
UNSUBSCRIBE and account-management - 
http://lists.puredata.info/listinfo/pd-list


Re: [PD] 'relocate' message

2010-01-04 Thread Hans-Christoph Steiner


On Jan 4, 2010, at 1:50 AM, Hans-Christoph Steiner wrote:



On Jan 3, 2010, at 1:14 AM, Hans-Christoph Steiner wrote:



On Jan 2, 2010, at 8:22 PM, Jonathan Wilkes wrote:




--- On Sun, 1/3/10, Hans-Christoph Steiner h...@at.or.at wrote:


From: Hans-Christoph Steiner h...@at.or.at
Subject: [PD] 'relocate' message
To: Pd List pd-list@iem.at
Date: Sunday, January 3, 2010, 12:00 AM

Is anyone using the 'relocate' message to move/resize
windows in Pd?  I ask because I want to simplify that
code and the message itself in pd-gui-rewrite 0.43.
Its currently a very strange format, and it no longer needs
to be.

Here's the only working example that I know of:
http://pure-data.svn.sourceforge.net/viewvc/pure-data/trunk/doc/additional/pd-msg/1.msg_and_patch/6.relocate_windows..pd?view=log

The idea is to make the message like this:

relocate   WIDTHxHEIGHT+XLoc+YLoc

Currently its like this:

relocate   WIDTHxHEIGHT+0+0
0x0+XLoc+YLoc

.hc


Hi Hans,
 Is there a reason the message can't simply be relocate WIDTH  
HEIGHT
XLoc Yloc?  Whether using pd-ext or vanilla, I've always thought  
it seems

really awkward to cram the coordinates into one big symbol.

-Jonathan



Hmm, that makes sense. I wonder if this should just have the same  
syntax as 'canvas', so:


relocate x1 y1 x2 y2

Where x is the upper left corner, and y is the lower right corner.



So I restored the old relocate message, and added a new message  
which the GUI now uses a new message 'whxy'.  'whxy' stands for  
Width/Height/X/Y.  Width/Height is the size of the window, and (x,y)  
is where the upper-left corner is located:


whxy width height xPosition yPosition
whxy 450 300 0 22

I am now thinking that perhaps I should make it called 'setbounds'  
after the old internal function, and make it mirror that:


   canvas_setbounds(x, xpos, ypos, xpos + width, ypos + height);

i.e. setbounds Xleft Ytop Xright Ybottom


After a little discussion with Miller, this one seems to make the most  
sense, so this is what the pd-gui-rewrite uses now.


http://pure-data.svn.sourceforge.net/viewvc/pure-data?view=revrevision=12883

.hc




If you are not part of the solution, you are part of the problem.



___
Pd-list@iem.at mailing list
UNSUBSCRIBE and account-management - 
http://lists.puredata.info/listinfo/pd-list


Re: [PD] Minimize Pure Data under Linux

2010-01-04 Thread Hans-Christoph Steiner


David Shimamoto recently announced an external to control the Windows  
system tray... check the archives.


.hc

On Jan 4, 2010, at 5:35 PM, patrick wrote:


not in system tray, but minimize yes:

[loadbang]
|
[wm iconify .
|
[sys_gui]

___
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


Re: [PD] 'relocate' message

2010-01-04 Thread Jonathan Wilkes


--- On Tue, 1/5/10, Hans-Christoph Steiner h...@at.or.at wrote:

 From: Hans-Christoph Steiner h...@at.or.at
 Subject: Re: [PD] 'relocate' message
 To: Jonathan Wilkes jancs...@yahoo.com, PD List pd-list@iem.at
 Date: Tuesday, January 5, 2010, 12:26 AM
 
 On Jan 4, 2010, at 1:50 AM, Hans-Christoph Steiner wrote:
 
  
  On Jan 3, 2010, at 1:14 AM, Hans-Christoph Steiner
 wrote:
  
  
  On Jan 2, 2010, at 8:22 PM, Jonathan Wilkes
 wrote:
  
  
  
  --- On Sun, 1/3/10, Hans-Christoph Steiner
 h...@at.or.at
 wrote:
  
  From: Hans-Christoph Steiner h...@at.or.at
  Subject: [PD] 'relocate' message
  To: Pd List pd-list@iem.at
  Date: Sunday, January 3, 2010, 12:00 AM
  
  Is anyone using the 'relocate' message to
 move/resize
  windows in Pd?  I ask because I want
 to simplify that
  code and the message itself in
 pd-gui-rewrite 0.43.
  Its currently a very strange format, and
 it no longer needs
  to be.
  
  Here's the only working example that I
 know of:
  http://pure-data.svn.sourceforge.net/viewvc/pure-data/trunk/doc/additional/pd-msg/1..msg_and_patch/6.relocate_windows..pd?view=log
  
  The idea is to make the message like
 this:
  
 
 relocate   WIDTHxHEIGHT+XLoc+YLoc
  
  Currently its like this:
  
 
 relocate   WIDTHxHEIGHT+0+0
  0x0+XLoc+YLoc
  
  .hc
  
  Hi Hans,
   Is there a reason the message can't
 simply be relocate WIDTH HEIGHT
  XLoc Yloc?  Whether using pd-ext or
 vanilla, I've always thought it seems
  really awkward to cram the coordinates into
 one big symbol..
  
  -Jonathan
  
  
  Hmm, that makes sense. I wonder if this should
 just have the same syntax as 'canvas', so:
  
  relocate x1 y1 x2 y2
  
  Where x is the upper left corner, and y is the
 lower right corner.
  
  
  So I restored the old relocate message, and added a
 new message which the GUI now uses a new message
 'whxy'.  'whxy' stands for Width/Height/X/Y. 
 Width/Height is the size of the window, and (x,y) is where
 the upper-left corner is located:
  
  whxy width height xPosition yPosition
  whxy 450 300 0 22
  
  I am now thinking that perhaps I should make it called
 'setbounds' after the old internal function, and make it
 mirror that:
  
     canvas_setbounds(x, xpos, ypos, xpos +
 width, ypos + height);
  
  i.e. setbounds Xleft Ytop Xright Ybottom
 
 After a little discussion with Miller, this one seems to
 make the most sense, so this is what the pd-gui-rewrite uses
 now.
 
 http://pure-data.svn.sourceforge.net/viewvc/pure-data?view=revrevision=12883

That's great.  I think setbounds is a much better name than relocate; 
it has a straightforward connection to the arguments (unlike relocate).

Is there any way to have the iemgui messages pos and delta for 
canvases?  For example, if I have a canvas with a bunch of subpatches 
that all have different sizes, but I want to move them all up to the 
top left-hand corner or the screen, pos 0 0 would be really handy.

-Jonathan


  


___
Pd-list@iem.at mailing list
UNSUBSCRIBE and account-management - 
http://lists.puredata.info/listinfo/pd-list


Re: [PD] pdp_qt problems

2010-01-04 Thread Hans-Christoph Steiner


Hey Ed,

Happy New Year!  Hmm, did it work before?  Have you tried a nightly  
build?  I'll take a look.  pdp_qt and libquicktime are a finicky  
combo.  Try pdp_yqt perhaps.


.hc

On Jan 4, 2010, at 8:48 PM, Ed Kelly wrote:


Hi all,

I'm trying to get something together for the Jan 7 deadline - and  
I've discovered that pdp_qt no longer loads my quicktime movies.

All the movies are h.263 codec, quicktime files.

I'm using Ubuntu 8.10, Pd-extended-0.41. I tried recompiling pdp  
from source and still no joy. But this is exactly the same setup as  
I used before, but a different computer! Any clues?


pdp_qt: opening Shapes_51.mov
pdp_qt: ERROR: not a quicktime file

Enclosed - load test.pd

Happy new year to all,
Ed
Metastudio 3 for Pure Data - Free download at:
http://sharktracks.co.uk/puredata


pdpqt__.tar.gz___
Pd-list@iem.at mailing list
UNSUBSCRIBE and account-management - 
http://lists.puredata.info/listinfo/pd-list








'You people have such restrictive dress for women,’ she said, hobbling  
away in three inch heels and panty hose to finish out another pink- 
collar temp pool day.  - “Hijab Scene #2, by Mohja Kahf




___
Pd-list@iem.at mailing list
UNSUBSCRIBE and account-management - 
http://lists.puredata.info/listinfo/pd-list


Re: [PD] pdp_qt problems

2010-01-04 Thread Hans-Christoph Steiner


Try the pdp_qt help patch.  Your patch doesn't work for me, but the  
help patch does work with the video.


Also, I just committed a change to pdp_qt.c to make its errors  
findable via the Find-Find last error menu.


.hc

On Jan 4, 2010, at 10:17 PM, Hans-Christoph Steiner wrote:



Hey Ed,

Happy New Year!  Hmm, did it work before?  Have you tried a nightly  
build?  I'll take a look.  pdp_qt and libquicktime are a finicky  
combo.  Try pdp_yqt perhaps.


.hc

On Jan 4, 2010, at 8:48 PM, Ed Kelly wrote:


Hi all,

I'm trying to get something together for the Jan 7 deadline - and  
I've discovered that pdp_qt no longer loads my quicktime movies.

All the movies are h.263 codec, quicktime files.

I'm using Ubuntu 8.10, Pd-extended-0.41. I tried recompiling pdp  
from source and still no joy. But this is exactly the same setup as  
I used before, but a different computer! Any clues?


pdp_qt: opening Shapes_51.mov
pdp_qt: ERROR: not a quicktime file

Enclosed - load test.pd

Happy new year to all,
Ed
Metastudio 3 for Pure Data - Free download at:
http://sharktracks.co.uk/puredata


pdpqt__.tar.gz___
Pd-list@iem.at mailing list
UNSUBSCRIBE and account-management - 
http://lists.puredata.info/listinfo/pd-list








'You people have such restrictive dress for women,’ she said,  
hobbling away in three inch heels and panty hose to finish out  
another pink-collar temp pool day.  - “Hijab Scene #2, by Mohja Kahf









Using ReBirth is like trying to play an 808 with a long stick.- 
David Zicarelli




___
Pd-list@iem.at mailing list
UNSUBSCRIBE and account-management - 
http://lists.puredata.info/listinfo/pd-list


Re: [PD] pdp_qt problems

2010-01-04 Thread ydego...@gmail.com

ola,

no problem here with your patch ...
must be a libquicktime issue ...
you have to install libauicktime-dev before compiling pdp,
if not you don't have quicktime support

and check if you have :
ls /usr/lib/libquicktime1/
lqt_audiocodec.so  lqt_dv.so  lqt_faad2.so  lqt_ffmpeg.so  lqt_mjpeg.so  
lqt_png.so  lqt_rtjpeg.so  lqt_videocodec.so  lqt_vorbis.so


the codecs

ciao,
sevy

Ed Kelly wrote:

Hi all,

I'm trying to get something together for the Jan 7 deadline - and I've 
discovered that pdp_qt no longer loads my quicktime movies.
All the movies are h.263 codec, quicktime files.

I'm using Ubuntu 8.10, Pd-extended-0.41. I tried recompiling pdp from source 
and still no joy. But this is exactly the same setup as I used before, but a 
different computer! Any clues?

pdp_qt: opening Shapes_51.mov
pdp_qt: ERROR: not a quicktime file

Enclosed - load test.pd

Happy new year to all,
Ed
Metastudio 3 for Pure Data - Free download at:
http://sharktracks.co.uk/puredata


  



___
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] 'relocate' message

2010-01-04 Thread Hans-Christoph Steiner


On Jan 4, 2010, at 7:16 PM, Jonathan Wilkes wrote:




--- On Tue, 1/5/10, Hans-Christoph Steiner h...@at.or.at wrote:


From: Hans-Christoph Steiner h...@at.or.at
Subject: Re: [PD] 'relocate' message
To: Jonathan Wilkes jancs...@yahoo.com, PD List pd- 
l...@iem.at

Date: Tuesday, January 5, 2010, 12:26 AM

On Jan 4, 2010, at 1:50 AM, Hans-Christoph Steiner wrote:



On Jan 3, 2010, at 1:14 AM, Hans-Christoph Steiner

wrote:




On Jan 2, 2010, at 8:22 PM, Jonathan Wilkes

wrote:





--- On Sun, 1/3/10, Hans-Christoph Steiner

h...@at.or.at
wrote:



From: Hans-Christoph Steiner h...@at.or.at
Subject: [PD] 'relocate' message
To: Pd List pd-list@iem.at
Date: Sunday, January 3, 2010, 12:00 AM

Is anyone using the 'relocate' message to

move/resize

windows in Pd?  I ask because I want

to simplify that

code and the message itself in

pd-gui-rewrite 0.43.

Its currently a very strange format, and

it no longer needs

to be.

Here's the only working example that I

know of:

http://pure-data.svn.sourceforge.net/viewvc/pure-data/trunk/doc/additional/pd-msg/1..msg_and_patch/6.relocate_windows..pd?view=log

The idea is to make the message like

this:




relocate   WIDTHxHEIGHT+XLoc+YLoc


Currently its like this:



relocate   WIDTHxHEIGHT+0+0

0x0+XLoc+YLoc

.hc


Hi Hans,
  Is there a reason the message can't

simply be relocate WIDTH HEIGHT

XLoc Yloc?  Whether using pd-ext or

vanilla, I've always thought it seems

really awkward to cram the coordinates into

one big symbol..


-Jonathan



Hmm, that makes sense. I wonder if this should

just have the same syntax as 'canvas', so:


relocate x1 y1 x2 y2

Where x is the upper left corner, and y is the

lower right corner.



So I restored the old relocate message, and added a

new message which the GUI now uses a new message
'whxy'.  'whxy' stands for Width/Height/X/Y.
Width/Height is the size of the window, and (x,y) is where
the upper-left corner is located:


whxy width height xPosition yPosition
whxy 450 300 0 22

I am now thinking that perhaps I should make it called

'setbounds' after the old internal function, and make it
mirror that:


canvas_setbounds(x, xpos, ypos, xpos +

width, ypos + height);


i.e. setbounds Xleft Ytop Xright Ybottom


After a little discussion with Miller, this one seems to
make the most sense, so this is what the pd-gui-rewrite uses
now.

http://pure-data.svn.sourceforge.net/viewvc/pure-data?view=revrevision=12883


That's great.  I think setbounds is a much better name than  
relocate;
it has a straightforward connection to the arguments (unlike  
relocate).


Is there any way to have the iemgui messages pos and delta for
canvases?  For example, if I have a canvas with a bunch of subpatches
that all have different sizes, but I want to move them all up to the
top left-hand corner or the screen, pos 0 0 would be really handy.



The first two values of 'setbounds' are the same as 'pos', they are  
the upper left corner.  But you have to also set the   lower right  
too.  This message is not really meant to be used a lot externally.   
Its really a direct mapping of the data that Tk gives to the format  
that Pd saves in the .pd file.  Plus 'setbounds' doesn't even take  
effect until you close and open the patch again.


.hc



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