there is an interesting talk bei Robert Henke online:
He very convincingly argues that more (technical) options in fact interfere with creativity (something also Brian Eno is not getting tired to promote). Besides that he also talks about why Ableton was programmed as it was (i. e. the technician/musician’s need for a tool which better supports a specific work process).
I could not resist to see some interesting similarities to Sonic Pi and the way you begin to think about music once you work with it. In a way Sonic Pi seems to be a much more consequent approach while Ableton seems to turn - that’s what we say in German - into a “eierlegende Wollmilchsau” (something which can do everything and therefore seems to lack profile).
Disclaimer: I have no deeper experience with Ableton and so I might be wrong on that.
Interestingly Henke is quite critical about the product ‘Max to Live’ because it brings programming to music thus even multiplying the abundance of options even more. Well, I can understand, why he is saying that, but you can implement creative limitations (if you want that) on every level. Meanwhile I consider this an integral part of my quest (in this respect it can be quite liberating to lack a proper programming background).
He seems to be a very intelligent and thoughtful bloke!
I have a lot of time for Robert Henke. I was on a panel with him a few years ago and had the pleasure of talking to him in depth about many of these things.
I completely agree that too many options interferes with creativity. However, I don’t necessarily equate programming to an overload of options. Personally I found SuperCollider to have too many options (just like Max MSP) which acts as a barrier to entry in addition to polluting the creative space for options. Sonic Pi actually imposes a number of hard restrictions (no direct synthesis design, limited randomisation, stereo signal chains, limited synth creation and manipulation options and a hard distinction between generation synths and FX synths (something SuperCollider doesn’t recognise in favour of greater configurability).
When thinking about this kind of thing, my mind always recalls the questions asked by Abelson and Sussman in their SICP lectures:
Every powerful language has three mechanisms for accomplishing this:
primitive expressions, which represent the simplest entities the language is concerned with,
means of combination, by which compound elements are built from simpler ones, and
means of abstraction, by which compound elements can be named and manipulated as units.
In terms of complexity, I think the challenge is to keep each of these three mechanisms simple, but not limit how they are combined. I think these concerns are not just about programming languages, but any interface where we want to communicate our intention.
If I have not made this clear, I completely agree with that.
Later in the talk Henke speaks about one of the problems of ‘programming’ music: It takes much time to do that (instead of organising loops, notes and what you have via a GUI). I do know that Sonic Pi addresses this issue; nevertheless it is up to the musician to cope with it (if she wants to ‘program’ music); he also considers programming very powerful in certain cases (namely the reuse of musical material and structures once established).
There is another talk of him (about ‘Success and Failure’ at Ableton Loop) where he talks about e. g. combining different drum loops randomly to create variety. He states that he was not concerned about the exact sound at a specific moment but rather movement and variation. It is obvious for me that this is one of the many interesting features of SP: to combine handcrafted bits with a dose of well-chosen randomization.
In my experience a very fruitful question (as a creative source) is: What music does SP ask for? This seemingly submissive starting point does indeed lead to interesting results, which I can then explore further.