Pd-list July 2000

pd-list@lists.iem.at

30 participants
40 discussions

Various pd/gem Qs
by Thomas Loop 11 Jul '00

11 Jul '00

Hi, thanks for the numerous answers to my virtual midi dev question. Got it running. Initially I thought midiindev would be the plug INTO pd, but now I realized that midioutdev is the input. Not really intuitive, I think. Setting midiindev still doesn't work, by the way, so I can't output midistuff internally with pd. Some new questions: Don't know if I understand the camera object correctly. I only get it to work if I put it into a gemlist and then it only works for that single gemlist. Is it possible to get it working globally, for all gemlists and subpatches? The camera should influence the perspective of the complete scene, of course... Also I am having trouble with a pix_multiimage in a patch. The patch consists of one gemhead with 4 separators downstream that split to 4 squares. 2 of those squares get textured with a pix_multiimage, each. The 2 multiimage objects live on the same set of images. When adding the second multiimage the first one stops iterating through the images. Same metro, different counters for the 2 objects. It only shows the first image, while the second multiimage works just fine. Any ideas? Does multiimage work at all with split gemlists? Is there any documentation available concerning data structures and the use of pointers? Would it be possible to load images on events, flushing memory from previously loaded files while the patch is running? Lots of questions, hope they are not to trivial ... :-) Greetings. .loop.

4 5

Re: Unidentified Subject!
by x7.235450798263·i 11 Jul '00

11 Jul '00

|>>http://www.eusocial.com > >nato+decentmac = ca.3500EU into the corporate |throats of nn and apple. >not affordable, nor glücks- or freiheitsspendend. | | | |!ntel + konglomeratz = legal!szd murder + zlaver! | |ganz afordabl quak quak qu4k ... http://www.exploratorium.edu/frogs/tracker/index.html

1 0

RE: documentaion on gem++
by Mark Danks 10 Jul '00

10 Jul '00

I am glad to hear that someone else is able to give some answers, even if they are my bugs :-) The next rev of GEM will include the view messages, along with Johannes objects. I am expecting a release next Monday. Sorry for the slowness of the revs lately. I will also include a patch which explains how the camera object works. It is a little bit cryptic, I agree. Thomas, Can you send me a patch with pix_multiimage that works incorrectly? Just send a zip file to me with the patch and images. I will look at it. People have used pix_multiimage with _really_ complex patches and not had any problems. Later, Mark ============================ = mdanks(a)stormfront.com = Lead Programmer PS2 = http://www.danks.org/mark ============================ > -----Original Message----- > From: Johannes M Zmoelnig [mailto:zmoelnig@iem.mhsg.ac.at] > Sent: Monday, July 10, 2000 9:15 AM > To: Thomas Loop > Cc: pd-list(a)iem.mhsg.ac.at > Subject: documentaion on gem++ > > > > > On Mon, 10 Jul 2000, Thomas Loop wrote: > > > > > Hi Johannes, > > > > > > >therefore i have written a "view" method for the GemWin > object (which > > >controls the whole scenery and therefore seems to be predestined to > > >influence the viewing point of the whole scenery) which is > exactly what > > >you want (as i think) > > .... > > >on Win98 I had it work for a quite long time (12-24h) > without any crash; > > > > > > ah, maybe i promised too much :: i saw the whole thing crash on Win98 > after a view seconds on another machine than mine > (unfortunately, this was > the one machine that was supposed to perform in public...) > > > > > I am very interested, as I work on Win98 at the moment. > > > you really should change to anything else :-) > > > > > >I have also done a "fog" method and a material object > (although I lost > > >formatted my harddisk and lost the latter...but of course > I can do this > > >again if anybody get's interested) > > > > > > Again, sounds very interesting. > > Could you somehow publish the objects for Win98. > > It's a shame, but I'm a plain (l)user at the moment. No > compiler nor the > > knowledge to compile pd/gem objects. > > Guess the stuff is included in the gem++ tarball you > uploaded, right? > > > > ah for all those users that cannot afford microsofts > applications, i have > put a zip-file on our ftp-server, that provides only the gem.dll; > get it from ftp://iem.mhsg.ac.at/pd/Externals/GEM/misc , unpack it and > have fun. > > the gem++ tarball contains nothing but the sources > > > changing the viewport:: > send a message-list to the "gemwin"-object > "view <x_eye> <y_eye> <z_eye> [<azimuth> [<elevation>]" will put the > viewer onto the specified position looking into the specified > direction; > note that there may arise some unexpected behaviour, because > normally, the > viewer is located at (0/0/-4) or (0/0/+4) (cannot remember); i dunno > whether i add this offset internally; maybe you have to do it yourself > azimuth and elevation are both given in degree (this is 0..360); i did > this piece of code very rough and therefore the picture might flip > for 180deg when reaching an elevation of 90deg. This is > because I need not > deal with looking straight upwards/downwards in my specifique case... > > "view <x_eye> <y_eye> <z_eye> <x_center> <y_center> <z_center> <x_up> > <y_up> <z_up>" gives you total control over the used > gluLookAt -procedure; > the _eye coordinates are as above, the _center coordinates > define (nona) > the center of confusion, the up_coordinates define a vector > that is points > to your hat (and not to your mouth, cyclop !); of course the up_vector > must not be parallel to the viewing direction (center-eye) > > > changing the fog:: > "fog <density>" will change the density of the fog depending on which > exponential fogmode you use; the greater <density> is, the > denser the fog > becomes (gotit ?) > negative densities are truncated to no density > "fog <a> <b>" will modify the parameters for linear fog; > something like > "beginning and ending" of the fog range > "fogmode <n>" will switch between linear-fog (0), exponential-fog (1, > default) and exponential^2-fog(2) > "fogcolor <r> <g> <b>" sets the fogcolor > > > a disk-object > "disk": very similar to all other spheric-geos (cylinder, > cone, sphere) > > ah, next time i will do a documentation in the tar-balls, this will be > less effort. thought i would be faster this way ::--_ > > mfg.dfs.sdr > iohannes > > > > > > Thanks for your time and greetings, > > > > .loop. > > > > > >

