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.
hi thomas, hi all
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...
Yeah, this is a very known problem with the camera i have already asked Mark before, and he said something about having the camera object at a specified point in the rendering tree:: this is : having a GemList with a very low or high priority (i've forgotten which); you can modify the priority of the GemList by passing an argument to the gemhead:: eg: "gemhead 1" will be very high priority and therefore be rendered prior to anything else.
but however, i couldn't get this to work, no matter whether i used high or low or no prioriteis; the only way it does *anything* is by putting it on the top of a gemlist (as you described above - and this is really not very satisfying, since it only takes effect on the specified gemlist)
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) BUT:: unfortunately this is not very stable (at least not on Linux-boxes); if you are quick (for i hope, that i can applie a stable patch tomorrow) and in Vienna, you can have a look at the "Haus der Musik" and see Gem crashing every 15 minutes or so; on Win98 I had it work for a quite long time (12-24h) without any crash; Since it is so unstable I have decided to use "translate" and "rotate" objects for each Geo in the patch --- not very sophisticated...
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)
other unstability issues :: if i continue to "start"/"stop" the rendering engine, I will surely get Gem (and PD, of course) to crash after "some" times; this is very inconvenient and only on Linux
suddenly (and i can't remember of having changed anything in my configuration) pd will cause a segmentation fault, every time i quit it with having Gem loaded (without gem, the exit is fine as ever); first I thought that my patching of the library (the view... methods) is really wicked (which, by the way, it certainly is) but trying the original .dll from Mark produced the very same crash anybody experienced similarities ?
on Linux i get Pd crash (signal 11) everytime i destroy the GemWindow; i think this only appears when using nVidia's detonator drivers (i use kernel+GLX-0.9-3); with mesaGL I think destroying the window is as good as on WinXX-platforms (but I am not sure about this)
mfg.fds.tzh iohannes
if anybody is interested, i have put the (undocumented) sources on ftp://iem.mhsg.ac.at/pd/Externals/GEM/misc
mfg.fds.asdr iohannes
Hi all,
Pd currently insists on opening ALL MIDI input devices. This is probably not a good idea. Unless anyone thinks this is a bad idea, I'll kludge the next release so that the default is still to open them all but so that "-midiindev" specifies that it open one MIDI input device only...
cheers Miller
On Mon, Jul 10, 2000 at 11:30:19AM +0200, Thomas Loop wrote:
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.
Miller Puckette schrieb:
Hi all,
Pd currently insists on opening ALL MIDI input devices. This is probably not a good idea. Unless anyone thinks this is a bad idea, I'll kludge the next release so that the default is still to open them all but so that "-midiindev" specifies that it open one MIDI input device only...
cheers Miller
Hi Miller, hi all,
is there a similar behavior with audio outs in the WinNT version of Pd? I experienced problems trying to open two audio outs for four-chanel-output. I need to open device #2 and #4. If I start Pd with only specifying '-outchannels 4' pd tries to open device #0 and #0+1. Saying e.g. '-soundoutdev 2' pd tries to open devices #2 and #2+1.
Is there a way to tell Pd to open #2 and #4 ?
thanks Olaf
Sorry, Pd on NT and Linux/OSS only deals with consecutively numbered output devices. It sounds like a good idea to generalize this; I'll stick it on my (long) doilst...
cheers Miller
Hi Miller, hi all,
is there a similar behavior with audio outs in the WinNT version of Pd? I experienced problems trying to open two audio outs for four-chanel-output. I need to open device #2 and #4. If I start Pd with only specifying '-outchannels 4' pd tries to open device #0 and #0+1. Saying e.g. '-soundoutdev 2' pd tries to open devices #2 and #2+1.
Is there a way to tell Pd to open #2 and #4 ?
thanks Olaf