New product, new name - what's the difference?
If you've already read the FAQ
, you'll understand that while Geist is a spiritual successor to GURU, it is not a direct replacement. If you haven't, please read it
first. This post elaborates a little on the design decisions behind Geist.
User feedback on GURU & design challenges
When we began the Geist design and development programme, we talked extensively to users & testers about perceived & actual design flaws in Guru's various versions.
There were two main issues that people reported, time and again:-
* The quality of the individual components that comprise the overall GURU system were not as high as they could and should be.
* The intuitiveness of the interface left a lot to be desired, especially for infrequent users and those looking for a predictable outcome (rather than, shall we way, random exploration in the hope of interesting or inspiring results).
The first point was relatively straightforward - if time consuming - to address. We progressively rebuilt each component to a very much higher standard. So you'll find, for example, a much nicer browser and sequence editor; full undo/redo history; multi threaded loading; DCAM circuit modeled filters and compressors (yep, those filters!); Dirac3 time compression/expansion and pitch shift developed by DSP genius Stephan M. Bernsee; a slicer that uses onset detection & hit classifier tech developed in conjunction with the world-renowned Center for Digital Music at Queen Mary, University of London (QMUL). There are, however, some existing components and much desired new features that could not be (re)built to this standard in time for v1.0 and we will be progressively adding those (obvious examples being full MIDI-implementation remapping, constructive randomization functionality, synthesis and OSC support) as time and resources permit.
The second was more challenging - we had to look at every aspect of the design, every operation, and consider whether they were both intuitive and predictable. There was much discussion in the early design phase as to where the emphasis should be - either in direct usability or in creative exploration and random generation.
However, there's a fundamental problem with algorithmic / generative composition as follows:- to get musical, original results outside of a narrow sonic spectrum, you need to either understand the algorithm (great if you're a Comp Sci Ph.D. and / or Brian Eno, not so great for everyone else) or surrender yourself to not understanding it (at which point you're ceding control of your composition to the computer - or, more accurately, to the people who programmed it). Neither is attractive for most musicians/producers, so we prioritised Geist's design on quickly and musically getting from A to B, rather than A to I-don't-know-let-the-computer-decide. Think of it, if you like, as a vote of confidence by the tool-makers (us) in the tool-users (you) as regards your creative skills - the creative spark has to come from the user, the tool is just that.
So with Geist there is less reliance on modifier keys (difficult to remember for many); less emphasis on (mis)matching the score extracted from one loop against the sounds from another (hard to predict the result; even with state-of-the-art detection / classifcation algorithms you have to roll the dice many times to get something musical; even when you do it's hard to reproduce it subsequently); the colour groups automation system has been replaced by a more standard MIDI Learn for knobs and sliders. The pay-off is an interface that makes it easy for everyone to find all the available functionality - many simply never discovered or understood the depth of what was on offer with GURU - and has allowed us to build, for example, a slicer that outperforms the industry's favourite semi-automatic standalone slicer.
Hope this clarifies things a bit & I'm happy to try and answer any further questions in this thread.