Pseg equivalent?

[kflak]

I was wondering what it would take to write a Pseg equivalent? At the moment I am using the cm interp function like this to achieve more or less the same:

        :time (ptime)
        :pan (pf (interp (e :time) 0 -1.0 2 1.0 4 0 8 -1.0))

The interp function interpolates a number over a series of breakpoints, so that in this example the value will be -1.0 at 0 seconds, 1.0 at 2 seconds, 0 at 4 and -1.0 and -1 again at 8 seconds. I kind of like this better than the env style of doing things in SuperCollider, so maybe I am rather shooting for a pinterp class instead of pseg...? In any case, I would be happy to work on creating this, but I find it a bit hard to understand how to write my own. I have read the writing-your-own document, but I couldn't understand how to do the thing from that. Do you have any kind of step-by-step instruction on how to do this?

Of course, I could do the quick-n-dirty path of defmacro:

(defmacro pinterp (breakpoints &optional duration)
  (if (not duration)
      (setf duration (second (reverse breakpoints))))
  `(pfindur (pf (interp (e :time) ,@breakpoints)) ,duration))

but I would love to be able to define my own proper pattern classes...

[defaultxr]

I agree, a pattern for this would be useful, and pinterp would be a good name for it.

And yes, the writing-your-own.org definitely needs some work, since it doesn't actually explain how to make a pattern class... 🤦

Here's some information about how to write a pattern class, which I will probably put in writing-your-own.org if it's useful and makes sense. It's a bit long, but I figure it's better to give too many details instead of not enough. I didn't write any code below since you said you want to learn how to write your own patterns and I didn't want to just give the answer if you're trying to learn, but let me know if you have any questions or anything about any of this.

When writing a pattern class, there are typically 2 or 3 elements required: the defpattern macro, the as-pstream method, and the next method.

defpattern

The defpattern macro will define the pattern and add it to the pattern system. It's where the name, superclasses, slots, and documentation are specified. Since pinterp seems similar to pindex, a defpattern form for pinterp would probably be pretty similar to the one for pindex.

(In fact, the code of pindex in general would probably be a good reference to base a pinterp implementation off of.)

as-pstream

Depending on the pattern's behavior, an as-pstream method may also need to be defined for it. This method is called by the pattern system to make a pstream from a pattern. It does this creating a new PATTERN-pstream instance (where PATTERN is the name of the pattern in question) whose slots are copied from the pattern object provided to it, making each value a pstream if it should be converted to one.

A value should be converted to a pstream if the user may want to provide a pattern for that value. So in the case of pindex, the user may want to provide a pattern as the LIST-PAT as well as the INDEX-PAT, but it doesn't really make as much sense to provide a pattern as the WRAP-P.

The default as-pstream method will make all of the pattern's slots into pstream objects themselves, so they can be used like patterns. So if there are any slots of the pattern you're writing whose values you DON'T want to become pstreams, then as-pstream should be defined for the pattern you're writing.

In this case, we want LIST-PAT and INDEX-PAT to become pstreams if patterns are provided for those slots, and we don't want WRAP-P to become a pstream at all. So the as-pstream method for pinterp would be basically the same as the one for pindex.

The reason that pattern-as-pstream is used for LIST-PAT and INDEX-PAT in pindex's as-pstream method is because as-pstream will convert non-pattern values into t-pstream objects, which are basically pstreams that yield their value once and then end. Whereas when next is called on a non-pattern value, it will always return that value:

> (defparameter one-t-pstream (as-pstream 1))
ONE-T-PSTREAM

> one-t-pstream
#<T-PSTREAM 1 1>

> (next one-t-pstream) ; a t-pstream yields its value once
1

> (next one-t-pstream) ; ...and then it ends
EOP

> (defparameter one 1)
ONE

> (next one) ; non-pattern values always yield themselves
1

> (next one) ; ...they don't end
1

pattern-as-pstream is just a convenience function that calls as-pstream if its input is a pattern, otherwise it just returns the input.

For patterns that don't have explicit repeats or length arguments (as should probably be the case for pinterp), their length is typically determined by the patterns the user provides as input. i.e. if the user wants to limit the length of the pinterp they will probably do so by providing a finite pattern as either LIST-PAT or INDEX-PAT.

next

Finally, all patterns should have a next method defined on their -pstream class. This method is what is called by the pattern class to actually get the next value of the pstream. So this is where the pattern's actual behavior is defined.

Since cl-patterns already depends on Alexandria, and doesn't seem to have an interp function, the best function to implement pinterp would probably be alexandria:lerp, available in cl-patterns as just lerp (without a package prefix). pindex's next method could probably be a reference here as well.

[kflak]

Awesome, thank you so much for that thorough write-up! I will need a bit of time to digest all of that, I think, but it is a fantastic starting point for me to get going.

[kflak]

OK, this is actually going a bit faster than I thought it would. At least I am able to get some values out of the pattern, which I take as a victory. However, I am trying to get the number of beats since I created the pattern, but this doesn't quite get me there...:

;; Helper functions come from Common Music
(defmacro ensure-tail (list error head)
  `(if (null ,list)
       (error ,error ,head)
       (pop ,list)))

