helo. ok, sorry for the flood, but i ll keep babbling as long as thoughts do come up.
- netscape plugin - maybe related to an interfaceless pd-instance since
both c/would be just a runtime module.?
- ok m this is obvious and i m sure people have spent time pondering it,
but what about porting pd to java-pltform? ? it could probalby save a lot of later work if efforts are started at this early stage. of course, i know that java's just tooooo slow, but, maybe on the alpha it would feel like on a p200 . and also on new-fast G3 macs it will maybe rock .. and then, you could also load the pd "synthesis-engine"(se) into an applet in the browser. so it would be a bit like Jmax in that you can have custom interfaces to running patches but also have the "se" directly in the browser, as well as on any other machine.! hm, i just know a bit to0 little about the true portability of java programs and the internal workings of pd to see wether what is realistic and what not .. ;9
- maybe there is already a solution for this, but whats shit on linux
(besides the full-duplex mess) is that if one app has open dev/dsp you cant access it from another applicatiion. so you would need something like soundmanager on the mac, which "serves" virtual audio-devices but mixes them internally, so no app beside soundmngr really accesses dev/dsp. would this work with NAS for example? or what else? on the other hand, i thought, maybe its possible to have pd to do this so an editor or a file player can connect to a internal-signal-inlet which you can then just mix or send it through processing chain ... but, in fact there's probably no way around recompiling each app you would want to use in this manner ... though .. i would go for it ...
- ... aeh, yeah, when will we do a workshop in "programming of
pd-externals for the layman"?? (maybe somewhere in austria in earlier 1999?)
ok enough, ltr.
-----Original Message-----
>>>>>>>> From: opt@wrzk.farmersmanual.co.at
<snip> > - maybe there is already a solution for this, but whats shit on linux > (besides the full-duplex mess) is that if one app has open dev/dsp you > cant access it from another applicatiion.
I started a sounddriver for Linux who could do that (and still does on my system). ItŽs working for SB16 cards, Terra Tech Base1, and ..uhm ..Turtle Beach Multisound. Ah, yes the es1668 chip based cards. Otherwise it supports the OSS API, so all standard Apps work.
I think I am the only user of this driver ... it wasnŽt really a great success.
so you would need something like soundmanager on the mac, which "serves" virtual audio-devices but mixes them internally, so no app beside soundmngr really accesses dev/dsp. would this work with NAS for example? or what else?
Yes, and thereŽs another sound server (canŽt remember itŽs name). I have written a sound server which mimics the SGI audio library, it was called "soundshame". (Actually a shame that I didnŽt make that public).
All this server based solutions will introduce an additional delay and .... will block your /dev/dsp too. ....
on the other hand, i thought, maybe its possible to have pd to do this so an editor or a file player can connect to a internal-signal-inlet which you can then just mix or send it through processing chain ... but, in fact there's probably no way around recompiling each app you would want to use in this manner ... though .. i would go for it ...
That would be really cool. We could implement an ALSA API that just connects to pd instead of the sound devices. We then would only have to recompile ALSA aware applications. (e.g CSound ..)
- ... aeh, yeah, when will we do a workshop in "programming of
pd-externals for the layman"?? (maybe somewhere in austria in earlier 1999?)
Why not, if thereŽs enough interest .... (and Beer :R )
Guenter
-
Guenter Geiger -
tpt