Re: Pbind question
[email protected] Thu, 10 Jun 2021 08:05:18 +0800
| Newsgroups | gmane.comp.audio.supercollider.user |
|---|---|
| Message-ID | <CAFniQ7UXO1G20Pi3zW3-51d9Fi9+jcx2+hDi5VNLC6AOYd8UqQ@mail.gmail.com> |
On Tue, Jun 8, 2021 at 9:27 PM <[email protected]> wrote: > I’ve always wondered why the Pattern class' library doesn’t seem to allow for continuous change... Hm... there are two ways to conceive of control of synthesis: as continuities, or as discrete events. I'm going to say something a bit speculative, but it seems to me that these domains are very different, and that it's a lot to ask a single abstraction to cover both of those requirements equally well. Consider, for instance, analog modular (or VCV Rack). Here, *everything* is a continuous signal -- and it takes extraordinary measures to produce discrete notes (clocks and clock dividers, step sequencers, various forms of algorithmic magic hidden -- and not inspectable -- beneath panel knobs). So one could ask the converse question: Why do analog modular synths not allow for easy, polyphonic notes? If "the Pattern class library [not] allow[ing] for continuous change" means that patterns are useless, then by the same token, the difficulty of playing polyphonic notes with analog modular would likewise mean that analog modular synths are useless. Which is of course a preposterous conclusion. So perhaps the premise is mistaken. In that case, Patterns *would* be seen as useful, but perhaps not a perfect fit for what you're trying to do. ***Main idea:*** One thing that would help here is a way, in SC, to map arbitrary control synths onto a main synth's control inputs. Instead of thinking in terms of one big synth that does every kind of modulation I could possibly dream of, we could think in terms of clusters of synths: one main synth, plus a frequency source synth (which could be a line, an LFO, a breakpoint envelope, a chaotic function, or...?), plus x number of other control source synths. We currently don't have an easy-to-use abstraction for this -- so it looks like it's impossible. It's not impossible -- just needs to be built from smaller units. > I don’t really like (what I understand of) its conception of time - as a grid that underlies and cuts everything I'm sorry, but I have to laugh about that one. Pexprand(0.1, 0.5, inf).asStream.nextN(20) -> [ 0.3443073364569, 0.15915276388006, 0.31323417573412, 0.12526591005795, 0.16658631354666, 0.35796869063474, 0.32007183151481, 0.19765304288833, 0.13097535468957, 0.46631971015074, 0.27155564302265, 0.13039742147499, 0.47910849783507, 0.14895486462567, 0.23602943303401, 0.3350735998923, 0.1139492280449, 0.30566291638996, 0.16258653827006, 0.18253953239994 ] I expect this collection of durations would defy attempts to identify a consistent metric grid. Yet, it was generated by a pattern. How could that be, if patterns are all about time grids? The answer is: There is nothing in the pattern library that enforces simple integer ratios between time durations. > strictures the organic-abstract potential of audio synthesis Right -- everybody has an aesthetic bias. If patterns aren't a good fit for yours, then there's no need to shoehorn your ideas into patterns. hjh _______________________________________________ sc-users mailing list info (subscription, etc.): http://www.birmingham.ac.uk/facilities/ea-studios/research/supercollider/mailinglist.aspx archive: http://www.listarc.bham.ac.uk/marchives/sc-users/ search: http://www.listarc.bham.ac.uk/lists/sc-users/search/