Re: [sc-users] Re: top five sclang pet peeves

2017-12-25 22:52 GMT-03:00 <jamshark70@xxxxxx>:

*** Synchronizing the value patterns within Pbind.
Pbind is beautiful when there doesn't need to be tight synchronization
between parameters streams. This is great for a lot of atmospheric,
free-rhythm textures, but it's terrible for metrical organization.

SuperCollider already have al the infrastructure for that, again, the problem is in the standard interface...

... because my system (as does Tidal) encodes data and rhythm at the same
time. This has other limits, though.

That is right although is less general purpose as are the sequencers.

8X --------------------------------------------------------------------

I'd wager the following would be hard
in Tidal.

(
p = Pbind(
\midinote, Ppatlace([
Pwhite(48.0, 50.0, inf),
Pn(
Pwhite(
54.0,
Pseries(56.0, Pwhite(0.25, 1.0, inf), { rrand(10, 25) }),
inf
),
inf
)
], inf),
\dur, Pn(
Pexprand(0.04, 0.1, inf) * Pgeom(1, Pwhite(1.08, 1.2, inf), { rrand(6, 12)
}),
inf
)
).play;
)

That is exactly what comes to my mind when I say that pattern interface is clumsy :-D

The Tidal's magic comes from two or three things IMO. It uses and adapt Haskell syntax in a very elegant way, e.g. "$" and "#", everything is a function and everything is a pattern, and there are not capital letters (well, this last may be biased). It is a dedicated pattern language of limited scope (domain specific) because it is bound to a preconceived rhythmical and instrumental structure based on the sampler's conceptions, it uses SuperDirt which in turn imposes a, very nice, sampler chain (mixer, effects, etc.). It has, and I would take out my hat if I had one, an embedded pattern language that clearly represents every possible proportional rhythm bound to another parameter (in this case the base case is the sample but it can be pitch) with the less quantity of symbols... as an inversion of the traditional music notation paradigm... historically coherent... relative to the unit... mathematically perfect... that is enough, McLean, you rock! :-D

The thing with SC patterns is how to present all that resources that already have (pattern composition, pattern filter, the badly named server control patterns, etc.). But, as you say later, is not coherently organised. For example, to have to deal with the environment logic to make a variation (e.g. collect) is too complicated and has nothing to do with the logic of the (musical) data or the instrumental abstractions. Nested structures generated by classes and arrays are difficult to follow and reuse in a different context. I believe it can be organise in a more clear composer oriented way without loosing general purpose. Mathematical and computational abstractions are all fine and necessary for me provided they clearly and succinctly represent the expressed concept... the important one... not easy.

*** Patterns are incomplete as a pure-functional system

Patterns are supposed to be stateless, but in practice, you have to embed
all kinds of Pfunc, .collect, Prout, Pspawner etc. to do really interesting
things.

*** Event patterns don't have a good way to encode dependencies

In practice, an event pattern playing a musical element needs other "stuff"
-- buses, buffers, data storage etc. but all of these are best handled
outside the pattern system itself. There was an attempt with Pproto, but it
doesn't support everything, and it doesn't sync loading cleanly.

I deal with it using PR/BP from my ddwChucklib library. I don't know if I
would call this a general solution, though.