generateMelodicSeed = slow 4
$ linger 0.5
$ repeatCycles 3
-- $ palindrome \n
$ (+ (slow (irand (4)+1) (sometimes (inversion) (run (irand (4)+1)))))
$ slow ((irand 3) + 1)
$ e ("x"<~>(irand 8)) 8
$ "x*16"<~>(irand 5)
d2
$ note
((scaleP scalePattern
$ (rotR 3.5)
-- $ inversion \n
$ (+ slow 8 "x" <~> ((0.5 ~>) generateMelodicSeed))
-- $ slow 2 \n
$ generateMelodicSeed
) - 12)#s "[pe-gtr:9,midi]" #gain 1.2 #orbit 1 #midichan 2
d1
$ note
((scaleP scalePattern
$ off 4 ((+ 2 ).slow 2)
$ off 1 (inversion.slow 2)
$ off 3 (inversion.slow 3)
$ off 1.5 ((+ 2).rev.slow 2)
$ generateMelodicSeed
))#s "[pe-gtr:10,midi]" #gain 1 #orbit 0 #midichan 1
d3
$ note
((scaleP scalePattern
$ (rotR 4)
$ (+ slow 8 "x" <~> ((0.25 ~>) generateMelodicSeed))
-- $ slow 4 \n
$ generateMelodicSeed
))#s "[pe-gtr:8,midi]" #gain 1.2 #orbit 2 #midichan 3
Referential Transparency
:cc0:
Often discussed in conjunction with the paradigm of Functional Programming, Referential Transparency is the property of pure functions that always guarantees the same return value for a given set of arguments. When a function is pure, it has no side effects, and relies on only the values of its arguments to determine the return value. This means that you will always receive the same return value for a given set of arguments.
This property is extremely useful when: - Unit Testing: Referential transparency enables "black box" testing of a function or composition of functions. Cases are depended on only input and output data, they require no mocking, and are generally more simple to reason about. These tests only care about the implementation details in so far as they effect the return value. - Designing Code: The guarantee of consistent behavior makes it easier to reason about the behavior of the code under a variety of circumstances and isolates the code from the world of things that may fail or misbehave. (eg. filesystems, Networks, other processes, ect...) Additionally it makes it safer to compose the functionality of functions together, which is helpful in designing more complicated algorithms from simple parts. - Concurrency: Referential transparent code never mutates outside values and instead deals with copies. In many circumstances this makes it easier to share a data boundary with some asynchronous concurrent process without resorting to mutex locks and risking deadlock scenarios.
In my opinion, Referential Transparency is the most important property of functional design and is also the most simple to translate to languages that are not specially designed for functional programming. It is possible to create referential transparent code that is not dependent on specialized language features such as Partial Application, Tail Call Optimization, or Lazy Evaluation.