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