@jameslo "Since many programmers seem to want to avoid [fexpr~] at all costs, maybe you could rewrite your [fexpr~] with [expr~ $v1 > $v2] and [rzero_rev~ 0]"
Hmm, yeah. I had thought that both [expr~] and [fexpr~] were said to be bad for performance.
I suppose this might be another way to do a signal-rate comparison:
There's a very small chance of the [-~] result being between 0 and 1e-30, where the clip~ value would be between zero and one but not exactly either. With typical signal magnitudes, that's unlikely, so this wouldn't work in cases where only 0 and 1 are acceptable.
+1 RE the mystifying omissions and irregularities in vanilla. Since I started thinking of it as a scripting language (and stopped comparing it to c, c++, c#, Java...) everything became happy and easy-going.
Yes and no... Pd is an important and valuable tool and it's good to make friends with it as it is. At the same time, lack of some core operators can be seen as a usability issue.
I definitely wouldn't compare it to C and such. Miller Puckette himself acknowledges[1] that many algorithms are straightforward to write in procedural languages (and maybe even more straightforward in functional languages), but rip-your-hair-out painful in dataflow patchers. E.g., quicksort, which in Haskell goes:
quicksort :: Ord a => [a] -> [a]
quicksort [] = []
quicksort (p:xs) = (quicksort lesser) ++ [p] ++ (quicksort greater)
where
lesser = filter (< p) xs
greater = filter (>= p) xs
and in C is... somewhat longer but still a fairly straightforward recursive implementation.
I can literally not even imagine how to implement a quicksort in Pd.
In SuperCollider, I'm doing most of my performances using a sequence-scripting language of my own design, where SC code is parsing the expressions and translating them into SC patterns. That's been a long project but within reach of an object-oriented language with a full suite of data structures. Pd... again, I can't imagine where to begin.
Puckette points out in that interview that Max and Pd are designed to react to input events, and they are very elegant for this. In Pd, you can connect a slider to a number box. In SC, the same is:
(
var number, slider;
w = Window("slider", Rect(800, 200, 500, 400)).front;
w.layout = VLayout(
nil,
HLayout(
number = NumberBox().fixedWidth_(80),
slider = Slider().orientation_(\horizontal)
),
nil
);
slider.action = { |view|
number.value = view.value;
};
)
In that case, definitely, Pd's expression of the idea of a value flowing from an interface object toward the display object is as concise as you can imagine, and SC's version is verbose and puzzling until you get used to it. Use the tool that's right for the job.
lacuna:
There are [vphasor~], [vphasor2~] and [vsamphold~] from @Maelstorm .
Oh that's good.
It's hard to find extensions like this, if you don't know where it is.
In your patch [rpole~ 1] is working with a signal-inlet, isn't it?
Yes. The idea is, while the (signal) coefficient is 1, then the left-hand signal gets integrated. If, for a single sample, both the signal and coefficient are 0, then the output is 0, and it will start integrating again as soon as the coefficient flips back to 1.
Which is that other forum you mentioned?
scsynth.org
TBH I think SC wins in terms of clear expression of this synthesis algorithm:
(
{
var sync = LFTri.ar(SinOsc.kr(0.2).exprange(100, 400));
var phase = Sweep.ar(sync, SinOsc.kr(0.12743).exprange(700/3, 2100));
var synced = SinOsc.ar(0, (phase % 1) * 2pi);
dup(LeakDC.ar(synced * sync) * 0.1)
}.play;
)
This is part of what I mean by "usability issues" -- Pd: 7 objects for the triangle wave vs SC: LFTri.ar(freq), or the automatic exponential scaling exprange, and Sweep has a signal-rate retrigger built-in (there's also a range-rewrapping Phasor, and it has an audio-rate trigger too)... SC's initial learning curve is steeper but once you know it well, it took a couple of minutes to write that, vs 30-40 minutes (including head-scratching time) in Pd. (Admittedly I'm less fluent in Pd.)
hjh
[1] https://omny.fm/shows/future-of-coding/47-maxmsp-pure-data-miller-puckette
)
