hi
3 things I already noticed in TEST7:
- the table object cannot be opened anymore. is this intentional?
- should writesf with 2 channels produce a stereo file? if so, this doesn't
seem to work: I get a mono file albeit of double length (in bytes: a 1 sec file is 88200 bytes long)
- vcf~ makes pd exit
mik
Sorry for the delay in replying to this...
All three things seem to be broken in 0.32; I can fix the first one but the other two might take me some more time..
On Wed, Nov 29, 2000 at 12:50:59AM +0100, mik wrote:
hi
3 things I already noticed in TEST7:
- the table object cannot be opened anymore. is this intentional?
- should writesf with 2 channels produce a stereo file? if so, this doesn't
seem to work: I get a mono file albeit of double length (in bytes: a 1 sec file is 88200 bytes long)
- vcf~ makes pd exit
mik
mik wrote:
hi
- vcf~ makes pd exit
on my debian linux box vcf~ works in pd032 (i used the filter-floyd example), but as soon as i open the help for vcf~ pd dies.
i opened the vcf~ help file in pd030, "edited" it (i.e. moved the boxes around) - now it opens fine also in pd032.
here it is, i wonder if pd survies opening it on your boxes ...
norbert
#N canvas 269 89 600 496 10; #X floatatom 274 116; #X obj 274 146 sig~; #X floatatom 333 218; #X floatatom 265 334; #X obj 265 294 env~; #X floatatom 149 334; #X obj 149 185 phasor~; #X obj 149 215 cos~; #X floatatom 149 119; #X obj 149 149 sig~; #X text 83 203 cosine; #X text 70 218 test signal; #X obj 149 290 env~; #X text 111 355 amp in (db); #X text 53 119 test frequency; #X text 251 356 amp out (db); #X obj 265 262 vcf~; #X text 314 114 center frequency; #X text 339 199 q; #X text 25 18 vcf~ -- voltage-controlled filter; #X floatatom 332 40; #X connect 0 0 1 0; #X connect 1 0 16 1; #X connect 2 0 16 2; #X connect 4 0 3 0; #X connect 6 0 7 0; #X connect 7 0 12 0; #X connect 7 0 16 0; #X connect 8 0 9 0; #X connect 9 0 6 0; #X connect 12 0 5 0; #X connect 16 0 4 0; #X connect 20 0 8 0; #X connect 20 0 0 0;
Yes, it works. It's indeed only the 0.32 help file which makes pd crash. Problem solved. Thanks. mik ----- Original Message ----- From: "Norbert Math" math@iem.kug.ac.at To: pd-list@iem.mhsg.ac.at Sent: Wednesday, December 13, 2000 5:51 PM Subject: Re: table/writesf/vcf~
mik wrote:
hi
- vcf~ makes pd exit
on my debian linux box vcf~ works in pd032 (i used the filter-floyd example), but as soon as i open the help for vcf~ pd dies.
i opened the vcf~ help file in pd030, "edited" it (i.e. moved the boxes around) - now it opens fine also in pd032.
here it is, i wonder if pd survies opening it on your boxes ...
norbert
#N canvas 269 89 600 496 10; #X floatatom 274 116; #X obj 274 146 sig~; #X floatatom 333 218; #X floatatom 265 334; #X obj 265 294 env~; #X floatatom 149 334; #X obj 149 185 phasor~; #X obj 149 215 cos~; #X floatatom 149 119; #X obj 149 149 sig~; #X text 83 203 cosine; #X text 70 218 test signal; #X obj 149 290 env~; #X text 111 355 amp in (db); #X text 53 119 test frequency; #X text 251 356 amp out (db); #X obj 265 262 vcf~; #X text 314 114 center frequency; #X text 339 199 q; #X text 25 18 vcf~ -- voltage-controlled filter; #X floatatom 332 40; #X connect 0 0 1 0; #X connect 1 0 16 1; #X connect 2 0 16 2; #X connect 4 0 3 0; #X connect 6 0 7 0; #X connect 7 0 12 0; #X connect 7 0 16 0; #X connect 8 0 9 0; #X connect 9 0 6 0; #X connect 12 0 5 0; #X connect 16 0 4 0; #X connect 20 0 8 0; #X connect 20 0 0 0;
Has anyone found a way to get performable output from Gem under Linux?
Since most video-output solutions for Linux send the whole screen, the challenge is getting Gem to inhabit the whole screen (while possibly allowing you to keep using pd)...
Perhaps, if Gem could open up a window (fullscreen) on another display - which was on another computer, or perhaps another monitor on the same computer?
Just wonding if anyone else has approached this problem.
pix.
pix@test.at a écrit :
Has anyone found a way to get performable output from Gem under Linux?
I prefer control my openGL applications, written in C, with the FUDI protocol, using the netsend and netreceive objects. Of course it makes the project more difficult to program than with Gem, but it's much more flexible.
Since most video-output solutions for Linux send the whole screen, the challenge is getting Gem to inhabit the whole screen (while possibly allowing you to keep using pd)...
Using the SDL library, I can work on my application in a window, then switch to fullscreen for the performance.
Perhaps, if Gem could open up a window (fullscreen) on another display
- which was on another computer, or perhaps another monitor on the
same computer?
That's one of the thing you can do with the FUDI protocol: control an application on a separate computer.
Hi all,
I've got to do something of the same sort too and will probably work on it soon, perhaps even find a way to help others do it...
My own plan is to run Pd and "pd-gui" on different machines. (There's a "-guicmd" flag in Pd in which you could specify, for example, "ssh next-door pd-gui". This could also be of use for people wanting to run Pd on embedded processors!)
The only thing I haven't figured out yet is how to tell Gem to render to the "root" window on the local machine (while Pd-gui is drawing on the other machine's display). I bet it's easy but I have to learn about the X window system's window-finding-and-specifying hooks; then I have to modify the "gemwin" object to write to an existing window instead of creating a new one. Sounds easy, right?
cheers Miller
On Thu, Dec 28, 2000 at 09:10:00PM -0500, Marc Lavallée wrote:
pix@test.at a écrit :
Has anyone found a way to get performable output from Gem under Linux?
I prefer control my openGL applications, written in C, with the FUDI protocol, using the netsend and netreceive objects. Of course it makes the project more difficult to program than with Gem, but it's much more flexible.
Since most video-output solutions for Linux send the whole screen, the challenge is getting Gem to inhabit the whole screen (while possibly allowing you to keep using pd)...
Using the SDL library, I can work on my application in a window, then switch to fullscreen for the performance.
Perhaps, if Gem could open up a window (fullscreen) on another display
- which was on another computer, or perhaps another monitor on the
same computer?
That's one of the thing you can do with the FUDI protocol: control an application on a separate computer.
-- Marc Lavallée
Miller Puckette writes:
The only thing I haven't figured out yet is how to tell Gem to render to the "root" window on the local machine (while Pd-gui is drawing on the other machine's display).
I guess it is better to not draw onto the root window, but to create a window without handles and all, this way you can make sure that GEM output is not hidden by other windows.
I bet it's pretty simple to hack that into the window creation for X ..
Guenter
-
Guenter Geiger -
Marc Lavallée -
mik -
Miller Puckette -
Norbert Math -
pix＠test.at