pix@test.at wrote:
i have been thinking about something like this for a while too. i have settled on a different approach to the problem (which essentially involves making a separate, more scheme-savvy pd-like application), because my time is not as limited (i am looking at it as a -really- long term project). but as a quick way of getting a lot of extra functionality into pd, the mechanism you described would be cool.
my halfbaked inital conception of something like what you have describe was that there would be an object which takes the name of a textfile, which contains scheme code to build the object. kind of like providing a mechanism for describing abstractions in scheme.
eg "scheme myobject.scm"..
internally tho, i think the execution model of pd is going to make this tricker than it appears (hence my desire to ambitiously rebuild pd from the gorund up).
pix.
Hi pix -
I pretty much have SIOD working with PD. But of course, it is slow. Especially because for now, I have not attempted to interface the data structures but instead create strings containing the expression to be evaluated in scheme, and similarly parse the string that is returned.
I had embarked on this in the hopes of having a faster way of creating objects without having to compile C code and understanding the PD API, but of course, in doing this, I personally have learned enough about the PD functions that it might now be just as fast to code my externs in C!
Once I iron out a few details, I hope to post the code. It works similarly to what we both have been describing, except that I load a single scheme file into the interpreter which defines all the objects. the PD object names a function in scheme which creates a closure for the object.
On Sat, 28 Apr 2001, Larry Troxler wrote:
Hi all,
I am attempting to implement an library which will provide a scheme extension language, and would welcome any comments.
First I should say what my motivation is. I have found PD very fun and practical, except where any kind of serious programming logic is needed. In these cases, I have found it a mind bender to try to implement graphically what could be accomplished very easily using a text-oriented language. As a case in point, I want to create a PD piano instrument that uses a piano sample CD. Although I got it working with a particular set of sample files, it is clear that the graphical hookup technique is certainly not a sensible way to go about this. As a result (well, not only because of this, but also because of several other similar situations), I have longed to drop down into a textual language to implement PD objects.
True, I could use C and implement what I need directly as a loadable object, but I though that an interpreted language would be in general nicer, and fast enough, for most purposes like this.
I have decided at first to use "scheme in one defun" (siod), simply because my time is limited, and siod it takes much less brain power to integrate siod, then to learn how to implement guile or elk. Of course, guile/elk is more complete and probably will run a lot faster, and this is a future option.
I'd like to present my first-attempt specs for how this would work, and see if anyone has any comments. This is very rough-draft and not precise, but just to give a general idea...
- implement a global receiver (like "pd"), that when it receives any
message, sends it to the sheme interpreter to evaluate. This would not be as nice as a seperate interpreter console, but for now, it will avoid me to have to deal with a new gui for an interpreter. Question: what to name this? I will take "scm" for now, so that for example, in a message box, "; scm foo `( 1 2)" will call the scheme function "foo" with the list (1 2) as an argument. The outer pair of parenthesis is implicitly added.
- The scheme function (pdsend 'receiver arg1 arg2 ..) will send its
args to the pd receiver named "receiver". For example, (pdsend 'pd 'quit).
- The scheme function (pdreceive 'x fn) will create a pd receiver, so
that when pd sends a message to "x", the scheme function "fn" will be called, and passed the message as a list.
- The pd object "scmob" (Question: better name?) will instantiate a pd
object implemented in scheme (for now I won't deal with DSP signals). Its first argument, prepended with "make-", will be the name of a scheme function which will create a closure which will become the object. The number of inlets to this object will be determined by the number of the arguments in the lambda expression returned by the generation function. And the number of outlets will be determined by, well I don't know yet. The additional creation arguments will be passed to the creation function. Within the lambda, the function (pdout n val) would send val to the n'th outlet of the object. When anything is received at the first inlet to the object, the arguments of the lambda will be bound to the current values at the inlets, and the lambda will be called.
For example, say we have in the scheme environment (note, I just typed this in without a proper editor, so there could be paren mismatches, etc, but to give the general idea...) :
(define (make-integrator initial-value) (let ((current initial-value)) (lambda (x) (cond ((and (symbol? x) (eq x 'reset)) (set! current initial-value)) ((number? x) (set! current (+ current x)))) (pdout 0 current) (pdout 1 x)))
Given that the above has been evaluated in the scheme environment, then typing "scmob integrator 10" into a PD object would create a an object with one inlet, whose first outlet would be a sum of the number object received at the inlet, or be reset to 10 if the "reset" message is received at the inlet. The second outlet would be a copy of the inlet.
--
Larry Troxler