1 0

documentaion on gem++
by Johannes M Zmoelnig 10 Jul '00

10 Jul '00

On Mon, 10 Jul 2000, Thomas Loop wrote: > > Hi Johannes, > > > >therefore i have written a "view" method for the GemWin object (which > >controls the whole scenery and therefore seems to be predestined to > >influence the viewing point of the whole scenery) which is exactly what > >you want (as i think) > .... > >on Win98 I had it work for a quite long time (12-24h) without any crash; > > ah, maybe i promised too much :: i saw the whole thing crash on Win98 after a view seconds on another machine than mine (unfortunately, this was the one machine that was supposed to perform in public...) > > I am very interested, as I work on Win98 at the moment. > you really should change to anything else :-) > > >I have also done a "fog" method and a material object (although I lost > >formatted my harddisk and lost the latter...but of course I can do this > >again if anybody get's interested) > > > Again, sounds very interesting. > Could you somehow publish the objects for Win98. > It's a shame, but I'm a plain (l)user at the moment. No compiler nor the > knowledge to compile pd/gem objects. > Guess the stuff is included in the gem++ tarball you uploaded, right? > ah for all those users that cannot afford microsofts applications, i have put a zip-file on our ftp-server, that provides only the gem.dll; get it from ftp://iem.mhsg.ac.at/pd/Externals/GEM/misc , unpack it and have fun. the gem++ tarball contains nothing but the sources changing the viewport:: send a message-list to the "gemwin"-object "view <x_eye> <y_eye> <z_eye> [<azimuth> [<elevation>]" will put the viewer onto the specified position looking into the specified direction; note that there may arise some unexpected behaviour, because normally, the viewer is located at (0/0/-4) or (0/0/+4) (cannot remember); i dunno whether i add this offset internally; maybe you have to do it yourself azimuth and elevation are both given in degree (this is 0..360); i did this piece of code very rough and therefore the picture might flip for 180deg when reaching an elevation of 90deg. This is because I need not deal with looking straight upwards/downwards in my specifique case... "view <x_eye> <y_eye> <z_eye> <x_center> <y_center> <z_center> <x_up> <y_up> <z_up>" gives you total control over the used gluLookAt -procedure; the _eye coordinates are as above, the _center coordinates define (nona) the center of confusion, the up_coordinates define a vector that is points to your hat (and not to your mouth, cyclop !); of course the up_vector must not be parallel to the viewing direction (center-eye) changing the fog:: "fog <density>" will change the density of the fog depending on which exponential fogmode you use; the greater <density> is, the denser the fog becomes (gotit ?) negative densities are truncated to no density "fog <a> <b>" will modify the parameters for linear fog; something like "beginning and ending" of the fog range "fogmode <n>" will switch between linear-fog (0), exponential-fog (1, default) and exponential^2-fog(2) "fogcolor <r> <g> <b>" sets the fogcolor a disk-object "disk": very similar to all other spheric-geos (cylinder, cone, sphere) ah, next time i will do a documentation in the tar-balls, this will be less effort. thought i would be faster this way ::--_ mfg.dfs.sdr iohannes > > Thanks for your time and greetings, > > .loop. > >

1 0

Re: Unidentified Subject!
by Thomas Loop 10 Jul '00

10 Jul '00

-----Original Message----- From: integer(a)www.god-emil.dk <integer(a)www.god-emil.dk> To: pd-list(a)iem.mhsg.ac.at <pd-list(a)iem.mhsg.ac.at> Date: Monday, July 10, 2000 11:53 AM Subject: Unidentified Subject! >!ntel arbe!t macht ganz gluckl!ch + fre! ja +? > >= peut etre = updat dze korporat ss html+!ntel zubz!d!szd m9nd konta!nr +? > >http://www.eusocial.com nato+decentmac = ca.3500EU into the corporate throats of nn and apple. not affordable, nor glücks- or freiheitsspendend. greets .loop.

1 0

None
by integer＠www.god-emil.dk 10 Jul '00

10 Jul '00

>Hi, d!v fuer dze ganze veLt >thanks for the numerous answers to my virtual midi dev question. >Got it running. Initially I thought midiindev would be the plug INTO pd, but now I realized that midioutdev is the input. >Not really intuitive, I think. Setting midiindev still doesn't work, by the way, so I can't output midistuff internally with pd. > >Some new questions: > >Don't know if I understand the camera object correctly. I only get it to work if I put it into a gemlist and then it only works for that single gemlist. >Is it possible to get it working globally, for all gemlists and subpatches? The camera should influence the perspective of the complete scene, of course... > >Also I am having trouble with a pix_multiimage in a patch. >The patch consists of one gemhead with 4 separators downstream that split to 4 squares. >2 of those squares get textured with a pix_multiimage, each. The 2 multiimage objects live on the same set of images. >When adding the second multiimage the first one stops iterating through the images. Same metro, different counters for the 2 objects. >It only shows the first image, while the second multiimage works just fine. >Any ideas? Does multiimage work at all with split gemlists? > >Is there any documentation available concerning data structures and the use of pointers? >Would it be possible to load images on events, flushing memory from previously loaded files while the patch is running? > >Lots of questions, hope they are not to trivial ... :-) > !ntel arbe!t macht ganz gluckl!ch + fre! ja +? = peut etre = updat dze korporat ss html+!ntel zubz!d!szd m9nd konta!nr +? http://www.eusocial.com - please apologize 4 dze FUTURE utop!az - n au!!!!!!!!!!!!!!!! motionless moz!on + uandrouz faze. ula. = uear do buterf!lez kom 4rom +? 4rom dreamz z!l! dze komun!ztz za! : komrad luvrz 4 ur helthz zake : k l o n e f r e e l + e pre.konssept!Øn meeTz ver!f1kat!Øn. > >Greetings. > > .loop. fr!endl! - Netochka Nezvanova f3.MASCHIN3NKUNST @www.eusocial.com 17.hzV.tRL.478 e | | +---------- | | < \\----------------+ | n2t | > e > ><!DOCTYPE HTML PUBLIC "-//W3C//DTD W3 HTML//EN"> ><HTML> ><HEAD> > ><META content=text/html;charset=iso-8859-1 http-equiv=Content-Type><!DOCTYPE HTML PUBLIC "-//W3C//DTD W3 HTML//EN"> ><META content='"MSHTML 4.72.3110.7"' name=GENERATOR> ></HEAD> ><BODY bgColor=#ffffff> ><DIV><FONT color=#000000 size=2>Hi,</FONT></DIV> ><DIV><FONT color=#000000 size=2></FONT> </DIV> ><DIV><FONT size=2>thanks for the numerous answers to my virtual midi dev >question.</FONT></DIV> ><DIV><FONT size=2>Got it running. Initially I thought midiindev would be the >plug INTO pd, but now I realized that midioutdev is the input.</FONT></DIV> ><DIV><FONT size=2>Not really intuitive, I think. Setting midiindev still doesn't >work, by the way, so I can't output midistuff internally with pd.</FONT></DIV> ><DIV><FONT size=2></FONT> </DIV> ><DIV><FONT size=2>Some new questions:</FONT></DIV> ><DIV><FONT size=2></FONT> </DIV> ><DIV><FONT color=#000000 size=2>Don't know if I understand the camera object >correctly. I only get it to work if I put it into a gemlist and then it only >works for that single gemlist.</FONT></DIV> ><DIV><FONT color=#000000 size=2></FONT><FONT size=2>Is it possible to get it >working globally, for all gemlists and subpatches? The camera should influence >the perspective of the complete scene, of course...</FONT></DIV> ><DIV><FONT size=2></FONT> </DIV> ><DIV><FONT color=#000000 size=2>Also I am having trouble with a pix_multiimage >in a patch. </FONT></DIV> ><DIV><FONT color=#000000 size=2></FONT><FONT size=2>The patch consists of one >gemhead with 4 separators downstream that split to 4 squares.</FONT></DIV> ><DIV><FONT size=2></FONT><FONT color=#000000 size=2>2 of those squares get >textured with a pix_multiimage, each. The 2 multiimage objects live on the same >set of images.</FONT></DIV> ><DIV><FONT color=#000000 size=2>When adding the second multiimage the first one >stops iterating through the images. Same metro, different counters for the 2 >objects.</FONT></DIV> ><DIV><FONT size=2>It only shows the first image, while the second multiimage >works just fine.</FONT></DIV> ><DIV><FONT color=#000000 size=2>Any ideas? Does multiimage work at all with >split gemlists?</FONT></DIV> ><DIV><FONT color=#000000 size=2></FONT> </DIV> ><DIV><FONT color=#000000 size=2>Is there any documentation available concerning >data structures and the use of pointers?</FONT></DIV> ><DIV><FONT color=#000000 size=2></FONT><FONT size=2>Would it be possible to load >images on events</FONT><FONT size=2>, flushing memory from previously loaded >files while the patch is running?</FONT></DIV> ><DIV> </DIV> ><DIV><FONT color=#000000 size=2>Lots of questions, hope they are not to trivial >... :-)</FONT></DIV> ><DIV> </DIV> ><DIV> </DIV> ><DIV><FONT size=2>Greetings.</FONT></DIV> ><DIV><FONT size=2></FONT> </DIV> ><DIV><FONT color=#000000 size=2>        >.loop.</FONT></DIV> ><DIV> </DIV></BODY></HTML>

1 0

8 channels on IRIX
by Søren Bovbjerg 08 Jul '00

08 Jul '00

Hi I have been trying to get 8 channel output with PD on IRIX. The machine is a Onyx2 with ADAT I/O running IRIX 6.5.6. So far I am only able to use 4 channels with PD, since the system return an error message if I try to open all 8 channels. The 8 channels DO work with VSS (Vanilla Sound Server) but we need something that is a little more 'interactive' ;-) Does anybody have experience with this type of hardware and PD? Is this problem related to PD? -or am I just missing a small - yet important - setting somewhere in the system setup? TIA Soeren

