[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [sc-users] Pbind question
On Tue, Jun 8, 2021 at 9:27 PM <maxlouis.raugel@xxxxxxxxx> 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: https://listarc.bham.ac.uk/marchives/sc-users/
search: https://listarc.bham.ac.uk/lists/sc-users/search/