Meeting minutes 2018-08-19

Development Dev meetings
1

Members present: Alex Goldsmith, Brian, Nathan, Patrick, Scott, Thomas

3.10.0-beta1 is out!!! (not announcing yet until sc3-plugins beta is ready)

Member updates:

  • Alex uses gen~ a lot and would like to see single-sample feedback for more fine-grained DSP goodies such as TPT filters & ladder filters with customizable nonlinearities, and discrete summation formulas. He had some trouble with HID, which was last touched 4-5 years ago
  • Brian hasn’t done much
  • Scott hasn’t done much
  • Patrick has a bandage for his HelpBrowser issues, developed a new quark called SATI
  • Nathan is working on improving the look of the IDE

Topics:

  • We’ll be (privately) putting together a survey after 3.10 release to get a good idea of the direction for 3.11, which we hope will be released very quickly
  • New forum is going well: questions are getting answered, lots of little mini-articles
  • We have tried to get sclang into some major syntax highlighting packages like Highlight.js but most of them have gone without response
  • A priority for 3.10 is packaging supernova in the official release for Mac
  • Brian’s big projects moving forward are improving the test suite and standardizing C++ formatting across the codebase
  • Pinning test for ugens
  • Rendering SCDoc and uploading CI
  • Remaining “big annoying projects:” SCIDE startup sequence unreliability, debian packaging, supernova on windows, command line on windows
  • Brian suggested that Alex work on compiler warnings
  • Possible new official tutorial development with e.g. gitbook, outside SC help system
  • “Clear post window” menu item
  • Aaaaaaaaableton Liiiiiiiiiink: going slow, going steady
2

This can already be done with Fb1 from miSCellaneous_lib quark, following an idea of Nathaniel Virgo. Not being a filter expert but out of interest I checked the TPT example from Robin Schmidt here:

It needs a lot of ugens but only 3 % CPU on my 5-year-old iMac.
This code supposes miSCellaneous installed, sample rate 44100 and blocksize 64 (can be adapted).

(
// following example by Robin Schmidt
// https://www.kvraudio.com/forum/viewtopic.php?p=4932644

~inBus = Bus.audio(s, 1);

SynthDef(\tpt_test, { |outBus = 0, inBus, damp = 0.5, cutoff = 10000, filterType = 0, amp = 1|
    var fs = 44100, wd, t, wa, g, in, sig, r = damp, fc = cutoff;
    in = In.ar(inBus, 1);

    wd = 2*pi*fc;
    t = 1/fs;
    wa = 2/t * tan(wd*t/2);
    g = wa*t/2;

    sig = Fb1({ |in, out|
        var yH, yB, yL, s1, s2;
        // we need previous s1 and s2 (out[1]), from this first and second component 
        s1 = out[1][0];  
        s2 = out[1][1];

        yH = in - (2*r*s1) - (g*s1) - s2 / (1 + (2*r*g) + (g*g));

        yB = g*yH + s1;
        s1 = g*yB;

        yL = g*yB + s2;
        s2 = g*yB + yL;

        // pass s1 and s2 for next sample plus filtered signal
        [s1, s2, yH, yB, yL]
    }, in, outSize: 5, leakDC: false);

    Out.ar(outBus, Select.ar(filterType, sig[(2..4)]) * amp);
}, metadata: (
    specs: (
        inBus: ~inBus.index,
        damp: [0.01, 0.99, \lin, 0, 0.5],
        cutoff: [100, 15000, \exp, 0, 2000],
        filterType: [0, 2, \lin, 1, 0],
        amp: [0, 1, \lin, 0, 0.5]
    )
)
).add
)

// start filter first with green button
\tpt_test.sVarGui.gui
        
// start source
{ Out.ar(~inBus, WhiteNoise.ar(0.1)) }.play

// check spectrum
s.freqscope

Daniel

3

This is cool Daniel.

Not sure I’d want to develop a finished UGen using this approach, but as a prototyping environment (e.g. for tuning a filter/reverb/whatever) - this looks very promising.

4

The topic ugens vs. pseudo ugens is a very interesting one as it touches a principle tradeoff problem in computer music. Usually ugens are faster but even this is not always the case. A number of some hundred or even thousand ugens is nothing that must frighten. But the probably more important point is flexibility. If you wrap a filter with a certain topology properly into a ugen that’s fine when you use a lot of them or use them often. But what if you want to deviate from the exact behaviour in some regard - e.g. with some extra algebraic operations within the feedback loop? That’s simply not possible if you have a fixed ugen (unless you schedule a certain extension already in the c++ code). Indeed filters are a special case because often you want a filter with a special expected behaviour, whereas during the process of sound exploration you don’t necessarily expect something specific.

I tend to think that a kind of over-encapsulation limits the possibility to explore unknown sound worlds. I’ve observed something similar with granulation: the granular ugens are fantastic and I use them a lot. They can produce really wonderful sounds quickly, but: they exclude a huge variety of microsound possibilities by the specifications they necessarily must have. Much more variants of granulation are possible with Patterns, but this needs more preparations also …

1 Like
5

Oh I agree on flexibility. I think what you’ve done is really cool and I do plan to use your feedback stuff for other one off stuff.

I just think that for filters specifically I would write a fixed UGen for the reasons you specify (primarily performance - optimized C++ will win by a lot here). But even there the ability to explore a space interactively prior to building a fixed UGen is very useful.