Hi everybody!
i'm still moving first steps in pd (yet reading manuals!!). By now it runs on a celly433, 128MB ram and win98 first ed. (but i'm installing WinNT) i notice that the system running PD is very slow in refreshing windows, at least slower than running other r/t audio softwares. Is it due to the architecture of pd (eg. audio computations made higher in hierarchy than graphical ones, or similar)?
Thx in advance
L�rd2��T3R
I've heard that Celerons are weak in floating point performance; I've never tried one myself. Pd's audio computations are all done in floating point so on the whole Pd won't run fast on Celerons. However, I don't know any reason why the graphical side of things should be so bad. Perhaps this is a W98 thing which will go away with NT?
cheers Miller
On Mon, Feb 28, 2000 at 06:57:57PM +0100, Raffaele Turra wrote:
Hi everybody!
i'm still moving first steps in pd (yet reading manuals!!). By now it runs on a celly433, 128MB ram and win98 first ed. (but i'm installing WinNT) i notice that the system running PD is very slow in refreshing windows, at least slower than running other r/t audio softwares. Is it due to the architecture of pd (eg. audio computations made higher in hierarchy than graphical ones, or similar)?
Thx in advance
L?rd2??T3R
hello miller, jason, garry, and anyone elso who may have experience with this,
i'm not really sure if this is worth anyone's time, but it could sure save me a lot of my own. i've been reading all of the mail involving pd on linuxppc and the like, and now that i've put linuxppc 2000 on my mac, i'd like to give this a whirl. HOWEVER, i've noticed some discrepancies in the suggested solutions.
the latest, from garry kling, says that miller says to change the format "AFMT_S16_LE" to "AFMT_S16_NE" in the s_linux.c file. HOWEVER, my s_linux.c file already has 2 occurrences of "AFMT_S16_NE" in it, and no reference to any "AFMT_S16_LE" anywhere. it does have 2 occurrences of "SFMT_S16_LE" though. is this what i'm supposed to change? this is pd-029-linux that i'm working with btw.
i think i've got the makefile editing down ok. i guess all you've got to do is point pd to where the egcs lib's are, yes? somewhere inside the /usr/lib/gcc-lib/ directory? i don't think these were included on the default installation, but i should be able to find and install them, i think. please confirm that i am indeed on the right track here. i apologize for my ignorance of this operating system; please feel free to consider me a prepubescent in the land of linux.
i found an earlier note from jason freeman about making these changes too. he wrote that you should change "SB16_LE" to "SB16_LE" in s_linux.c file, and that there is only one occurrence of this. well, i've got no occurrence of "SB16_LE" in my s_linux.c file (again, pd-029-linux), and even if i did, i there is no difference between what was there and what i'm supposed to change it to. please confirm that i am not insane.
i don't really care all that much about alsa and all that as i'm not that concerned with sound input or midi in/out (yet). what i'd like to achieve is to have gem running with mesa or quesa(?) drivers and the appropriate atyrage128 driver setup (b&w g3). i'm assuming that you got this to work jason, or possibly dieter kovacic, as you both alluded that you seemed pretty close to getting it to work. if so, any snags or tricks that i should know?
ULTIMATELY what i'd like to do, just because i'm curious is find out if pd would be portable to os x. does pd rely on things that are linux specific? or could os x's bsd layer and unix/next roots and such allow some amount of compatibility? pd for linux and pd for irix are obviously different because of the difference in the os, so obviously some amount of editing would have to take place, but how much? impossible? or just really difficult? or just not worth it?
thanks in advance for any/all responses! -jeremy schulz
J.R. Schulz writes:
hello miller, jason, garry, and anyone elso who may have experience with this,
Hi j.r., I`ve only "glanced" through your email .. some answers maybe....
I have to look into this myself, generally endianess should not be a problem ... if it is, pd will issue a message like "OSS: Could not set DSP format"
i think i've got the makefile editing down ok. i guess all you've got to do is point pd to where the egcs lib's are, yes? somewhere inside the /usr/lib/gcc-lib/ directory?
do a "make depend", and you should not have to do any makefile editing..
i don't think these were included on the default installation, but i should be able to find and install them, i think. please confirm that i am indeed on the right track here. i apologize for my ignorance of this operating system; please feel free to consider me a prepubescent in the land of linux.
ULTIMATELY what i'd like to do, just because i'm curious is find out if pd would be portable to os x. does pd rely on things that are linux specific? or could os x's bsd layer and unix/next roots and such allow some amount of compatibility? pd for linux and pd for irix are obviously different because of the difference in the os, so obviously some amount of editing would have to take place, but how much? impossible? or just really difficult? or just not worth it?
pd is not OS dependent, it just needs an average amount of changes. The hardest part will be the sound and MIDI I/O, all other things only require minimal editing (especially on a unix like environment).
Guenter
Hi All,
the latest, from garry kling, says that miller says to change the format "AFMT_S16_LE" to "AFMT_S16_NE" in the s_linux.c file. HOWEVER, my s_linux.c file already has 2 occurrences of "AFMT_S16_NE" in it, and no reference to any "AFMT_S16_LE" anywhere. it does have 2 occurrences of "SFMT_S16_LE" though. is this what i'm supposed to change? this is pd-029-linux that i'm working with btw.
well, I think by 0.29, I had incorporated the change from AFMT_S16_SE to AFMT_S16_NE in the OSS driver code in s_linux.c. I haven't touched the ALSA code, but then again, I've never heard of anyong running ALSA on PPC...
cheers Miller