Hi, I'd like to know if anybody on this list is actually using or planning to use my scheme extern:
http://www.westnet.com/~lt/pd/index.html
I think that the version there is not the newest, and I've since been writing stuff to import scheme sequences into Common Music, etc, but really, if nobody else is using this (which is perfectly fine by me) then I don't have to bother with documentation, version control, posting, and all that stuff...
So, if anybody is actually using this thing, let me know. Otherwise it will save me a bit of time :-)
Larry
Hi Larry,
well, I'm not really using it anymore although I find extensibility through scheme *very* useful. It's more that I don't like to fool around with too many interpreters and siod definitely wouldn't be my first choice as it is not maintained anymore. Did you think about some integration with guile? I guess that way maybe the full functionality of common music could be available from within pd and vice versa. Right now I'm interfacing using files or a combination of netsend/netreceive and named pipes but I could imagine a somewhat tighter integration.
Any thoughts?
-- Orm
Am Sonntag, den 29. Dezember 2002 um 21:40:39 Uhr (-0500) schrieb Larry Troxler:
Hi, I'd like to know if anybody on this list is actually using or planning to use my scheme extern:
http://www.westnet.com/~lt/pd/index.html
I think that the version there is not the newest, and I've since been writing stuff to import scheme sequences into Common Music, etc, but really, if nobody else is using this (which is perfectly fine by me) then I don't have to bother with documentation, version control, posting, and all that stuff...
So, if anybody is actually using this thing, let me know. Otherwise it will save me a bit of time :-)
Larry
PD-list mailing list PD-list@iem.kug.ac.at http://iem.kug.ac.at/cgi-bin/mailman/listinfo/pd-list
thinking of common music and pd etc..
I would like to see an integration of clm particularly the PVOC and convolution into pd if possible
so one could change parameters inside pd instead of editing .ins files by hand
and also maybe an external for dealing with .sdif files generated by loris/fossa?
are these outrageous suggestions?
Pat Pagano, Director South East Just Intonation Society http://www.screwmusicforever.com/SHREESWIFT/ http://www.digitalworlds.ufl.edu
Orm Finnendahl wrote:
Hi Larry,
well, I'm not really using it anymore although I find extensibility through scheme *very* useful. It's more that I don't like to fool around with too many interpreters and siod definitely wouldn't be my first choice as it is not maintained anymore. Did you think about some integration with guile? I guess that way maybe the full functionality of common music could be available from within pd and vice versa. Right now I'm interfacing using files or a combination of netsend/netreceive and named pipes but I could imagine a somewhat tighter integration.
I agree that SIOD isn't a best choice. I picked that one mainly because it didn't take much time to figure out how to interface to it. I was very easy. But as you have said in the past, not too many people are using it and it isn't standard Scheme - there are some differences and ommisions.
Since CM now runs in Guile, it would be interesting to take the effort now to use Guile instead.
What have you done with PD and CM so far? It sounds like you are succesfully using them together on some level.
This is getting seriously off-topic now, but one question that arises whenever I think of interfacing some other program to CM, whether via pipes or sockets, is how to keep the existing listener so that one can interact with CM from a terminal or from xemacs, while at the same time allowing the Lisp to evaluate forms coming in over a pipe or socket (and then to send the result back to the appropriate destination). I imagine that this can be accomplished in all current implementations, by writing a custom REPL that listens to both stdin and a socket (or whatever), but I haven't seen any examples of such a thing. I am just wondering whether you have thought of this.
Larry Troxler