3 2

Virtual midi ports in pd?
by Thomas Loop 06 Jul '00

06 Jul '00

Does anybody know if pd-win is able to see virtual midiports? I'm trying to use Hubi's loopback device in Win98 to connect a sequencer software to pd. .loop.

2 1

stuff
by x7.72·- 06 Jul '00

06 Jul '00

http://barely.a.live.fm/pd/__/ -- ¯-ii·llt³t³¹¹+ 09677.41111t³t³

1 0

Re:Pd 0.31 test version with ALSA fix
by Linium 04 Jul '00

04 Jul '00

Miller Puckette a Ã©crit : > > Hi all, > > THere's a test release, pd-031TEST3.tar.gz, for linux only, on the web > site at > > http://www.crca.ucsd.edu/~msp/Software/ > > The main new thing is that ALSA is compiled in and seems to work OK with > both stereo and with one multichannel sound card (the Midiman.) I hope > this time that Pd with ALSA compiled in will also work on machines without > ALSA installed on them. > > If any of you want to check the ALSA support on your own machines I'd > be eager to hear how it goes. Hello, -Creative Labs Sbawe64 gold + Alsa 0.5.7: PD_ALSA: input doesn't support 4 byte samples; trying 2 PD_ALSA: can't find 4 or 2 byte format; giving up audio I/O stuck... closing audio and MIDI -Creative Labs Audio PCI (snd-card-ens1370) + Alsa 0.5.7 PD_ALSA: input doesn't support 4 byte samples; trying 2 Audio out works though, but in the example "Test audio and midi" if you put "audio in" ON you get a high pitched noise. midi doesn't seem to work -Creative Labs SBlive! + Alsa 0.5.8 PD_ALSA: input doesn't support 4 byte samples; trying 2 Audio out was intermintently cut and "audio in" ON produced some evil noise too. midi seems to work (IN and OUT) I will test 0.5.8b on all machines when I will have time to see if it improves. All machines: Mandrake 7.0 Linium

1 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

2003

2002

2001

2000

1999

1998

Pd-list July 2000