Thanks William. Yes it's definitely a labout of love, and you're absolute right about the Flicker Generative Orchestra (FGO) being a personal concept. I think of this kind of work as a kind of cyborgian construction. But in place of the typical body-machine hybrid that the word "cyborg" typically conjures, here it's more of a mind-machine hybrid. Since starting this project in earnest, a little over four years ago, I've tried to keep it focused on what makes intuitive sense to my own musical sensibility. That's why I mentioned in the first post that it's a kind of personal theory of music. It answers the question: "How does music work?" But the answer is focused on my own understanding of what music is. It's not trying to be a comprehensive theory of music, which I doubt is even possible given the variety of forms and cultural differences that make one come back with "Which music?". To which I'll answer: "My music." I don't care, at this point, for instance that it doesn't know much about functional harmony, because I'm simply not that interested in that in my own work. I have other approaches to pitch relationships. On the other hand it does, I think, do interesting things with the relationships between parts that reveal my interest in counterpoint. The fact that it's doing a pretty good job of sounding like performed music is, I believe, because I've been playing music my whole life. I've also spent a lot of time aligning the theoretical insights of others with my own embodied sense of what's going on when I play a line "expressively". If the theory doesn't align with that I'm skeptical of it's usefulness. If it then also fails to produce something my ears are pleased with I move on. I'm a firm believer that our music software must be musical. That is, it has to be grounded on an encoding of musical knowledge. That's why I long ago lost interest in the use of randomness, cellular automata, strange attractors, and the host of other algorithmic approaches to generating music because then almost universally produce unmusial results. Just google "generative music" on youtube for a list of, to my ears, unmusical results of these kinds of experiments. Or perhaps I should put it a bit more diplomatically: That's not the way (my) music works. I want to work with a system that I can interact with in terms of the language of music, not mathematics. I want to be able to think in the language of music and express as much as possible those thoughts with my computational assistant in that same language.
And yes, I've had moments of foolish abandon, and under the well-meaning influence of family and friends, in which I considered starting a crowd-sourcing campaign to push the development of some these techniques to that marketable state you mentioned. The automatic performance tool seemed like the most viable piece to start with. A constant refrain we hear on this and other related forums is form people who are first starting out using these comprehensive libraries. Where to start? Why would I choose this articulation over that one? In what context might it be useful? How is this one better than that one? etc. Add to that someone with a limited knowledge of orchestration or even experience playing an instrument that demands the detailed embodied knowledge that a violin requires to do with "style", and it's easy to see why there's also a demand for "out of the box" solutions. The work I'm doing with FGO is perhaps a proof-of-concept for an more advanced form of Humanizing that could be developed for Vienna Instruments Pro. The talented engineers at VSL are no doubt working on these kind of techniques behind the scenes. There's been good research into automatic performance systems around for years now. See the work of Friberg and Sunders on this. They worked out a set of rules for rendering expresssive performances that influenced some of the startegies in FGO. Even without encoding it into an automated system their work is worth a look for composers using comprehensive sampe-based libraries looking for articulation selection strategies. It seems to me that by now there should have been some tools produced based on that and other research in this area. I get impatient and start building my own.
I think more artists with programming skills should do the same to help guide the direction the industry takes, which is mainly why I responded to Cyril's open request for feedback on "tools". An automatic performance tool is an obvious missing link in VSLs ecosytem of fabulous tools. The best advice I've seen on this forum, aside from encouragement to learn as much about music theory, composition, instrumentation, orchestration, harmony, counterpoint, performance, etc. in order to make good choices on how to bring your music to life, can be summed up as "map it to the form" and "mix it up". Mark the important structural points in the music, including melodic form, and try to use as much variety as you can. There's even been suggestions that one use a different articulation on virtually every event. That is, indeed, a very good way to get a richness and lively quality to the music, particularly if you know something about how the instruments you're working with are played expressively. It's just depressingly labour intensive. I've been thinking of this problem of how to make smart selections from the large pool of options the VSL libraries offer as a small Big Data problem. It's crying out for a role to be provided for an intelligent assistant. That's at least one of the reasons for the specialization of composers, orchestators, conductors, score preparators, section leaders, performers, etc.. It's a huge and complex task with loads of expertise and time spent in mastering each part of the whole thing. Enter the thought machine. We're now on the cusp of an era in which our computional assistants are skilled enough, fast enough, and know enough to be viable assistants in this process, allowing someone to realize the potential of the wonderful resources provided by these libraries. Of course, some will object, raising concerns about the machines taking over tasks that are distinctly human or precious to us in the sense that these are the things that make us human. I take a much more optimistic view that we're allowed to think at a higher level with the computational system taking on a lot of the grunt work. It's skilled work, yes, but grunt work nonetheless. Particularly when you consider that our current crop of super-computers can do that work in the blink of an eye, work that would take a composer weeks if not months of labour. I'd rather be dreaming up new musical ideas for my computational assistant to chew on. It's a kind of "intelligence amplification".
So, as soon as you start seriously considering what is involved in making such a tool truly responsive to the needs of a variety of users, the demands of keeping up with cross-platform issues, operating system changes, getting it to work with other libraries, dealing the bugs and failures that are constantly being introduced by the inherent instability of our computational landscape. Witness the heroic efforts by our friends here at VSL to get Vienna Ensemble Pro 6 up and running smoothly. That requires a team of talented people who have no time to do anything else during those times when you introduce something new and complex to the already overly complex computational landscape of hardware-software interdependencies. I understand that world, having spent a few years working in the game industry coding audio behaviors. In short, I don't have time. I need to stay focused on the music. So I live with the instabilities inherent in experimental software. Try to keep a balance between the time spent on design, coding, integration, testing, refining and actually producing music. I'm not willing to give up that last part to perfect an engineering problem. Gotta keep the focus on the music now.
That's my story... and I'm sticking to it ;-) Now back to work on things musical.
