Re: [music-dsp] Boulez
Douglas, I think my wife Ariane, who plays First Violin in the Neue Philharmonie Westfalen, can relate to your description of the activities of an orchestra musician. A few years back she was reprimanded when an audience member told management they had seen (from up in a balcony) a female violinist playing Sudoku during a slow section of a musical. Ari had hoped no one would notice her, tucked away down in the pit, LOL. Better to just put a book on the music stand. ;-) Kind Regards, David Reaves On Sat, 25 Feb 2012 20:43:04, douglas repetto doug...@music.columbia.edu wrote: snip But that's not really how live musicians tend to think of it. It's not like a violinist keeps her bow moving at all times and only touches it to the strings when there's a note to be played. But that's kinda what sending zeros to a buffer when there's no sound is like. On the other hand, if you work directly in hardware (say using an analog synth, hooking up logical oscillators, or programming a microcontroller) you can take a very different approach. You twiddle some output pins when you want sound and when you don't want sound you can just go off and do other things. In many ways I think that's a lot more like what many musicians do -- when you're not playing (either because you've got a bunch of rests, or maybe you're playing improvised music and you're just sitting out for awhile, or whatever) you don't really sit there counting off the beats. You stop playing. You might think about other things. After awhile hopefully you'll notice that the conductor is about to cue you in, or you get an idea and decide to join the improvisation, etc. I've seen people reading books in Broadway orchestra pits... snip -- dupswapdrop -- the music-dsp mailing list and website: subscription info, FAQ, source code archive, list archive, book reviews, dsp links http://music.columbia.edu/cmc/music-dsp http://music.columbia.edu/mailman/listinfo/music-dsp
Re: [music-dsp] guitar physical model
http://music.columbia.edu/~brad/music/mp3/Rough_Raga_Riffs.mp3 This. I just listened to it and it put me in a good mood! -- dupswapdrop -- the music-dsp mailing list and website: subscription info, FAQ, source code archive, list archive, book reviews, dsp links http://music.columbia.edu/cmc/music-dsp http://music.columbia.edu/mailman/listinfo/music-dsp
Re: [music-dsp] a little about myself
On Feb 26, 2012, at 12:48 AM, Ross Bencina wrote: In my view, anyone who cares about being a composer of *computer music* (in the context of this dicussion) needs at least the following (or equivalent) undergraduate knowledge: 1) music composition degree 2) computer science and/or software engineering degree 3) electrical engineering degree Maybe even this is required: 4) Tonmeister/ sound engineering degree I would like to agree with you, because I also value all these things (and am pretty much a dilettante in all four). But I see an analog with the is a DJ *really* a [computer music] composer? question that floats around (or in an earlier generation, is a collage artist...). Most DJ things I find just annoying, but lately I've heard a few that are quite interesting, and also operating independent of the categories 1-4 above that I know and love. I guess it's the in the context of this discussion qualifier that makes the difference here. brad http://music.columbia.edu/~brad -- dupswapdrop -- the music-dsp mailing list and website: subscription info, FAQ, source code archive, list archive, book reviews, dsp links http://music.columbia.edu/cmc/music-dsp http://music.columbia.edu/mailman/listinfo/music-dsp
Re: [music-dsp] a little about myself
On 27/02/2012 1:11 AM, Brad Garton wrote: We're fooling around with the new Max/MSP gen~ stuff in class, it seems an interesting alternative model for low-level DSP coding. Once they figure out how to do proper conditionals it will be really powerful. Why anyone would want to use a visual patcher to write low level code is beyond me though. Managing complexity in Max is already a nightmare compared to using text-based development methods and tools. Not to mention how quickly you can type code compared to patching it. They should have just added an object for live coding assembly language (only half kidding). Ross. -- dupswapdrop -- the music-dsp mailing list and website: subscription info, FAQ, source code archive, list archive, book reviews, dsp links http://music.columbia.edu/cmc/music-dsp http://music.columbia.edu/mailman/listinfo/music-dsp
Re: [music-dsp] a little about myself
On Feb 26, 2012, at 5:13 AM, Richard Dobson wrote: One way or another, every user is limited by what those systems do not enable; Yes! and I would argue that of all of them, Csound offers the fewest limitations. No!! :-) (and the no refers doubly to 'let's not have that argument) brad http://music.columbia.edu/~brad -- dupswapdrop -- the music-dsp mailing list and website: subscription info, FAQ, source code archive, list archive, book reviews, dsp links http://music.columbia.edu/cmc/music-dsp http://music.columbia.edu/mailman/listinfo/music-dsp
Re: [music-dsp] a little about myself
On Feb 26, 2012, at 9:25 AM, Ross Bencina wrote: Why anyone would want to use a visual patcher to write low level code is beyond me though. Managing complexity in Max is already a nightmare compared to using text-based development methods and tools. Not to mention how quickly you can type code compared to patching it. They should have just added an object for live coding assembly language (only half kidding). I completely agree. However, I find myself exploring aspects of an implemented DSP algorithm in ways that I wouldn't using a text-based approach. It's kind of like trying to write poetry in a second language, you occasionally find yourself constructing things you would not have otherwise. All these various languages facilitate different kinds of 'tweakiness', and for me a lot of the fun is seeing where a particular approach might lead... brad (who really is a text-based kinda guy) http://music.columbia.edu/~brad -- dupswapdrop -- the music-dsp mailing list and website: subscription info, FAQ, source code archive, list archive, book reviews, dsp links http://music.columbia.edu/cmc/music-dsp http://music.columbia.edu/mailman/listinfo/music-dsp
Re: [music-dsp] a little about myself
On Sun, Feb 26, 2012 at 09:11:10AM -0500, Brad Garton wrote: On Feb 26, 2012, at 5:13 AM, Richard Dobson wrote: It is rather more flexible than Max/MSP, say, because you can if you want to run a single-sample vector, whereas MSP has always been fixed to a 64-sample block size. I don't think that's actually true... We're fooling around with the new Max/MSP gen~ stuff in class, it seems an interesting alternative model for low-level DSP coding. Once they figure out how to do proper conditionals it will be really powerful. brad For a long time, there has been the equivalent trick to that which Michael mentions for Csound, setting ksamps = 1, only in Pd/Max you set blocksize =1. While these seem superficially similar, and both have the same outcome that you can do control calculations on a per sample basis, they are conceptually different, in the same sense that multi-rate and pull dataflow differ. cheers, Andy -- dupswapdrop -- the music-dsp mailing list and website: subscription info, FAQ, source code archive, list archive, book reviews, dsp links http://music.columbia.edu/cmc/music-dsp http://music.columbia.edu/mailman/listinfo/music-dsp
Re: [music-dsp] a little about myself
On Feb 26, 2012, at 9:38 AM, Andy Farnell wrote: For a long time, there has been the equivalent trick to that which Michael mentions for Csound, setting ksamps = 1, only in Pd/Max you set blocksize =1. While these seem superficially similar, and both have the same outcome that you can do control calculations on a per sample basis, they are conceptually different, in the same sense that multi-rate and pull dataflow differ. Andy -- could you unpack this a little for me? Are you referring to the independence between the 'control rate' and the underlying blocksize that you get in Csound (and others)? if so, what are the some of the real effects that this might have? I'm not being pejorative with these questions, I honestly don't understand what you mean. brad http://music.columbia.edu/~brad -- dupswapdrop -- the music-dsp mailing list and website: subscription info, FAQ, source code archive, list archive, book reviews, dsp links http://music.columbia.edu/cmc/music-dsp http://music.columbia.edu/mailman/listinfo/music-dsp
Re: [music-dsp] a little about myself
On 27/02/2012 1:22 AM, Brad Garton wrote: I would like to agree with you, because I also value all these things (and am pretty much a dilettante in all four). But I see an analog with the is a DJ*really* a [computer music] composer? question that floats around (or in an earlier generation, is a collage artist...). Other analogous questions include Should the artist be a programmer?, Must creative engagement with computers involve programming? Then there is the whole schtick of composer as Auteur directing the technical minions to do the programming for him/her. A variant might be Composer buying pre-made tools to use to make their music. I liked Andy's reference to second order culture earlier. This is one way of looking at software reuse by composers. Another is the instrument-builder - instrument - composer-performer relation. Most DJ things I find just annoying, but lately I've heard a few that are quite interesting, and also operating independent of the categories 1-4 above that I know and love. Of course you don't need all the aforementioned computer skills to use a computer to make *music*, and I wouldn't dare to ascribe relative value to the different areas of musical engagement with computers. Great music is being made in all sorts of different ways -- and a computer is sometimes part of that. But I think it's when the composer engages with the computer *as a computer* (whatever that means, but I think it involves programming, or algorithmic processes, or some uniquely digital manipulation methods, not as a virtual real thing) that it becomes computer music composition in the specialised sense meant here. I guess it's the in the context of this discussion qualifier that makes the difference here. Yeah. There is such a thing as specialised computer music composition that takes in all those disciplines -- and in my view, the limits of the tools we are discussing are especially relevant within that context. If you come at it from a found object perspective, the tools have certain affordances -- they're good at certain things. My impression is that Richard has suggested that what they are good at and what they are intended for is the same thing.. but I'm not convinced. Ross. -- dupswapdrop -- the music-dsp mailing list and website: subscription info, FAQ, source code archive, list archive, book reviews, dsp links http://music.columbia.edu/cmc/music-dsp http://music.columbia.edu/mailman/listinfo/music-dsp
Re: [music-dsp] guitar physical model
Me too, Some great Steve Hillage like moments in that. On Sun, Feb 26, 2012 at 10:52:12AM +0100, Emanuel Landeholm wrote: http://music.columbia.edu/~brad/music/mp3/Rough_Raga_Riffs.mp3 This. I just listened to it and it put me in a good mood! -- dupswapdrop -- the music-dsp mailing list and website: subscription info, FAQ, source code archive, list archive, book reviews, dsp links http://music.columbia.edu/cmc/music-dsp http://music.columbia.edu/mailman/listinfo/music-dsp -- dupswapdrop -- the music-dsp mailing list and website: subscription info, FAQ, source code archive, list archive, book reviews, dsp links http://music.columbia.edu/cmc/music-dsp http://music.columbia.edu/mailman/listinfo/music-dsp
Re: [music-dsp] guitar physical model
Thanks! I always wanted to play the guitar, but I wasn't any good. LISP to the rescue! brad http://music.columbia.edu/~brad On Feb 26, 2012, at 9:50 AM, Andy Farnell wrote: Me too, Some great Steve Hillage like moments in that. On Sun, Feb 26, 2012 at 10:52:12AM +0100, Emanuel Landeholm wrote: http://music.columbia.edu/~brad/music/mp3/Rough_Raga_Riffs.mp3 This. I just listened to it and it put me in a good mood! -- dupswapdrop -- the music-dsp mailing list and website: subscription info, FAQ, source code archive, list archive, book reviews, dsp links http://music.columbia.edu/cmc/music-dsp http://music.columbia.edu/mailman/listinfo/music-dsp -- dupswapdrop -- the music-dsp mailing list and website: subscription info, FAQ, source code archive, list archive, book reviews, dsp links http://music.columbia.edu/cmc/music-dsp http://music.columbia.edu/mailman/listinfo/music-dsp -- dupswapdrop -- the music-dsp mailing list and website: subscription info, FAQ, source code archive, list archive, book reviews, dsp links http://music.columbia.edu/cmc/music-dsp http://music.columbia.edu/mailman/listinfo/music-dsp
Re: [music-dsp] a little about myself
On Feb 26, 2012, at 9:48 AM, Ross Bencina wrote: Then there is the whole schtick of composer as Auteur directing the technical minions to do the programming for him/her. Oh my *favorite* paradigm! Ya just gotta love the cultural model that puts forward, too. brad http://music.columbia.edu/~brad -- dupswapdrop -- the music-dsp mailing list and website: subscription info, FAQ, source code archive, list archive, book reviews, dsp links http://music.columbia.edu/cmc/music-dsp http://music.columbia.edu/mailman/listinfo/music-dsp
Re: [music-dsp] a little about myself
On Feb 26, 2012, at 12:48 AM, Ross Bencina wrote: .. 1) music composition degree 2) computer science and/or software engineering degree 3) electrical engineering degree .. Hmm, software engineering would preferably be covered by EE, but of course there are differences in emphasis. And I doubt it's better to have a conservatory degree than be called Ludwig vonin some joint of history, though a good degree wouldn't stop the Commodores from making interesting music, of course. Let's not comfuse the desires of a New Age talking about movements with decent leadership, and proper academic or even universal definitions of subject boundaries, please ? Theo -- dupswapdrop -- the music-dsp mailing list and website: subscription info, FAQ, source code archive, list archive, book reviews, dsp links http://music.columbia.edu/cmc/music-dsp http://music.columbia.edu/mailman/listinfo/music-dsp
Re: [music-dsp] a little about myself
On 26/02/2012 14:11, Brad Garton wrote: On Feb 26, 2012, at 5:13 AM, Richard Dobson wrote: It is rather more flexible than Max/MSP, say, because you can if you want to run a single-sample vector, whereas MSP has always been fixed to a 64-sample block size. I don't think that's actually true... It used to be; maybe it is more flexible in version 6. I have never owned it, so my knowledge is somewhat sparse and anecdotal. Richard Dobson -- dupswapdrop -- the music-dsp mailing list and website: subscription info, FAQ, source code archive, list archive, book reviews, dsp links http://music.columbia.edu/cmc/music-dsp http://music.columbia.edu/mailman/listinfo/music-dsp
Re: [music-dsp] a little about myself
On Feb 26, 2012, at 12:48 AM, Ross Bencina wrote: In my view, anyone who cares about being a composer of *computer music* (in the context of this discussion) needs at least the following (or equivalent) undergraduate knowledge: 1) music composition degree 2) computer science and/or software engineering degree 3) electrical engineering degree Maybe even this is required: 4) Tonmeister/ sound engineering degree Guess that means I should not be here. No musical qualification beyond a poor 'O' level, no Computer SCience degree, no knowledge of electrical engineering (and very little of electrical science) and certainly not sound engineering. So perhaps I will return to grubbing in the dirt and clashing rocks together ==John ff -- dupswapdrop -- the music-dsp mailing list and website: subscription info, FAQ, source code archive, list archive, book reviews, dsp links http://music.columbia.edu/cmc/music-dsp http://music.columbia.edu/mailman/listinfo/music-dsp
Re: [music-dsp] a little about myself
On 26.02.12 16:46, Theo Verelst wrote: Of course most all computer languages have serious limitations, too: none allow explicit parallel programming concepts, native associative behaviour, and even simple mathematical reasoning takes a heavy LISP program to begin with (Like Maxima), and a lot of programming skills are essentially a training in the feasibility of a certain amount of efficiency with a language, either to express an idea in the language, or to make the language when compiled/interpreted and run on a machine to work efficient enough on it to achive the programming purpose. Without a clear definition of what explicit parallel programming concepts or native associative behaviour is supposed to mean it is impossible to say whether any given programming language supports either one. Simple mathematical reasoning does not take the whole of Maxima, Reduce or the like. Simple mathematical reasoning can be done by relatively short programs that in some courses students create as part of their homework assignments. But again it is impossible to judge this without a clear definition of simple mathematical reasoning. I mean the whole of the software boys and gals ideas aren't going to make either the new Marshall or Les Paul ever. I doubt seriously if the collective software world without external guidance could sit together and finish a random electrical engineering exam from the first year if they'd have a week time, and their lives depended on it. Seriously. I seriously doubt that this is true. Seriously. But perhaps it depends on some very specific idea of what the collective software world is. A little bit of scientific thinking can go a long way when trying to explain some point of view such that other people can actually understand what is or is not meant by any given statement. Thomas -- dupswapdrop -- the music-dsp mailing list and website: subscription info, FAQ, source code archive, list archive, book reviews, dsp links http://music.columbia.edu/cmc/music-dsp http://music.columbia.edu/mailman/listinfo/music-dsp
Re: [music-dsp] a little about myself
On Sun, Feb 26, 2012 at 04:01:52PM +, Richard Dobson wrote: For my sonification work for LHCsound, I used Perl to parse data files and generate Csound scores, simply because it is a task Perl is canonically optimised to do and scripts can be run up very quickly. Just a quick +1 for Perl as an event generator in cooperation with Csound, especially if the project involves any kind of network processing. Andy -- dupswapdrop -- the music-dsp mailing list and website: subscription info, FAQ, source code archive, list archive, book reviews, dsp links http://music.columbia.edu/cmc/music-dsp http://music.columbia.edu/mailman/listinfo/music-dsp
Re: [music-dsp] a little about myself
On 26/02/2012 05:48, Ross Bencina wrote: .. (1) An efficient way to implement a runtime compiler for block-based audio DSP chains (these are what are in software synthesizers)... which usually are based on As if block-based DSP chains are the only way to make sound with a computer. Indeed they are not; but they are often the most efficient way to do it while retaining flexibility of configuration. For much the same reason that block-based access to a disk file is so much more efficient than single-word access that the latter never happens. Most audio devices for general-purpose computers have no choice but to deliver audio to the host in bursts of, say, 32 samples, so the audio is already being supplied as a block rather than single samples. Given the choice of one function call on a vector, or 32 function calls on a sample, there can still be many reasons to choose the former. .. .. The assumption here is that the target audience is the non technical musician. I think this is completely spurious. Talking about limitations or capabilities of computer programming languages is kind of pointless if you allow for the novice user who doesn't even know what a turing complete language can do. Exactly true. It is only relevant to programmers. We can drive a car pefectly well, and even do or direct basic maintenance on them, without knowing the minutiae of metallurgy or chemistry, and we can light and enjoy a firework without knowing anything about Newton's laws (or chemistry, again). Maybe just a bit about health and safety. And we can enjoy a film and use a GPS system without having to know anything about the interactions of photons and electrons or the relativistic compensation of satellite signals. All these things are interesting, and for those whose business is building them, essential. But carbon-based life forms have managed to jump, swim, fly, throw and catch for millennia without having any idea how gravity really works, or what momentum really is. People (UK-based) concerned about the public's level of education with respect to computing may be interested to join the Computing At School community, dealing with the newly announced UK initiative to all but replace the existing ICT curriculum with a computer science one involving real programming. One tool widely used at primary level is called Scratch, developed at MIT: http://scratch.mit.edu/ It supports some music programming, but arguably could do very much more in that area. In my view, anyone who cares about being a composer of *computer music* (in the context of this dicussion) needs at least the following (or equivalent) undergraduate knowledge: Although I go along with the collective and use the term, I do not believe there is actually such a thing as computer music, outside the usual limitations of the language myth. At the very least, I would question if everyone using that term means it in the same way. There is music (or sound art) that has been composed or performed using computers, and in practice there are sounds which we either know or assume depended on computers (or tape, or strange electronics) to make them. There is also music composed using algorithmic techniques, but these do not all need computers, unless in the old meaning of one who computes. The vast majority of what is popularly called computer music is well within the classical paradigm of instruments and notes, rhythms and harmonies, drones and moments, active performers and passive listeners, and can be listened to and enjoyed with no more than the corrsponding vernacular musical listening skills. A basic definition of electro-acoustic is no more than music/sound presented using loudspeakers. The somewhat astonishing but also understandable enthusiasm for all things analogue and retro suggests that for most people computers are best seen but not heard! Computers, in the end, are used because comparatively speaking they are either cheaper and/or faster than the available alternatives of comparable scale. This is not to trivialise them at all (most of my life and work involves them, after all), but it is not to over-romanticise them either. They remain strictly a means to an end (unless your thing is designing them). However, it is clear that composers of computer music very intensely and understandably want their skills to be recognised and appreciated; easy enough with a physical instrument, a printed score and ready comparisons, but not so much when all you have to show for it is hunched shoulders over a laptop, or a CD and brief programme note. So, the more informed the public is about computing, the more they will appreciate those who are adepts. The only other way is if the programming seems truly impossible or mould-breaking - witness the admiration given to the Melodyne developers, for example. Sadly the public is so used to breakthroughs on a yearly basis, that soon enough they
[music-dsp] high-level vs. low-level coding of algs
changed the subject line to something more accurate... On 2/26/12 9:25 AM, Ross Bencina wrote: On 27/02/2012 1:11 AM, Brad Garton wrote: We're fooling around with the new Max/MSP gen~ stuff in class, it seems an interesting alternative model for low-level DSP coding. Once they figure out how to do proper conditionals it will be really powerful. Why anyone would want to use a visual patcher to write low level code is beyond me though. Managing complexity in Max is already a nightmare compared to using text-based development methods and tools. Not to mention how quickly you can type code compared to patching it. They should have just added an object for live coding assembly language (only half kidding). On 2/26/12 9:31 AM, Brad Garton wrote: I completely agree. However, I find myself exploring aspects of an implemented DSP algorithm in ways that I wouldn't using a text-based approach. It's kind of like trying to write poetry in a second language, you occasionally find yourself constructing things you would not have otherwise. All these various languages facilitate different kinds of 'tweakiness', and for me a lot of the fun is seeing where a particular approach might lead... i have never used Max. i have programmed algs at pretty much the lowest level using either C or the asm for some particular chip. in my opinion, the optimal division of labor becomes obvious if your system modularizes specific low-level algs. when i worked at Eventide 2 decades ago, i thought that division of high level vs. low level was pretty much natural and optimal. on the low level we programmed blocks where the sample processing was in the 56K assembly and the coefficient cooking was in C. they wrote some pretty good tools that fished the symbols outa the linkable object code that came outa the assembler and the coefficient cooking code could write to specific DSP variables as symbols. you didn't need to note where the DSP address was, it would find it for you. the coefficient cooking code was executed only when a knob was twisted, but the sample processing code was running all the time after it was loaded. a typical example would be an EQ filter where user parameters (like resonant frequency, Q, boost/cut gain) would go into the block from the outside and the coefficient cooking code would cook those parameters and send the coefficients to the DSP where the DSP was expecting them to go. but patching these blocks together was (eventually) done with a visual patch editor. if, to create an overall effect, you're laying down a modulatable delay line here, a modulatable filter there, and some other algorithms that have already been written and tested, with definable inputs and outputs, why not use a visual editor for that? but, if you need a block that does not yet exist, you need to be able to write hard-core sample processing code in a general purpose language like C (or the natural asm for a particular chip). then turn that into a block, then hook it up with a visual editor like all of the other blocks. -- r b-j r...@audioimagination.com Imagination is more important than knowledge. -- dupswapdrop -- the music-dsp mailing list and website: subscription info, FAQ, source code archive, list archive, book reviews, dsp links http://music.columbia.edu/cmc/music-dsp http://music.columbia.edu/mailman/listinfo/music-dsp
