> From: tim hall [mailto:tech@xxxxxxxxxxxxxxxxxxxxxxx] > Last Tuesday 13 July 2004 02:43, ricktaylor@xxxxxxxxxxxxx was like: > > > Entering textual representation of music and following certain _markup_ > > > rules is not programming. If it were so, simply scoring should be > > > considered programming, too. > > > > It probably is in csound. > > Surely it counts as scripting, like an html page or postscript file and thus > can be considered the 'source' of a piece of music. > > > I think the above methods need to somehow be extended to work with > > samples. Either that or computer audio needs its own form of musical > > representation. > > > > Maybe we need to just skip the idea of any sort of representation outside > > of a song or audio file? If so... maybe we need to break with tradition a > > bit and make "song" files themselves provide a higher degree of > > functionality? > > A score needs to be a human-readable explanation of how to realise the piece > of music so that it sounds the way the composer intended. The use of samples > in a piece would need specifying in the same place as the rest of the > instrumentation with clear directions of how to get hold of these samples. > These things could easily be represented by an icon and a link. So any net enabled computer could read this sound file... http://wam.inrialpes.fr/software/limsee2/ I really don't see the point of distributing the file with sequencing information. The audio itself is as descriptive of the sequence as the song file could be. If there were a sufficient number of online sample servers {with sufficient bandwidth...} it might begin to make sense. Most of what I use {that I call samples} is around the length of a standard song {1-8 minutes}. I really don't use loops as loops... I use them to generate longer sequences which, in turn, get mixed into the mix. :} {My stuff is probably more properly defined as "sound" than "noise".} > > > I don't think that computer programs should reflect the physical world > > > we operate in. Not always anyways, there surely are better ways of > > > dealing with certain issues. > > > > I think they should probably reflect the "reality" they deal with. > > I also think they need an overhaul. > > I think scoring is an art form in itself, I also think that the conventional > form of musical score is an anachronism that belongs with the musical > fashions of 1700 to 1950. I also enjoy working with the random factor of > interpretation so I like to present my performers with alien looking musical > maps to explore sometimes, but I wouldn't want to do that to my community > choir, I'd never hear the end of it! ~They get conventional scores ;-)~ I think you're probably right in calling it an "anachronism" and leaving it at that. I think it's time to move on to XML and SMIL {with appropriate extensions for sequencing languages like csound, ...midi, etc. } and to present stuff over the web or with large 4 color glossy inkjet prints. > If you deal with any amount of electronic instruments, then your scoring > language will require considerable extension. If it contains computerised > elements, then we may as well use existing computer conventions to describe > those elements. I think the reality of that is burning it all to CD and > distributing that with the score if it's that important to the piece. Then > you get to the point where it works out cheaper just to put the score on the > CD as well and have done with it! Usually I find there's enough room for > several demo versions, and there you have it, rehearsal copies for all into > the bargain. I'm for putting it on cd... Are we talking "language" or "file format" here? {Seems to me that any sufficently enabled file format should be readable in just about any language. :}} :} One file format to bind them all...
