more stuff

tpt opt at
Thu Dec 3 23:48:20 CET 1998

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,
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

ok enough, 



More information about the Pd-list mailing list