(defun interp1 (x coords base)
  (let ((head coords)
        (error "bad coordinate list: ~s"))
    (let* ((x1 (ensure-tail coords error head))
           (y1 (ensure-tail coords error head))
           (x2 x1)
           (y2 y1))
      (do ()
          ((or (null coords) (> x2 x)) nil)
        (setf x1 x2)
        (setf y1 y2)
        (setf x2 (pop coords))
        (setf y2 (ensure-tail coords error head)))
      (cond ((>= x x2) y2)
            ((<= x x1) y1)
            ((= base 1) (+ y1 (* (- x x1) (/ (- y2 y1) (- x2 x1)))))
            (t
             (let ((pct (/ (- x x1) (- x2 x1))))
               (+ y1
                  (* (/ (- y2 y1) (- base 1.0))
                     (- (expt base pct) 1.0)))))))))

(defun interp (x &rest coords) (interp1 x coords 1))

(defpattern pinterp (pattern)
  (coordinates
   (elapsed-beats :initform (beat *clock*)))
  :documentation "Linear interpolation between a series of time values, based on the Common Music interp function. Think of it as a series of breakpoints in an envelope curve.

Example:

;; (next-n (pinterp (list 0 0 1 2 3 6)) 4)
;;
;; ;=> (0 2 6 NIL)")

(defmethod as-pstream ((pinterp pinterp))
  (with-slots (coordinates elapsed-beats) pinterp
    (make-instance 'pinterp-pstream
                   :coordinates (pattern-as-pstream coordinates)
                   :elapsed-beats (beat *clock*))))

(defmethod next ((pinterp pinterp-pstream))
  (with-slots (coordinates elapsed-beats) pinterp
    (let ((coords (next coordinates))
          (beat (- (beat *clock*) elapsed-beats)))
      (when (eop-p coords)
        (return-from next eop))
      (print beat)
      ;; (apply #'interp (beat *clock*) coords)
      )))

Basically what I would need to get is the beat value at the moment the pattern is launched, and then be able to subtract that from the current beat on the clock, but it seems that whatever I try the initial beat value is always updated to become the current one, resulting in elapsed-beats always being 0.

[kflak]

OK, I am flailing around right now... I discovered that there is a way to get the beat count from the pattern pbind, but I am at a loss as to how to use this. This is what I have so far:

;; Better to interleave two lists, one for levels and one for times, similar to pseg. I find it a bit more readable.
(defun interleave (list1 list2)
  (cond
    ((null list1) list2)
    ((null list2) list1)
    (t (cons (car list1) (interleave list2 (cdr list1))))))

(defpattern pinterp (pattern)
  ((levels :initform (list 0))
   (times :initform (list 0)))
  :documentation "Linear interpolation between a series of levels and time values, based on the common music interp function. Think of it as a series of breakpoints in an envelope curve.

example:
;; (defparameter *p* (pbind :dur (pinterp '(10 20 30 40) '(0 2 4 6))))")

(defmethod as-pstream ((pinterp pinterp))
  (with-slots (levels times) pinterp
    (make-instance 'pinterp-pstream
                   :levels levels
                   :times times)))

(defmethod next ((pinterp pinterp-pstream))
  (with-slots (levels times) pinterp
    (let ((levels (next levels))
          (times (next times))
          (beats (beat (pattern-parent pinterp :class 'pbind)))
          ;; (beats (beat *clock*))
          )
      (when (eop-p levels)
        (return-from next eop))
      (apply #'interp beats (interleave times levels))
      )))

However, when I call this for example like this:

(pb :interptest :dur (pinterp '(0 2 4 8) '(0 4 8 12)) :print (pf (print (e :dur))))
(play :interptest)

I get a whole bunch of 0s printed out and, finally:

WARNING:
   Task #<CL-PATTERNS::TASK :ITEM #<CL-PATTERNS:PDEF-PSTREAM :INTERPTEST>> yielded NIL 32 times in a row; removing from clock to avoid locking into an infinite loop.

[defaultxr]

I'm realizing now that I misunderstood interp before, oops... Someday I will learn how to read...

I am trying to get the number of beats since I created the pattern

Inside the next method (i.e. for each output of the pstream), I think what you're asking for is (event-value *event* :beat).

Basically what I would need to get is the beat value at the moment the pattern is launched, and then be able to subtract that from the current beat on the clock, but it seems that whatever I try the initial beat value is always updated to become the current one, resulting in elapsed-beats always being 0.

Beat value (of the clock) at the moment the pattern is launched = (beat *clock*), from inside as-pstream (as that method is called when the pstream begins).

Example of these:

(pb :foo
  :dur 1
  :x (pf (let* ((clock-beat (beat *clock*))
                (pattern-beat (event-value *event* :beat))
                (diff (- clock-beat pattern-beat)))
           (format t "~&clock-beat: ~S ; pattern-beat: ~S ; diff: ~S~%" clock-beat pattern-beat diff)
           1))
  :amp 0
  :pfin 4)

(play :foo)

However, when I call this for example like this:

(pb :interptest :dur (pinterp '(0 2 4 8) '(0 4 8 12)) :print (pf (print (e :dur))))
(play :interptest)
I get a whole bunch of 0s printed out and, finally:

WARNING:
   Task #<CL-PATTERNS::TASK :ITEM #<CL-PATTERNS:PDEF-PSTREAM :INTERPTEST>> yielded NIL 32 times in a row; removing from clock to avoid locking into an infinite loop.

I believe this is because of the 0 at the start of your LEVELS list. When I change it to a 1, I see the pattern outputting more values, which I think are probably the ones you're hoping for.

I think in general you'll probably want to be careful when making events that have a dur of 0, because while a duration of 0 beats lasts zero time, there are also an infinite number of 0s inside of 0 beats. So any pattern that calculates its output based on its current beat may have issues with events of 0 dur.

dur tells the pattern system how many beats the clock needs to advance to get to the next event, so when it sees :dur 0 it will move forward 0 beats. Then when your pattern is processed again, 0 (previous beat) + 0 (dur) = 0 (current beat), so its current beat is still 0. Hence why it appears to lock up instantly and permanently.

You're dividing by zero, basically... :)

P.S.: Another reason to be careful with events of or around 0 dur is that SuperCollider has some issues with them.

[kflak]

Cool, thanks a lot! The more I think about this, the more I realize that I should probably rather try to implement Pseg more or less directly. There are certain very cool tricks that you can only do with the Pseq approach (like Pseg(Pwhite(1, 10), Pwhite(1 4))) that you just can't do with the pinterp version. Didn't have time to look into it today, hopefully in the coming week... My zola site generator died on me, so I am in the process of porting an ungodly amount of web pages over to org-mode. The end result will be much better, though, even if there is much short-term pain :-)