Re: [music-dsp] a little about myself
Also, as in traditional music disciplines, intuitive (and partial) understanding of principles can also be enough to make music, and I expect this to be the same here. This is, again, generally independent of whether we find this music good or bad. Victor On 29 Feb 2012, at 08:46, Victor wrote: In my opinion, the process here is as important as in traditional music disciplines. So I think having a good knowledge of craft is essential for a composer. In the traditinal world, this meant mastering counterpoint and harmony, tonal and post-tonal, as well as being able to think new ways of structuring the material, etc. Here, I think we have an emerging set of crafts, maybe not yet completely defined, but things like synthesis and programming might well be part of it. In the end, no one might be able to determine whether your music is worth anything, but having a good craft at least it will guarantee a certain level of structural quality (if you believe there is such a thing). In some quarters, it will be said to be professionally done. These are the things that can be taught and learned. However, as in traditional music, there is also something beyond the craft, which is hard to define. Victor On 29 Feb 2012, at 00:41, Richard Dobson richarddob...@blueyonder.co.uk wrote: On 28/02/2012 16:03, Bill Schottstaedt wrote: I don't think this conversation is useful. The only question I'd ask is did this person make good music?, and I don't care at all about his degrees or grants. One of the best mathematicians I've known does not even have a high-school diploma. If I find such a person, then it's interesting to ask how she did it. But there are very few, and no generalizations seem to come to mind. I agree, but I think such conversations can be useful. Computer Music does possibly suffer more than most from what I might mischievously call the expertise problem - how does the typical listener recognise all the skills that have been brought to bear in a piece? They presumably have to do that at least to some extent, to decide if the piece is good. The temptation I see is to focus more on the process than the product - understandable enough for a composer, but not necessarily practical for the listener. Ross, for example, stipulated that a computer musician not only needs to be a programmer, but also have undergraduate level EE expertise. The process is clearly paramount. I do wonder how that would be unambiguously apparent listening to a piece. On the CEC mailing list, the proposal was made (Kevin Austin IIRC) that in what was called High Acousmatic Art (HAA) the piece will always involve the process of transformation. That may well be widely true, but as a matter of principle I would be disappointed if that was the only possible criterion of goodness of a piece for it to qualify as HAA (assuming of course HAA can itself be adequately defined). I am really interested in what other paradigms of the compositional process could also qualify for a HAA piece. 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 -- 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 Dr Victor Lazzarini Senior Lecturer Dept. of Music NUI Maynooth Ireland tel.: +353 1 708 3545 Victor dot Lazzarini AT nuim dot ie -- 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 29 Feb 2012, at 08:46, Victor wrote: In my opinion, the process here is as important as in traditional music disciplines. So I think having a good knowledge of craft is essential for a composer. In the traditinal world, this meant mastering counterpoint and harmony, tonal and post-tonal, as well as being able to think new ways of structuring the material, etc. Here, I think we have an emerging set of crafts, maybe not yet completely defined, but things like synthesis and programming might well be part of it. 'not yet completely defined' is the key phrase for me. The craft of computer music, or indeed live electronic music may well currently require a working knowledge of programming, synthesis, acoustics, production (etc), but this is surely by necessity rather than design. A tradition of using textual programming languages to produce computer music has evolved because initially this was the only way to do it, and so computer music programming languages have become ubiquitous. I'm personally interested in new tools, interfaces and instruments that allow musicians to compose with (and for) computers without the requirement for years of study in DSP/programming. I guess UPIC, Fairlight and Kyma are earlier systems that hint towards this. The current Western orchestra, notation and musical language(s) have resulted from 100's years of development. The equivalent for 'computer music' is IMO as yet unknown, and lies somewhere in the future. I'd like to see a situation where musicians can make computer music armed only with musical ideas for sounds and processes, and no programming or DSP knowledge at all, but we're still a long way from that. Just my 2p. best, Jamie -- http://www.jamiebullock.com -- 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 28/02/2012 00:43, Michael Gogins wrote: .. What I would dearly love to hear in this discussion is how Csound can be improved to facilitate the creation of music, from people who do use software to compose and create their music. Or how some other software might be better, for that matter. For the beginner and experienced user alike, a rough spot in Csound is resource management. Perhaps because Csound comes from an offline lineage and was not conceived as a real-time system it's very easy to create monsterous things. Things that unexpectedly use all the CPU and drop out. Things that unexpectedly eat memory very fast. Of course, to paraphrase Stroustrup, you can shoot yourself in the foot with all audio DSP languages, but with Csound you absolutely positively kill every last mo___ker in the room. Better polyphony and CPU monitoring/management, with some kind resource limited subprocess concept would make it much safer. Just 2c -- 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 28/02/2012 13:05, Andy Farnell wrote: On Tue, Feb 28, 2012 at 11:04:45AM +, Richard Dobson wrote: So, one way and another, Computer music is so laden with definitions and qualifications as to have lost all definition - using it gives the listener no real information. And yet, if I were to say to you about such and such a piece of music Oh, it's computer music, you would know exactly what I mean, and what to expect. Er... You will sit in a room with a high quality sound system of no less than four loudspeakers, many of the audience will sport impressive beards, Actually, I see more pony-tails these days (mine is getting somewhat thin). and you will nod your head through excruciating expanses of silence and high frequency buzzing. Sounds like some night-clubs I used to go to. At times you will feel quite dizzy. And mistake your own tinnitus for the finale. Done that. Most recently, the performance faded out to the air-conditioning noise, which (not having particularly noticed it previously) I was convinced was the piece still fading away. The very illustrious composer had to stand up and say that's it. At the end there will be a presentation of some quite opaque equations, and afterwards cheese, wine and cordial conversation as we roam Paris or Vienna devouring haute cuisine paid for by some impossibly selective European grant money, If only! .. That's computer music. 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 Tue, 28 Feb 2012, Andy Farnell wrote: And mistake your own tinnitus for the finale. Bwahaha! I went to that concert. :-) -- Monty Brandenberg -- 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
I don't think this conversation is useful. The only question I'd ask is did this person make good music?, and I don't care at all about his degrees or grants. One of the best mathematicians I've known does not even have a high-school diploma. If I find such a person, then it's interesting to ask how she did it. But there are very few, and no generalizations seem to come to mind. -- 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 the one hand, I completely agree with Bill, I'm only interested in whether the music is good, and no, I don't think it's completely subjective. On the other hand, I do think there are many things it would be advisable for a person who wants to write good music to know. For someone who wants to write good computer music, what would be useful to know is... bewildering and hard to define! But some understanding of how good software is written, some understanding of signal processing, some understanding of musical acoustics and psychological acoustics, some understanding of music history and theory, some understanding of musical form, and above all a deep, personal immersion in music itself... deep listening. On Tue, Feb 28, 2012 at 11:03 AM, Bill Schottstaedt b...@ccrma.stanford.edu wrote: I don't think this conversation is useful. The only question I'd ask is did this person make good music?, and I don't care at all about his degrees or grants. One of the best mathematicians I've known does not even have a high-school diploma. If I find such a person, then it's interesting to ask how she did it. But there are very few, and no generalizations seem to come to mind. -- 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 -- Michael Gogins Irreducible Productions http://www.michael-gogins.com Michael dot Gogins at gmail dot com -- 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
Andy, there's an opcode called active that does what you want 'numalloc' to do: http://csounds.com/manual/html/active.html On 2/28/12, Michael Gogins michael.gog...@gmail.com wrote: On the one hand, I completely agree with Bill, I'm only interested in whether the music is good, and no, I don't think it's completely subjective. On the other hand, I do think there are many things it would be advisable for a person who wants to write good music to know. For someone who wants to write good computer music, what would be useful to know is... bewildering and hard to define! But some understanding of how good software is written, some understanding of signal processing, some understanding of musical acoustics and psychological acoustics, some understanding of music history and theory, some understanding of musical form, and above all a deep, personal immersion in music itself... deep listening. On Tue, Feb 28, 2012 at 11:03 AM, Bill Schottstaedt b...@ccrma.stanford.edu wrote: I don't think this conversation is useful. The only question I'd ask is did this person make good music?, and I don't care at all about his degrees or grants. One of the best mathematicians I've known does not even have a high-school diploma. If I find such a person, then it's interesting to ask how she did it. But there are very few, and no generalizations seem to come to mind. -- 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 -- Michael Gogins Irreducible Productions http://www.michael-gogins.com Michael dot Gogins at gmail dot com -- 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 28/02/2012 16:03, Bill Schottstaedt wrote: I don't think this conversation is useful. The only question I'd ask is did this person make good music?, and I don't care at all about his degrees or grants. One of the best mathematicians I've known does not even have a high-school diploma. If I find such a person, then it's interesting to ask how she did it. But there are very few, and no generalizations seem to come to mind. I agree, but I think such conversations can be useful. Computer Music does possibly suffer more than most from what I might mischievously call the expertise problem - how does the typical listener recognise all the skills that have been brought to bear in a piece? They presumably have to do that at least to some extent, to decide if the piece is good. The temptation I see is to focus more on the process than the product - understandable enough for a composer, but not necessarily practical for the listener. Ross, for example, stipulated that a computer musician not only needs to be a programmer, but also have undergraduate level EE expertise. The process is clearly paramount. I do wonder how that would be unambiguously apparent listening to a piece. On the CEC mailing list, the proposal was made (Kevin Austin IIRC) that in what was called High Acousmatic Art (HAA) the piece will always involve the process of transformation. That may well be widely true, but as a matter of principle I would be disappointed if that was the only possible criterion of goodness of a piece for it to qualify as HAA (assuming of course HAA can itself be adequately defined). I am really interested in what other paradigms of the compositional process could also qualify for a HAA piece. 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 29/02/2012 11:41 AM, Richard Dobson wrote: On 28/02/2012 16:03, Bill Schottstaedt wrote: I don't think this conversation is useful. The only question I'd ask is did this person make good music?, and I don't care at all about his degrees or grants. One of the best mathematicians I've known does not even have a high-school diploma. If I find such a person, then it's interesting to ask how she did it. But there are very few, and no generalizations seem to come to mind. I agree, I'm not sure whether (or which) conversation is useful, but I totally agree with good music being the important thing in the end. That said, result orientation has been the subject of criticism in certain circles, and there exists a counter view that it's the process, not the result that matters. but I think such conversations can be useful. Computer Music does possibly suffer more than most from what I might mischievously call the expertise problem - how does the typical listener recognise all the skills that have been brought to bear in a piece? (In my view) the listener need not recognise all those skills. The audience is presented with acoustic stimulus and the first order experience is usually auditory. What happens beyond that depends, among other things, on the mode of listening, but in general it's safe to say it won't typically be an experience of thinking about expert-level technical production details. The typical listener may not know much about late 19th century tonal harmony but can appreciate music that employs it. One knows when a seamstress/tailor/brain surgion/street cleaner/cabinet maker/film production team/ has done something good without needing to know about the specialised skills and tools involved. They presumably have to do that at least to some extent, to decide if the piece is good. They may recognise some of the skills, to some extent, perhaps -- but I think more often the product is experienced on its own terms, as sound. There's a genotype/phenotype relationship between skills and the musical result: maybe the skills and means are apparent, maybe they aren't -- maybe the composer has worked hard to conceal the techniques of production -- the appreciable skill might be the invisibility of the process (like the absence of visible brush strokes in the paintings of the Dutch masters.) Thuse the criteria for good music should not require recognition of all the skills that have been brought to bear in a piece. But such recognition can certainly be a component of music appreciation. Art speaks into a context which comprises of some subset of knowledge of everything that has gone before, and this could, under some circumstances, include knowledge of production processes, organising principles and structuring techniques -- whether in general, or with respect to a particular composer or work. There are forms of computational art (e.g. net art, software art, perhaps also live coding, and I mean these with reference to specific art movements) where the computational process has been aestheticised. (Perhaps analogous to the aestheticisation of concept in modern art.) One could also argue that in modern classical music, performance technique has become aestheticised. But this reification of technitution as Harry Partch called it, is by no means a universally accepted definition of what is or should be considered good. The temptation I see is to focus more on the process than the product - understandable enough for a composer, but not necessarily practical for the listener. Agreed. It can sometimes be a problem when the aestheticisation of the internal (technical) structure of an artwork is considered key to the appreciation of the artwork. Perhaps this is what you're getting at? These days I see computer practice with a strong focus on proces over product as a branch of the software art movement. Personally I think it is critical that music must be good on merits related to the domain of musical/auditory perception and cultural experience. But allowing for appreciation of computational aesthetics as an integral part of the work may also be valid -- some might even argue that computational aesthetics are more important than the musical result.. but at that point I think it ceases being music, which is why categories like software art are useful. Ross, for example, stipulated that a computer musician not only needs to be a programmer, but also have undergraduate level EE expertise. The process is clearly paramount. The driving concern here is to be sufficiently prepared to engage with the computer in an act of composer/performer programmed computation that results in musical sound -- i.e. computation as a medium of musical expression. This isn't any more about the process as it is about having the requisite skills to create the product. I do wonder how that would be unambiguously apparent listening to a piece. Ross. --
Re: [music-dsp] a little about myself
Hi Andy, Some comments, and questions for clarification... IIRC, most Music-N line of systems are multi-rate. That means we have a fast computation rate, on which audio signals are calculated, and a slower rate (obviously some integer factor of the audio rate), usually called the control rate, at which things like slow moving envelopes, MIDI inputs and suchlike are calculated. That's my understanding too. I'm not sure when in the lineage the control rate was introduced. Note that there is another wrinkle: some variants support sample-accurate event scheduling by slicing the audio period into multiple sub-blocks at event boundaries. I believe this was around from the early days. Then, considering (Pd) message dataflow: On 27/02/2012 2:20 AM, Andy Farnell wrote: The essential facts of this dataflow might be There is_always_ an audio signal but there are sometimes no control messages Control messages are computed on a block boundary Given this formulation, that the control message scheduler is only pumped on the block boundary, isn't this equivalent to having a control rate available? Presumably there is a way to get a bang (evaluation) every block. From a signal processing angle this still allows the same semantics as Music-N multirate? (but see below). Also note that at least in max, the scheduler doesn't always run block-synchronously with the audio thread. I think there are different scheduling modes. See Scheduler in Audio Interrupt (SAI) here for example: http://cycling74.com/2004/09/09/event-priority-in-max-scheduler-vs-queue/ This actually makes your point clearer -- if the scheduler is *not* in the audio interrupt then clearly it is asynchronous and is quite different from the Music-N multirate approach. The audio signal is hard real time, so failure of the control to complete before the next interrupt will result in a drop out. Assuming SAI, which is maybe the only option in Pd, but not in Max. Okay, given these two approaches we can see that setting kr = ar alternatively expressed as (ksamps = 1) in the former system seems to be the same as setting the blocksize to 1 in the latter. BUT: In Csound we will still get an interleved series [As_0, Ks_0, As_1, Ks_1, As_2, Ks_2 ... As_n, Ks_n] wheras in Miller's dataflow we have As, the audio stream running constantly, with the possibility for Ks to intervene_anywhere_ within the stream so long as they can complete before the next As is demanded [As_0, As_1, As_2, As_3 ...As_20, As_21, Ks_0, As_22 ...As_100, Ks_1, Ks_2, As_101] This description doesn't strike me as completely consistent with what you said above. Are you saying that scheduler dispatch is triggered by the audio block rate but doesn't happen synchronously with it (ie it is still in a separate thread?) I'm not sure I understand what you mean by Ks to intervene_anywhere_ within the stream -- presumably (in the model you described) they only intervene at block boundaries? If the scheduler could be invoked at any sample location (ie sample accurate callbacks) then things could get interesting. Obviously this requires one to think about difficult problems where control and signals are closely coupled in subtly different ways for each language. Right, so for example, you don't implicitly have a control sample rate for doing control rate filtering etc. Ross P.S. Your post was in response to Brad's comment about ~gen, which I think is more like implementing audio-rate code in a max object, than any of the above methods. -- 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
Hi Richard, On 27/02/2012 3:01 AM, Richard Dobson wrote: On 26/02/2012 11:33, Ross Bencina wrote: .. Perhaps I'm not being clear. My point is about being able to execute arbitrary code at an arbitrary time based on the value of some signal(s). The zero crossing thing was a simple example. In which case it is a trivial test. Way back when I first used Csound on the Atari ST, the documentation cited the single-sample mode for implementing audio feedback and recursion. Not as efficient as using dedicated opcodes, but far from impossible. Conditional tests at krate effectively become conditional tests per sample. If running at ksamps=1 is acceptable, then I agree. But in my view this is an inefficient hack. Some people are happy with that. A language is defined not simply by what it enables, but by what it ~supports~. Csound supports and is optimised for fast audio vector processing, but it can do scalar processing too if you really need it. And on modern machines it is not even all that slow. Some recently added processes such as the Sliding DFT are defined as single-sample processing. You could also think of algorithms that are not strictly signal based such as multi-rate counters etc etc. Without a full-blown programming language the compromises become unacceptable once you know how to program in a normal language, whether that be C, C++, Java, Haskel, Scheme or Lisp. All your points centre on the last - that Csound is not a full-blown programming language. This is only stating the obvious, and is not a Csound flaw. My basic contention is that it is an insurmountable shortcoming and obstacle to future human creative progress for any environment that employs this restrictive DSL-like paradigm for creative expression in the domain of computer music (as previously described). This is what I mean by flaw. This is not stating the obvious, it is a position on the design of software tools for computer music, as previously defined. [and yes, AudioMulch fails the test far more than CSound]. ~Of course~ it isn't, never was and has never claimed to be - it is a scripted interpreter specialised for audio processing. It is a domain-specific language, and as such is one among many - Matlab, SQL, HTML and so on. Right. Although Matlab, SQL and HTML are all very different in their relation to a domain so I'm not exactly sure what your point is here. The bulk of this argument is what are the boundaries of the domain of a DSL for musical audio processing. You would like to define that domain as what Csound does whereas I conjecture that it is essentially no smaller than the domain of generalised computation. Which, lest I be misinterpreted, does *not* require C++, templates or exceptions, but it *does* require efficient sample-by-sample computation, support for data structures, etc. In short, this is a completely straw-man argument, If you think that, you are missing my point. The point being that musical DSLs that do not provide full blown programming features present undesirable limitations to the current state of practice in computer music. This may be a marginal view, but it is not a straw man. Further, the fact that you cite the use of Python and Lua embedded in CSound suggests that there already exists support for this requirement. as you are comparing apples to oranges. Well yes, I am saying that apples are not a nutritional option. Indeed, the single biggest issue I have with some on the Csound list is precisely that they want to add more general-purpose procedural idioms to Csound, in a misguided attempt to turn into it an audio version of C++. No need to group my opinions with your Csound list buddies. I'm quite happy for CSound to continue in its limited scope. I just think that scope is too limited and I for one would prefer a tool that *efficiently* combines all levels (from sample computation to algorithmic composition). To some degree, ironically, Max with ~gen approaches this, although it is still a multi-language approach which to me has its problems (the problems being with where and how the boundaries get drawn at the interfaces between languages). Even the addition of opcodes to embed Python or Lua code within the orchestra was something I had great misgivings about (i.e. a whole opcode and even effectively a whole instrument can be written in Python or Lua), as to me it is the wrong way around - Csound is a low-level language most suited to being embedded within higher-level ones. Still, they work (as far as I know), and I suppose if I try them one day I might feel differently! So we can probably have the slightly surreal spectacle of a Python script running Csound which in turn runs a Python-defined opcode. .. Are you being a pedant on purpose or did you miss my point? It was just an example. Anything that needs to efficiently to execute signal aware logic triggered at arbitrary locations in the sample stream.
Re: [music-dsp] a little about myself
On 27/02/2012 21:00, Ross Bencina wrote: .. And as I have already said. Computer musicians, must be programmers *by definition*. Otherwise they are musicians, using computers. But there is no single universally agreed definition of Computer musician. It is very likely a super-category. You have your definition, but it is not the only one out there. In English we tend to aggregate nouns, so we say computer musician. What you really mean is computing musician. How about music informaticist? It may catch on. In the meantime, people working intensely with DAW such as Pro Tools or Cubase call themselves programmers. And there is of course, I hope you will agree, nothing wrong or inferior about being a musician who uses computers. And there are many many levels of computing. What equivalent two-word name would you give them? There are musicians who do not use a computer but who think and compose algorithmically. What do we call them? For nobody really exists until we can call them something. 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 28/02/2012 8:55 AM, Richard Dobson wrote: On 27/02/2012 21:00, Ross Bencina wrote: .. And as I have already said. Computer musicians, must be programmers *by definition*. Otherwise they are musicians, using computers. But there is no single universally agreed definition of Computer musician. As previously posted this is my definition, like it or lump it: 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 If you feel that my use of terminology is distracting from the central purpose of the discussion I would be quite happy to call them User X. They are, I belive, the primary audience for use-case Y that is DSL's for User X to create music. It is very likely a super-category. You have your definition, but it is not the only one out there. Sure, but we don't need to further argue semantics, I've specifically qualified my usage as relevant to this discussion about limitations of some exisiting tools / paradigms. In English we tend to aggregate nouns, so we say computer musician. What you really mean is computing musician. How about music informaticist? It may catch on. In the meantime, people working intensely with DAW such as Pro Tools or Cubase call themselves programmers. And there is of course, I hope you will agree, nothing wrong or inferior about being a musician who uses computers. Somewhere else in the thread I already explicitly said that I wouldn't dream of casting any aspersions or associate any relative merit or value to different approaches. However, just as their are better and worse violins for violinists, there are better and worse programming systems for User X. And there are many many levels of computing. What equivalent two-word name would you give them? There are musicians who do not use a computer but who think and compose algorithmically. What do we call them? For nobody really exists until we can call them something. I am afraid you have lost me here. I have tried to provide you with sufficient description to contextualise my argument. If you don't like my use of two letter words that is fine. I'm not attached to them, especially since it appears that all they have done is distracted you. On the other hand, I am attached to the underlying notions that I used the two letter word to denote (perhaps modulo my omission of mathematics to the mix). 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 27/02/2012 22:05, Michael Gogins wrote: .. The actual blocks of audio samples will probably still be there... but it would be nice if one didn't have to think about them. Come to think of it, what with a-rate and k-rate variables in Csound orchestra language, WE don't have to think about them -- much. Quite. We don't have to think about them at all, except for the times when we do! 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
and with the same k and a variables we can still think about each sample of the signal, if we need to. On 27 Feb 2012, at 22:42, Richard Dobson richarddob...@blueyonder.co.uk wrote: On 27/02/2012 22:05, Michael Gogins wrote: .. The actual blocks of audio samples will probably still be there... but it would be nice if one didn't have to think about them. Come to think of it, what with a-rate and k-rate variables in Csound orchestra language, WE don't have to think about them -- much. Quite. We don't have to think about them at all, except for the times when we do! 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 -- 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
This has become a somewhat interesting and relevant discussion, in that we are preparing to rewrite the internals of Csound to at least some extent. I have been using Csound since the late 1980s, I have contributed a number of features and opcodes to Csound, and I have influenced the current design of Csound. I have also made attempts to learn and use other programmable synthesizers, starting with analog electronic modular synthesizers, and cmix (now RTcmix), Pure Data, and Reaktor. I have also created working prototypes of software synthesizers of my own design. I do algorithmic composition almost exclusively. I have designed a few Csound instruments from scratch, but more often adapt other peoples'. What I'm looking for is simple. I want sit down, write code quickly, hear it right away, figure out how to make it better fast, and do this over and over as quickly as possible. And I need to be able to express any musical or acoustical concept or image in code. General purpose languages are better than domain specific languages for this. The reason I use Csound after all these years is then, obviously, not because I haven't learned other systems or approaches, it is because it facilities the workflow I have described best of all. Your mileage, style, and taste may vary. I would really prefer to do everything in one, widely used, efficient, standard language such as C++. I would use Java or Lisp or whatever if thought they would do the job. But the fact of the matter is that I have been able to get more done with Csound, facilitated by other languages such as Python or Lua for which I have created the wrappers. And I am now trying to see how the workflow goes if I do my composing in straight C++ with Csound embedded as an engine. To a considerable extent this musical productivity I am able to express with Csound is due to its having been around a long time and having grown with a community of composers, musicians, and programmers who have created something like a tradition within which I find it easier to make music. As with the adapted Csound instruments, definitely. Certainly a major reason why I have not proposed my own design for a software synthesizer is I recognize the titanic amount of work required to get the functionality, the opcode set, and so on up to the level of Csound or any other widely used programmable synthesizer. But it is also because, for all its flaws, the Csound orchestra language concisely and relatively clearly expresses what is going on in the sound synthesis. What I would dearly love to hear in this discussion is how Csound can be improved to facilitate the creation of music, from people who do use software to compose and create their music. Or how some other software might be better, for that matter. On Mon, Feb 27, 2012 at 6:27 PM, Victor victor.lazzar...@nuim.ie wrote: yes, I guess this is a side effect of backwards compatibility, which has been the only absolute in development of Csound (it still runs even Music11 compositions). However, it can be improved with better formatting of documentation. While it can be off-putting, it has been a clear decision by the community not to break with this principle. No matter how good a system is, in my view, it is not worth much without a user community. Victor On 27 Feb 2012, at 23:11, Risto Holopainen risto.holopai...@imv.uio.no wrote: I must say I'm happy to have learnt the rudiments of Csound in 1996 and not today. The problem is not so much its shortcomings (I partly agree with Ross on them) but its longcoming list of opcodes and ever-expanding list of new features. Searching the manual for the correct name for a one-pole filter and whatnot becomes a distraction. But I still find it excellent for throwing together a custom effect and sometimes for algorithmic composition. At least in cases when I'm too lazy or too ignorant to do it in C++. Csound is an evolving language, still after more than 25 years, and there are many features you might not be aware of. The recently-introduced new parser has opened up a bunch of new possibilities, including that of new languages to control the engine. We are in active discussion regarding the development of Csound 6, which will include more new features and possibilities. The community has been very active and engaged in telling us what they would like to see there. Victor Looking forward to the new version, nevertheless! Risto [ != computer musician by the strictest of standards] -- 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
Re: [music-dsp] a little about myself
On 27/02/2012 22:15, Ross Bencina wrote: .. 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 As noted elsewhere, that probably excludes almost everyone in the field. I would be tempted to say the top of the iceberg, except that it seems to be all tip and no iceberg. My own view is that there is no such thing as computer music. There is music composed one way or another using computers, but I suspect that is not the same. There is music composed algorithmically, but all using pencil, eraser, and paper. That is not the same thing either. We have a habit in the West of seeing the thing as defining the person. I prefer to approach it the other way around, I see what the person does, and ~if appropriate~ find a description for them. The simplest of all is to call them musicians; which is how I describe myself, because all the activities I engage in are related to music one way and another. It remains to be seen, of course, to what extent my sonifications amount to music - but they have at least been used by musicians to make music with, so that makes it OK. 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 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] 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
Re: [music-dsp] a little about myself
The only language I'm aware of that allows the design of direct sample-massaging code in the language itself is chuck. CLM? Or do I misunderstand something? When I put on my old and battered composer's hat, I'd say the GUI made me do it is not very persuasive. In linguistics, it's known as the Great Eskimo Vocabulary Hoax. I wrote the same basic kinds of music whether by hand (Daily Life), using SCORE (Sandcastle), using Pla + Samson box (many tunes), etc. By the way, if you're interested in closures and lambdas, Snd+CLM+s7 has a ton; or check out Rick Taube's work. -- 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 25, 2012, at 2:23 PM, Bill Schottstaedt wrote: The only language I'm aware of that allows the design of direct sample-massaging code in the language itself is chuck. CLM? Or do I misunderstand something? Aha -- my 'weasel-wording' was aware of. Of course CLM! My awareness ain't what it used to be. Sorry Bill! When I put on my old and battered composer's hat, I'd say the GUI made me do it is not very persuasive. In linguistics, it's known as the Great Eskimo Vocabulary Hoax. I wrote the same basic kinds of music whether by hand (Daily Life), using SCORE (Sandcastle), using Pla + Samson box (many tunes), etc. For me it's more the point of what kind of music is more 'enabled' by particular design decisions. The 5 words for snow notwithstanding, I bet that people using a software instrument with the pitch specification in Hz will generally do different musics than people who use one with a 12-tone ET specification. Yeah, I know you can get around these specifications, but still... 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
Hi Andy, On 25/02/2012 5:05 AM, Andy Farnell wrote: The problem with plug unit generators languages for me is that they privilege the process (network of unit generators) over the content Some really interesting thoughts here Ross. At what level of granularity does the trade-off of control, flexibility and efficiency reach its sweet spot? Part of my argument is that ther's a problem if your synthesis language is not turing complete. C/C++ and MP4-SAOL are two options here. I'm not sure Faust gives you that. In some ways the unit generator or patchable code-block model is to be considered a compromise between the overhead of calling functions on single samples and being able to process chunks. It comes bottom up, out of implementation needs rather than being a top down shorthand. On the other hand, because familiar structures like the filter, oscillator and so forth make sense as basic units of design the VM + Ugen model makes a lot of sense to practitioners coming from the studio. Agreed. As an aside: studio equipment (typically, not always) has this property that all couplings are impedence matched, or buffered. What something is plugged into doesn't affect what it does (to a first order approximation). This is not how acoustic systems nor electronic circuits work. So that's one problem with the abstraction. Indeed increasingly audio software is incorporating iterative solvers for this kind of thing, although we don't yet see computer music languages with full solving capabilities like QUCS or SPICE. Plenty of analogous structures in general computer science have similar rationales, like pipelines, SIMD, with the question being at what level of granularity can you lump a bunch of stuff together and process it all without sacrificing flexibility? Even apparently atomic instructions are, from the microprocessors point of view, collections of more atomic register operations that we never consider unless programming in machine code. Right. But unless you're programming in assembley language these constraints (and benefits) don't usually impact the outcome. The compiler provides a generalised model of computation and optimises to these low level structures. The problem in something like Music-N-with-control-rate derived languages is that the optimisation surfaces as a strict constraint in the structure of the high level language. Faust is one example that gets away from this. Although I'm pretty sure it is not usefully turing complete. MP4-SAOL is the best thing I've seen so far that allows control-rate semantics/optimisations but doesn't force them (you can write a single sample delay and the compiler will recognise it as such). Anything else is just plugging unit generators together, which is limiting in many situations (one reason I abandoned these kind of environments and started writing my algorithms in C++). As linguists and writers note (Wittgenstein, Orwell, Ayer, Chomsky etc) language defines the modes of thought and facilitates or limits what we can do more or less easily. I guess plenty of studies have been done of the expressibility of computer languages, since they are strictly formal and amenable to analysis. Though we tend to invoke Turing completeness and assume all roads lead to Rome, clearly some languages are much better for certain things than others. I don't think we have to resort to the Saphir-Whorph hypothesis here. (there was a great thread on that on the POTAC list last year btw.) I think you're right about turing completeness though: in my view, you need something that is expressively turing complete that can operate on individual samples within that language framework. C/C++ and MP4-SAOL give you this. CSound doesn't, at least not easily, perhaps if ksamps=1 you can get close, neither do any of the split synthesis graph/control language systems (SC3, LuaAV, pd, maxmsp). Grist for the mill in computing philosophy, but as musicians or sound designers it takes on a freshness. For example, the ease with which polyphony can be conceived in Supercollider and Chuck is amazing compared to Pure Data/Max, which makes it an awkward hack at the best of times. Csound is somewhere between. And of course, though Csound is clearly conceived as a _composers_ language where large scale structures are easy to build, abstraction is very obtuse. Well I would question whether CSound is a composers language. To me it's an audio rendering language. Whenever I used CSound in my composition workflow I would write Python scripts or C programs to generate scores, so the composition didn't happen in CSound per-se. I remember Gunter Geiger's thesis being a good comparative treatment of different computer music languages, but that was mainly from a computational rather than expressibility angle. Maybe there's a good doctoral project for someone lurking in this question. Ah didn't realise he ever finished, I should look it up.
Re: [music-dsp] a little about myself
On 25/02/2012 2:38 PM, Adam Puckett wrote: What is WaveRT? I don't see it in the tarball. WaveRT is a recent WDM-KS driver sub-model that was introduced in Windows Vista. It is the version of WDM-KS that people seem to get excited about as offering the lowest latency and efficiency. I can't remember the details but at its core I think it's similar to the ASIO driver model. In any case, in PortAudio it's part of the wdmks host API. 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
Yeah, no shit just hit the fan... When you least expect it... On Sun, Feb 26, 2012 at 2:26 AM, robert bristow-johnson r...@audioimagination.com wrote: On 2/20/12 10:28 AM, douglas repetto wrote: Hi Adam, Welcome to the list. It's slow right now, but no doubt it'll flare up again soon! no shit -- 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 6:23 AM, Bill Schottstaedt wrote: In linguistics, it's known as the Great Eskimo Vocabulary Hoax. It's also known as the Sapir-Whorph Hypothesis. There are strong and weak versions of the hypothesis. The whole thing isn't necessarily completely a hoax. http://en.wikipedia.org/wiki/Linguistic_relativity (see Present status section). Here's a short excerpt from a discussion on the POTAC list last year. I really liked Dan Stowell's introduction of the idea of long-term bias effects [1]: Ross Bencina wrote: In any case I am not reverting to strong-SW here.. just suggesting that the notation system biases what we think of as music. It doesn't mean we can't think of other things as music, or even work out ways of notating them with CMN or programming languages. In reply, Dan S wrote: Nicely put. I agree with all this. You don't need strong-SW, since mild biasing factors can have strong effects over an extended period of time (that's one of the mainstays of evolution by natural selection, of course, but in other types of system too). I've always thought that western music notation colours a lot of people's musical expression in ways I don't like. Perhaps because I'm into timbral gestures; or perhaps I'd think that anyway, whatever was the dominant representation. I wrote the same basic kinds of music whether by hand (Daily Life), using SCORE (Sandcastle), using Pla + Samson box (many tunes), etc. I'm not sure whether you want to unpack that, but a couple of obvious issues are that (1) I would think it's difficult for a composer to judge the effects of the tools they use on their compositional output, (2) you wrote Pla so it is really part of the composition, (3) just because you wrote the same basic kind of music independent of tool used I'm not sure that says much about the broad impact of tool structure on practice. On the other hand, I'd agree that most of what actually consitutes music is not directly captured by the tools. By which I mean, what musical expression really is is mostly outside the domain of the directly encoded in programs, languages, algorithms, much in the same way as most human communication is non-verbal (and hence not encoded in words). Ross. [1] http://lists.lurk.org/pipermail/potac/2011-July/000107.html -- 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
Hi Brad, On 24/02/2012 3:01 PM, Brad Garton wrote: Joining this conversation a little late, but what the heck... Me too... On Feb 22, 2012, at 9:18 AM, Michael Gogins wrote: I got my start in computer music in 1986 or 1987 at the woof group at Columbia University using cmix on a Sun workstation. Michael was a stalwart back in those wild Ancient Days! cmix has never had a runtime synthesis language; even now instrument code has to be written in C++. One possible misconception -- by runtime synthesis language I'm sure Michael means a design language for instantiating synthesis/DSP algorithms *in real time* as the language/synth-engine is running. I tend to think of languages like ChucK or Supercollider more in that sense than Csound, and even SC differentiates between the language and then sending the synth-code to the server. My reading would be that Michael may be implying that there is a difference between interpretation and compilation. CSound does not have a runtime synthesis language either. It's a compiler with a VM. There is no way to re-write the code while it's running. SC3 is very limited in this regard too (you can restructure the synth graph but there's no way to edit a synthdef except by replacing it, and there's no language code running sample synchronously in the server). So you have a kind of runtime compilation model. I didn't get much of a chance to play with SC1 but my understanding is that you could actually process samples in the synthesis loop (like you can with cmix). To me this is real runtime synthesis. You get this in C/C++ too -- your program can make signal dependent runtime decisions about what synthesis code to execute. Anything else is just plugging unit generators together, which is limiting in many situations (one reason I abandoned these kind of environments and started writing my algorithms in C++). RTcmix (http;//rtcmix.org) works quite well in real time, in fact it has now for almost two decades. The trade-off in writing C/C++ code is that it is one of the most efficient languages currently in use. We've also taken a route which allows it to be 'imbedded' in other environments. rtcmix~ was the first of the 'language objects' I did for max/msp. iRTcmix (RTcmix in iOS) even passes muster at the clamped App Store, check out iLooch for fun: http://music.columbia.edu/~brad/ilooch/ (almost 2 years old now). For me the deeper issue is how these various languages/environments shape creative thinking. I tend to like the way I think about music, especially algorthmic composityon, using the RTcmix parse language than I do in, say SC. Each system has things 'it likes to do', and i think it important to be aware of these. Indeed. The problem with plug unit generators languages for me is that they privilege the process (network of unit generators) over the content (the signal). Programming in C++ makes the signal efficiently accessible. Nothing wrong with patchable environments of course :) just that their not the whole story. 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
My biggest concern with audio programming languages is the audio callback. I wonder if there is a way on Windows with the classic mmsystem.h and winmm to get low latency? Maybe call the function more times? I'm not sure how they really work though, I'd just like a way to render audio in realtime without dropped calls, if you will. It seems eSpeak does a pretty good job of this (NVDA's speech synthesizer). I'll have a look at Csound's winmm realtime code to try to understand how it works. On 2/24/12, Charles Turner vze26...@optonline.net wrote: On Feb 24, 2012, at 3:25 AM, Ross Bencina wrote: To me this is real runtime synthesis. You get this in C/C++ too -- your program can make signal dependent runtime decisions about what synthesis code to execute. Anything else is just plugging unit generators together, which is limiting in many situations (one reason I abandoned these kind of environments and started writing my algorithms in C++). Hi Ross- Has it escaped me that Audio Mulch supports this kind of interpretation? Best wishes, Charles -- 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
Ross is correct. I know that RTcmix supports real-time audio - I was using it that way just last week. What I meant is that before you run a new synthesis routine in RTcmix, you have to compile its C++ source code. I was trying to get LuaJIT to do this (run DSP code immediately). I created the infrastructure for this and it works. Unfortunately, it only works reliably for simple test cases. Complex code causes LuaJIT to crash. Not sure why. This kind of thing works much better in Csound. That's one reason I'm taking a closer look at working directly in C++. That, in turn, makes RTcmix itself more attractive in some ways. Best, Mike On Fri, Feb 24, 2012 at 3:25 AM, Ross Bencina rossb-li...@audiomulch.com wrote: Hi Brad, On 24/02/2012 3:01 PM, Brad Garton wrote: Joining this conversation a little late, but what the heck... Me too... On Feb 22, 2012, at 9:18 AM, Michael Gogins wrote: I got my start in computer music in 1986 or 1987 at the woof group at Columbia University using cmix on a Sun workstation. Michael was a stalwart back in those wild Ancient Days! cmix has never had a runtime synthesis language; even now instrument code has to be written in C++. One possible misconception -- by runtime synthesis language I'm sure Michael means a design language for instantiating synthesis/DSP algorithms *in real time* as the language/synth-engine is running. I tend to think of languages like ChucK or Supercollider more in that sense than Csound, and even SC differentiates between the language and then sending the synth-code to the server. My reading would be that Michael may be implying that there is a difference between interpretation and compilation. CSound does not have a runtime synthesis language either. It's a compiler with a VM. There is no way to re-write the code while it's running. SC3 is very limited in this regard too (you can restructure the synth graph but there's no way to edit a synthdef except by replacing it, and there's no language code running sample synchronously in the server). So you have a kind of runtime compilation model. I didn't get much of a chance to play with SC1 but my understanding is that you could actually process samples in the synthesis loop (like you can with cmix). To me this is real runtime synthesis. You get this in C/C++ too -- your program can make signal dependent runtime decisions about what synthesis code to execute. Anything else is just plugging unit generators together, which is limiting in many situations (one reason I abandoned these kind of environments and started writing my algorithms in C++). RTcmix (http;//rtcmix.org) works quite well in real time, in fact it has now for almost two decades. The trade-off in writing C/C++ code is that it is one of the most efficient languages currently in use. We've also taken a route which allows it to be 'imbedded' in other environments. rtcmix~ was the first of the 'language objects' I did for max/msp. iRTcmix (RTcmix in iOS) even passes muster at the clamped App Store, check out iLooch for fun: http://music.columbia.edu/~brad/ilooch/ (almost 2 years old now). For me the deeper issue is how these various languages/environments shape creative thinking. I tend to like the way I think about music, especially algorthmic composityon, using the RTcmix parse language than I do in, say SC. Each system has things 'it likes to do', and i think it important to be aware of these. Indeed. The problem with plug unit generators languages for me is that they privilege the process (network of unit generators) over the content (the signal). Programming in C++ makes the signal efficiently accessible. Nothing wrong with patchable environments of course :) just that their not the whole story. 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 -- Michael Gogins Irreducible Productions http://www.michael-gogins.com Michael dot Gogins at gmail dot com -- 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 Friday 24 February 2012, at 19.05.47, Andy Farnell padawa...@obiwannabe.co.uk wrote: The problem with plug unit generators languages for me is that they privilege the process (network of unit generators) over the content Some really interesting thoughts here Ross. At what level of granularity does the trade-off of control, flexibility and efficiency reach its sweet spot? For ChipSound, I decided on subsample accuracy - which basically means you can script your own waveforms, hardsync effects, AM, FM etc without explicit support from the engine. Of course, this is an extreme case, as ChipSound started out as an attempt at doing something seriously useful in less than 2k lines of code - but the point is, I don't think there is any way around subsample accurate control if you want to do anything much interesting without relying on a massive set of unit generators. Even single sample accuracy is totally insufficient if you want to do chromatic granular, hardsync and similar. tired, headache induced tech rant There is indeed a bit of complexity involved (timestamped events mixed with VM execution + buffer splitting), but the advantage is that one can pretty much eliminate LFOs, envelope generators, granular-ish synthesis methods and all that - and still have the functionality right there! Just script whatever you need when you need it. Of course, high density granular synthesis, FM etc is never going to run as fast this way as with dedicated, optimized unity generators, but then again, there is LLVM, if one really wants to push it... :-) Or just throw in a peephole optimizer + multi-instructions for starters; 50-100% speedup right there. (Expensive instruction dispatching; the plague of non-JIT VMs, making it extremely worthwhile to keep the instruction count down...) However, I'm doing sort of ok already, with some 1k voices running average VM code on a single core of a 2.4 GHz Core 2 CPU. (90% of my target customers have at least dual core CPUs, and the game already runs ok with sfx + music on a single core P4, despite lots of physics and graphics optimization left to do.) I haven't even bothered with the render-to-waveform feature yet; that could cut voice count to a fraction and/or improve quality drastically. It just feels like... cheating! All pure realtime synthesis using only basic geometric waveforms! sounds much cooler. Not that 95% of gamers would have any idea what that means anyway. :-D /tech rant -- //David Olofson - Consultant, Developer, Artist, Open Source Advocate .--- Games, examples, libraries, scripting, sound, music, graphics ---. | http://consulting.olofson.net http://olofsonarcade.com | '-' -- 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
Hi Charles, On 24/02/2012 10:45 PM, Charles Turner wrote: Anything else is just plugging unit generators together, which is limiting in many situations Has it escaped me that Audio Mulch supports this kind of interpretation? Hi Charles, I'm not exactly sure what you think has escaped you. But I wasn't really bringing AudioMulch into this :) AudioMulch is a high level environment for patching pre-built modules together. The modules are high level (at the level of musical effects, drum machines etc) and patching at this level makes sense (to me at least). It's a kind of component assembly model and isn't really related to programming per-se. There are a couple of levels of abstraction below this (which aren't directly available to the user of AudioMulch unless they start writing plugins): 1. The plugging unit generators together which you get with Reaktor, Csound, Pd, etc. 2. The sample-manipulation level that you get with C/C++/Assembley language. My point above being that level level (2) is distinct from level (1), and in my view, too much emphasis is placed on level (1). Cmix is one of the few systems I've used that provides access to level (1) and (2) in a relatively seamless way. 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 25/02/2012 4:50 AM, Adam Puckett wrote: Is there a minimal example of a complete working program that renders a sine wave in realtime using Kernel Streaming that will compile with just a bare MinGW install? (I have the latest GCC 4.5 on Windows XP Service Pack 3). Which DirectX SDK do I need, the one from Microsoft, or the one fromhttp://libsdl.org/extras/win32? On WDM-KS note that portaudio (portaudio.com) recently merged WDK-KS with WaveRT to trunk. It might be an easier option than doing it from scratch with Microsoft SDKs. Not sure whether it builds with MinGW though. 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
What is WaveRT? I don't see it in the tarball. On 2/24/12, Ross Bencina rossb-li...@audiomulch.com wrote: On 25/02/2012 4:50 AM, Adam Puckett wrote: Is there a minimal example of a complete working program that renders a sine wave in realtime using Kernel Streaming that will compile with just a bare MinGW install? (I have the latest GCC 4.5 on Windows XP Service Pack 3). Which DirectX SDK do I need, the one from Microsoft, or the one fromhttp://libsdl.org/extras/win32? On WDM-KS note that portaudio (portaudio.com) recently merged WDK-KS with WaveRT to trunk. It might be an easier option than doing it from scratch with Microsoft SDKs. Not sure whether it builds with MinGW though. 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 -- 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
Joining in late I have been using real-time Csound since 1996. I also write much of my music in C to create scores to drive Csound, and the rest directly in Csound. While I do not really do real-time I know that many of our users do, and as for installation, there are Debian and SuSE packages, OSX and Windows installers, etc. No harder than installing much stuff (I failed to install audacity yesterday on a Linux machine). ==John ffitch -- 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 Thursday 23 February 2012, at 14.03.54, Emanuel Landeholm emanuel.landeh...@gmail.com wrote: There is a another approach you could take when summing many voices that may be correlated in time and frequency, Indiividually pass your voices through a simple 2:nd order all pass with semi random phase angle before down mixing. This will reduce the risk of peaks lining up and might save you some headroom. Ofcourse, this means one extra IIR per voice, so it comes with a cost. In this case, I tend to use multiple voices specifically *because* I want them slightly offset in phase and/or frequency, so that's already in there, so to speak. For example, the strings are made from a few sawtooth waves starting at random phases, then having pitch and amplitude randomly modulated. The random modulation is absolutely essential for avoiding that harsh, metallic sound, but I suspect that it also has the side effect of reducing the probability of extreme peaks, compared to just randomizing initial phase and detune. If you want to be really clever, I suppose you could augment the randomization with logic that tracks all voices and tweaks the random values as needed to avoid peaks piling up... Interesting exercise if you really want to push the limits. :-) Anyway, I think the only safe and proper solution for the general case is a multiband compressor as the final stage before hard clip and output conversion. For an FPS game, this is where you insert a limiter that triggers a crossfade over to a ringing ears sound. ;-) That solves the clipping problem while also adding quite effective Whoa, too close to home! feedback. If you just want to psychoacoustically emphasize really loud noises, a compressor/limiter with suitable settings might work - unlike a transparent multiband compressor setup, which tends to have the opposite effect. -- //David Olofson - Consultant, Developer, Artist, Open Source Advocate .--- Games, examples, libraries, scripting, sound, music, graphics ---. | http://consulting.olofson.net http://olofsonarcade.com | '-' -- 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
For example, the strings are made from a few sawtooth waves starting at random phases, then having pitch and amplitude randomly modulated. The random modulation is absolutely essential for avoiding that harsh, metallic sound, but I suspect that it also has the side effect of reducing the probability of extreme peaks, compared to just randomizing initial phase and detune. Makes sense. No need to do an all pass stage on chorused, detuned or heavily modulated voices. Anyway, I think the only safe and proper solution for the general case is a multiband compressor as the final stage before hard clip and output conversion. Agreed. cheers, Emanuel -- 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 Thursday 23 February 2012, at 16.17.38, Adam Puckett adotsdothmu...@gmail.com wrote: Interesting. How would you make an ear ringing sound? That's a good question...! :-D I was just thinking of Half-Life 2, which has this feature. They're playing the same pre-generated waveform, AFAICT. It does the job, and it's quite obivous what it's intended to be, but perhaps not very realistic. A more realistic approach might be to FFT the offending audio snippet that triggers the effect, remove all bands but the too loud peaks and then IFFT that to create the ring waveform. -- //David Olofson - Consultant, Developer, Artist, Open Source Advocate .--- Games, examples, libraries, scripting, sound, music, graphics ---. | http://consulting.olofson.net http://olofsonarcade.com | '-' -- 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
Ringing in your ears due to exposure to loud noise is the stereocilia (small hair cells) being damaged and falsely reporting to your brain that there is still sound vibration present. The frequency of the ringing is not a function of the sound that damaged your ears (a super loud bassy sound doesn't cause a bassy ringing in your ears). Tom -Original Message- From: music-dsp-boun...@music.columbia.edu [mailto:music-dsp-boun...@music.columbia.edu] On Behalf Of David Olofson Sent: 23 February 2012 16:15 To: music-dsp@music.columbia.edu Subject: Re: [music-dsp] a little about myself On Thursday 23 February 2012, at 17.10.52, David Olofson da...@olofson.net wrote: On Thursday 23 February 2012, at 16.17.38, Adam Puckett adotsdothmu...@gmail.com wrote: Interesting. How would you make an ear ringing sound? [...] A more realistic approach might be to FFT the offending audio snippet that triggers the effect, remove all bands but the too loud peaks and then IFFT that to create the ring waveform. Oh, wait. Probably throw in some heavy distortion before the FFT, approximating the mechanical distortion in the ear...? Also, the whole thing needs to take in account that the too loud level is highly frequency dependent. Nothing is ever nearly as simple as it may seem at first. ;-) -- //David Olofson - Consultant, Developer, Artist, Open Source Advocate .--- Games, examples, libraries, scripting, sound, music, graphics ---. | http://consulting.olofson.net http://olofsonarcade.com | '-' -- 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
Thomas Young thomas.young at rebellion.co.uk wrote at Thu Feb 23 11:39:36 EST 2012 .. The frequency of the ringing is not a function of the sound that damaged your ears (a super loud bassy sound doesn't cause a bassy ringing in your ears) .. There's real danger in mid-sized powerful speakers producing ringing tones in a very reverberant space, because the sound levels from a directed, say 70 Watt 8 inch speakers going round and getting tuned to amplify themselves can be exceedingly high, and as it appears also in the for the hearing sensitive mid-range. So to my knowledge *all* materials of official form (records, taps, vhses, cds dvds blurays, even tv, etc) must be checked to have those types of waves a) checked out to remain only moderately amplified by all common room slapback echos and reverberating rings b) in the builtup of songs and the use of the midrange, there should be a clear indication of how much mid-range is present, without sudden _averaged peaks_. The averaging and the expansion envelope patterns possible with the averaged midrange are in my experience even to be found, emphasized and removed from all top audio materials, and make people put on an intro of Metallica on their powefull stereos not too loud, and make it not possible to get ringing ears from playing Abba's Ring Ring voices at really loud stereo or media-centre amps in a concrete living room, because all the waves which would lead to the obvious repeating reverberation sound-buildup have been sufficiently removed/altered. I recall from being an early teenager that even a (for the time) big 500W disco system in a medium sized and heavy echoing school hall could be used, without causing more than the hearing adjusting itself to lower internal volume, and of course after the show was over in half an hour or so back to normal, and I'm sure after repeating the experience more than few times I still could easily hear leaves moving and 18 kHz test tones ;) ! And thus system was so loud one would have to shout at on another at 30 cm or less be be intelligible, I seriously doubt most home systems and most hobby studio systems ever get so loud. Probably it's more a certain transient or resonance/shear wave causing the unnatural ringing effect, and of course I'd like to stay way clear of that... Theo Verelst -- 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
I worked with an audiologist once to make a system for people suffering from tinnitus. The idea was patients would turn knobs until a synthesized sound matched what they heard in their heads. This would then be used to configure a special hearing aid to generate a masking tone. The typical result was a sine wave in the two to five kilohertz range, mixed with some white noise passed through a narrow bandpass filter at about the same frequency. And/or, a second sinewave tuned a few hundred hertz away from the first, to make a rough dissonance. Um, this was in the mid 1970's. I was in high school, my neighbor had one of the first Putney's (EMS VC3 analog synth) in the US. My best friend's dad was a doctor, and didn't like the music I liked, and put me up to this experiment. I guess it all worked out: my friend and I stopped standing in the very front row at rock concerts, and more importantly, my neighbor ended up giving me the VCS3, that I still have :). I assume and hope tinnitus treatments have come a long way since then. According to some current friends who have ringing in the ears, the synth patch we came up with is still pretty good... Alex On Feb 23, 2012, at 8:39, Thomas Young thomas.yo...@rebellion.co.uk wrote: Ringing in your ears due to exposure to loud noise is the stereocilia (small hair cells) being damaged and falsely reporting to your brain that there is still sound vibration present. The frequency of the ringing is not a function of the sound that damaged your ears (a super loud bassy sound doesn't cause a bassy ringing in your ears). Tom -Original Message- From: music-dsp-boun...@music.columbia.edu [mailto:music-dsp-boun...@music.columbia.edu] On Behalf Of David Olofson Sent: 23 February 2012 16:15 To: music-dsp@music.columbia.edu Subject: Re: [music-dsp] a little about myself On Thursday 23 February 2012, at 17.10.52, David Olofson da...@olofson.net wrote: On Thursday 23 February 2012, at 16.17.38, Adam Puckett adotsdothmu...@gmail.com wrote: Interesting. How would you make an ear ringing sound? [...] A more realistic approach might be to FFT the offending audio snippet that triggers the effect, remove all bands but the too loud peaks and then IFFT that to create the ring waveform. Oh, wait. Probably throw in some heavy distortion before the FFT, approximating the mechanical distortion in the ear...? Also, the whole thing needs to take in account that the too loud level is highly frequency dependent. Nothing is ever nearly as simple as it may seem at first. ;-) -- //David Olofson - Consultant, Developer, Artist, Open Source Advocate .--- Games, examples, libraries, scripting, sound, music, graphics ---. | http://consulting.olofson.net http://olofsonarcade.com | '-' -- 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 23/02/2012 17:53, Alex Stahl wrote: Um, this was in the mid 1970's. I was in high school, my neighbor had one of the first Putney's (EMS VC3 analog synth) in the US. ... and more importantly, my neighbor ended up giving me the VCS3, that I still have:). I think you need to big up the smiley count there Alex! -- 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
Joining this conversation a little late, but what the heck... On Feb 22, 2012, at 9:18 AM, Michael Gogins wrote: I got my start in computer music in 1986 or 1987 at the woof group at Columbia University using cmix on a Sun workstation. Michael was a stalwart back in those wild Ancient Days! cmix has never had a runtime synthesis language; even now instrument code has to be written in C++. One possible misconception -- by runtime synthesis language I'm sure Michael means a design language for instantiating synthesis/DSP algorithms *in real time* as the language/synth-engine is running. I tend to think of languages like ChucK or Supercollider more in that sense than Csound, and even SC differentiates between the language and then sending the synth-code to the server. RTcmix (http;//rtcmix.org) works quite well in real time, in fact it has now for almost two decades. The trade-off in writing C/C++ code is that it is one of the most efficient languages currently in use. We've also taken a route which allows it to be 'imbedded' in other environments. rtcmix~ was the first of the 'language objects' I did for max/msp. iRTcmix (RTcmix in iOS) even passes muster at the clamped App Store, check out iLooch for fun: http://music.columbia.edu/~brad/ilooch/ (almost 2 years old now). For me the deeper issue is how these various languages/environments shape creative thinking. I tend to like the way I think about music, especially algorthmic composityon, using the RTcmix parse language than I do in, say SC. Each system has things 'it likes to do', and i think it important to be aware of these. 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
I've tried that before, basically writing a soft synth and a sequencer. I won't pretend I made anything that sounded very good but it was fun. In the demoscene there is a whole field of 'programmed music' which is just this, although generally they use a sequencer for the composition and just code the instruments. I have to say I've never really seen the appeal of CSound since it seems as complicated as just writing your own code in C/C++, maybe I am missing some great use case for it. -Original Message- From: music-dsp-boun...@music.columbia.edu [mailto:music-dsp-boun...@music.columbia.edu] On Behalf Of Adam Puckett Sent: 22 February 2012 13:45 To: A discussion list for music-related DSP Subject: Re: [music-dsp] a little about myself It's nice to see some familiar names in Csound's defense. Here's something I've considered since learning C: has anyone (attempted to) compose music in straight C (or C++) just using the audio APIs? I think that would be quite a challenge. I can see quite a bit more algorithmic potential there than probably any of the DSLs written in it. On 2/21/12, Michael Gogins michael.gog...@gmail.com wrote: It's very easy to use Csound to solve idle mind puzzles! I think many of us, certainly myself, find ourselves becoming distracted by the technical work involved in making computer music, as opposed to the superficially easier but in reality far more difficult work of composing. Regards, Mike On Tue, Feb 21, 2012 at 7:53 PM, Emanuel Landeholm emanuel.landeh...@gmail.com wrote: Well. I need to start using csound. To actually do things in the real world instead of just solving idle mind puzzles. On Tue, Feb 21, 2012 at 10:02 PM, Victor victor.lazzar...@nuim.ie wrote: i have been running csound in realtime since about 1998, which makes it what? about fourteen years, however i remember seeing code for RT audio in the version i picked up from cecelia.media.mit.edu back in 94. So, strictly this capability has been there for the best part of twenty years. -- 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 -- Michael Gogins Irreducible Productions http://www.michael-gogins.com Michael dot Gogins at gmail dot com -- 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
Speed of development is an issue, as turning ideas into sound uses considerable human cognition, echoic memory to listen, serial and linguistics faculties to interpret, and then geometric mathematical and procedural acrobatics to adapt the internal model. C gives great flexibility and control, but requires such intense working that an idea is often lost before it can be implemented. Compactness is thus a desirable quality for music making (with large structures) rather than sound programming. For seeing programmers, visual signal flows like Pure Data are powerful because the algorithm is maintained as a compact diagram. I can understand why Csound is attractive to someone without sight, and I wonder if you have also explored Supercollider, Chuck and Nyquist, which all represent quite different language interfaces to sound making. But as you are a programmer I also wonder, if for you Adam, Faust might be something important to explore. For one who interprets the world more in symbolic structures it's compactness might be something you find very useful. On Wed, Feb 22, 2012 at 08:44:56AM -0500, Adam Puckett wrote: It's nice to see some familiar names in Csound's defense. Here's something I've considered since learning C: has anyone (attempted to) compose music in straight C (or C++) just using the audio APIs? I think that would be quite a challenge. I can see quite a bit more algorithmic potential there than probably any of the DSLs written in it. On 2/21/12, Michael Gogins michael.gog...@gmail.com wrote: It's very easy to use Csound to solve idle mind puzzles! I think many of us, certainly myself, find ourselves becoming distracted by the technical work involved in making computer music, as opposed to the superficially easier but in reality far more difficult work of composing. Regards, Mike On Tue, Feb 21, 2012 at 7:53 PM, Emanuel Landeholm emanuel.landeh...@gmail.com wrote: Well. I need to start using csound. To actually do things in the real world instead of just solving idle mind puzzles. On Tue, Feb 21, 2012 at 10:02 PM, Victor victor.lazzar...@nuim.ie wrote: i have been running csound in realtime since about 1998, which makes it what? about fourteen years, however i remember seeing code for RT audio in the version i picked up from cecelia.media.mit.edu back in 94. So, strictly this capability has been there for the best part of twenty years. -- 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 -- Michael Gogins Irreducible Productions http://www.michael-gogins.com Michael dot Gogins at gmail dot com -- 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
I have done this several times and plan to do more. I got my start in computer music in 1986 or 1987 at the woof group at Columbia University using cmix on a Sun workstation. cmix has never had a runtime synthesis language; even now instrument code has to be written in C++. Score code can be written in a variety of languages including the built-in minc interpreter, Perl, Python, C, C++, and I have used Lua. The pieces I made used C++ for both synthesis and score generation. They were done using a Lindenmayer system to place complex, recursively generated patterns of phase-aligned grains into a soundfile. When I created the CsoundAC class library, which is written in C++, it was intended to be usable with C++ or with various wrapper languges such as Java, Python, Lisp, or Lua. Nobody maintained the C++ interface, but I am making it usable directly from C++ again. In this case, Csound is used for synthesis, but actually CsoundAC itself has some rudimentary facilities for synthesis including a soundfile class and some granular synthesis classes. Right now, I am finishing some fixes that need to be done so that I can compose in C++ using Qt as a toolkit for widgets that I will use to tweak mastering (final EQ, reverb, and compression) as well as sensitive instrument parameters (e.g. for STKBowed). In this case also, Csound is used for synthesis but the orchestra code is completely embedded in the C++ program. I will probably also embed plugin opcodes written in C++ in the program and register them with Csound just before compiling the orchestra. These plugins will not actually be external DLLs, they will be routines in the main composition program which will register them with Csound. Ideally, I would like to write entire instrument definitions in C++ embedded in the program. Then Csound would serve as an engine and a framework that would manage scheduling, voice allocation, and all input and output. These are the hard parts of music programming. I would manage all the score generation and sound synthesis in C++. I am writing an article about composing in C++ with the Csound API and CsoundAC, and I will try to get it published in the Csound Journal or elsewhere. All these techniques work with command-line programs as well as with GUIs. Regards, Mike On Wed, Feb 22, 2012 at 8:44 AM, Adam Puckett adotsdothmu...@gmail.com wrote: It's nice to see some familiar names in Csound's defense. Here's something I've considered since learning C: has anyone (attempted to) compose music in straight C (or C++) just using the audio APIs? I think that would be quite a challenge. I can see quite a bit more algorithmic potential there than probably any of the DSLs written in it. On 2/21/12, Michael Gogins michael.gog...@gmail.com wrote: It's very easy to use Csound to solve idle mind puzzles! I think many of us, certainly myself, find ourselves becoming distracted by the technical work involved in making computer music, as opposed to the superficially easier but in reality far more difficult work of composing. Regards, Mike On Tue, Feb 21, 2012 at 7:53 PM, Emanuel Landeholm emanuel.landeh...@gmail.com wrote: Well. I need to start using csound. To actually do things in the real world instead of just solving idle mind puzzles. On Tue, Feb 21, 2012 at 10:02 PM, Victor victor.lazzar...@nuim.ie wrote: i have been running csound in realtime since about 1998, which makes it what? about fourteen years, however i remember seeing code for RT audio in the version i picked up from cecelia.media.mit.edu back in 94. So, strictly this capability has been there for the best part of twenty years. -- 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 -- Michael Gogins Irreducible Productions http://www.michael-gogins.com Michael dot Gogins at gmail dot com -- 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 -- Michael Gogins Irreducible Productions http://www.michael-gogins.com Michael dot Gogins at gmail dot com -- 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 Wed, Feb 22, 2012 at 09:18:11AM -0500, Michael Gogins wrote: I am writing an article about composing in C++ with the Csound API and CsoundAC, and I will try to get it published in the Csound Journal or elsewhere. Definitely looking forward to that Michael. -- 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
+1 Am 22.02.2012 um 15:16 schrieb Andy Farnell: Speed of development is an issue, as turning ideas into sound uses considerable human cognition, echoic memory to listen, serial and linguistics faculties to interpret, and then geometric mathematical and procedural acrobatics to adapt the internal model. C gives great flexibility and control, but requires such intense working that an idea is often lost before it can be implemented. Compactness is thus a desirable quality for music making (with large structures) rather than sound programming. For seeing programmers, visual signal flows like Pure Data are powerful because the algorithm is maintained as a compact diagram. I can understand why Csound is attractive to someone without sight, and I wonder if you have also explored Supercollider, Chuck and Nyquist, which all represent quite different language interfaces to sound making. But as you are a programmer I also wonder, if for you Adam, Faust might be something important to explore. For one who interprets the world more in symbolic structures it's compactness might be something you find very useful. On Wed, Feb 22, 2012 at 08:44:56AM -0500, Adam Puckett wrote: It's nice to see some familiar names in Csound's defense. Here's something I've considered since learning C: has anyone (attempted to) compose music in straight C (or C++) just using the audio APIs? I think that would be quite a challenge. I can see quite a bit more algorithmic potential there than probably any of the DSLs written in it. On 2/21/12, Michael Gogins michael.gog...@gmail.com wrote: It's very easy to use Csound to solve idle mind puzzles! I think many of us, certainly myself, find ourselves becoming distracted by the technical work involved in making computer music, as opposed to the superficially easier but in reality far more difficult work of composing. Regards, Mike On Tue, Feb 21, 2012 at 7:53 PM, Emanuel Landeholm emanuel.landeh...@gmail.com wrote: Well. I need to start using csound. To actually do things in the real world instead of just solving idle mind puzzles. On Tue, Feb 21, 2012 at 10:02 PM, Victor victor.lazzar...@nuim.ie wrote: i have been running csound in realtime since about 1998, which makes it what? about fourteen years, however i remember seeing code for RT audio in the version i picked up from cecelia.media.mit.edu back in 94. So, strictly this capability has been there for the best part of twenty years. -- 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 -- Michael Gogins Irreducible Productions http://www.michael-gogins.com Michael dot Gogins at gmail dot com -- 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 -- 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
Yes, it's quite a challenge to compose music just using C/C++. Lately, I have tried to compose entire pieces written in C++. Many of them are just monolithic feedback systems with oscillators, filters and some low-level feature extractors. There are no hierarchic levels of control functions, the musical form emerges from the specific algorithm. In principle, similar programs should be possible to write in csound and other languages, but I have found it easier to use C++ for this. As others have pointed out, you easily forget your musical ideas while programming. The trick is: don't have any ideas to begin with! And speaking of short programs, this reminds me of the Obfuscated C contest and, not least, the new style of bytebeat (well, to me it seems like a revival of nonstandard / instruction synthesis): http://canonical.org/~kragen/bytebeat/ There is also a paper at arXiv by Heikkilä that explains it. Risto Holopainen Department of Musicology University of Oslo It's nice to see some familiar names in Csound's defense. Here's something I've considered since learning C: has anyone (attempted to) compose music in straight C (or C++) just using the audio APIs? I think that would be quite a challenge. I can see quite a bit more algorithmic potential there than probably any of the DSLs written in it. On 2/21/12, Michael Gogins michael.gog...@gmail.com wrote: It's very easy to use Csound to solve idle mind puzzles! I think many of us, certainly myself, find ourselves becoming distracted by the technical work involved in making computer music, as opposed to the superficially easier but in reality far more difficult work of composing. Regards, Mike -- 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
For me as a composer working almost exclusively with algorithmic composition and synthesis, the question of language is complex. It's not just the power of the language, but also the ease of writing code, plus the time for building, plus the time for maintaining any necessary build system and other parts of the toolchain, plus the number of steps involved in the compose/build/run/listen, compose/build/run/listen cycle, plus any postproduction or mastering steps... and the actual runtime speed of the code is often critical as some of the algorithmic composition procedures are quite compute-intensive. I've experimented with many languages, computer music languages, etc., and it's come down to using Csound plus as few other parts as possible. But runtime speed always turns out to more important than one might expect... That in turn means a choice between composing in LuaJIT or composing in C++, with qtcreator taking care of the build system and toolchain maintenance, and some additions to CsoundAC taking care of the post-processing stuff. I would prefer to compose using just one language, but at least this way I only have to deal with the Csound orchestra language plus one other language, either Lua or C++. I don't have enough experience yet to tell which way I will end up going, but right now it looks like each piece will be a C++ program written in qtcreator and run from qtcreator. Each piece will have as much as GUI as it needs for mastering and testing instrument parameters, and automatically do any necessary post-processing, Jack configuration, etc. This is what I will be writing about... Regards, Mike On Wed, Feb 22, 2012 at 11:17 AM, Risto Holopainen risto.holopai...@imv.uio.no wrote: Yes, it's quite a challenge to compose music just using C/C++. Lately, I have tried to compose entire pieces written in C++. Many of them are just monolithic feedback systems with oscillators, filters and some low-level feature extractors. There are no hierarchic levels of control functions, the musical form emerges from the specific algorithm. In principle, similar programs should be possible to write in csound and other languages, but I have found it easier to use C++ for this. As others have pointed out, you easily forget your musical ideas while programming. The trick is: don't have any ideas to begin with! And speaking of short programs, this reminds me of the Obfuscated C contest and, not least, the new style of bytebeat (well, to me it seems like a revival of nonstandard / instruction synthesis): http://canonical.org/~kragen/bytebeat/ There is also a paper at arXiv by Heikkilä that explains it. Risto Holopainen Department of Musicology University of Oslo It's nice to see some familiar names in Csound's defense. Here's something I've considered since learning C: has anyone (attempted to) compose music in straight C (or C++) just using the audio APIs? I think that would be quite a challenge. I can see quite a bit more algorithmic potential there than probably any of the DSLs written in it. On 2/21/12, Michael Gogins michael.gog...@gmail.com wrote: It's very easy to use Csound to solve idle mind puzzles! I think many of us, certainly myself, find ourselves becoming distracted by the technical work involved in making computer music, as opposed to the superficially easier but in reality far more difficult work of composing. Regards, Mike -- 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 -- Michael Gogins Irreducible Productions http://www.michael-gogins.com Michael dot Gogins at gmail dot com -- 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
More recently, I set out to hack a tiny, fast, usable sound engine for games, and ended up with ChipSound Nice idea. I'm using it in my WIP game Kobo II; all sounds still built from sine, saw, triangle, square waves and noise, no filters or anything. Going to do some (possibly recursive) render-sound-into-waveform stuff, add filters and other units etc later on, but this will do for now. http://olofsonarcade.com/2011/11/06/kobo-ii-another-song-wip/ http://olofsonarcade.com/2011/02/10/kobo-ii-title-song-wip/ Excellent noises! Please shout when the engine is available for experimentation. ATB Jerry -- 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
you mean like: in pure python, without external libs etc, synthesizing every single sample, in one file.py: http://paste.org/45689 OR PPEPPS: Pure Python EP: Project Solvent $ git clone git://labmacambira.git.sourceforge.net/gitroot/labmacambira/FIGGUS $ cd FIGGUS $ sudo python setup.py install # not dependent on anything else $ python RUNME_make_now_an_EP_MUSIC.py Go to ep-Projeto_Solvente/ and enjoy symmetry music for easing altered states of mind. more: IRC Channel #labmacambira @ irc.freenode.net http://wiki.nosdigitais.teia.org.br/FIGGUS ??? Em 22 de fevereiro de 2012 11:44, Adam Puckett adotsdothmu...@gmail.com escreveu: It's nice to see some familiar names in Csound's defense. Here's something I've considered since learning C: has anyone (attempted to) compose music in straight C (or C++) just using the audio APIs? I think that would be quite a challenge. I can see quite a bit more algorithmic potential there than probably any of the DSLs written in it. On 2/21/12, Michael Gogins michael.gog...@gmail.com wrote: It's very easy to use Csound to solve idle mind puzzles! I think many of us, certainly myself, find ourselves becoming distracted by the technical work involved in making computer music, as opposed to the superficially easier but in reality far more difficult work of composing. Regards, Mike On Tue, Feb 21, 2012 at 7:53 PM, Emanuel Landeholm emanuel.landeh...@gmail.com wrote: Well. I need to start using csound. To actually do things in the real world instead of just solving idle mind puzzles. On Tue, Feb 21, 2012 at 10:02 PM, Victor victor.lazzar...@nuim.ie wrote: i have been running csound in realtime since about 1998, which makes it what? about fourteen years, however i remember seeing code for RT audio in the version i picked up from cecelia.media.mit.edu back in 94. So, strictly this capability has been there for the best part of twenty years. -- 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 -- Michael Gogins Irreducible Productions http://www.michael-gogins.com Michael dot Gogins at gmail dot com -- 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 -- GNU/Linux User #479299 labmacambira.sf.net -- 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 Wednesday 22 February 2012, at 18.39.22, Jerry Evans je...@novadsp.com wrote: More recently, I set out to hack a tiny, fast, usable sound engine for games, and ended up with ChipSound Nice idea. I'm using it in my WIP game Kobo II; all sounds still built from sine, saw, triangle, square waves and noise, no filters or anything. Going to do some (possibly recursive) render-sound-into-waveform stuff, add filters and other units etc later on, but this will do for now. http://olofsonarcade.com/2011/11/06/kobo-ii-another-song-wip/ http://olofsonarcade.com/2011/02/10/kobo-ii-title-song-wip/ Excellent noises! Thanks! Please shout when the engine is available for experimentation. There is a version here, actually: http://eel.olofson.net/download/ChipSound-20111207.tar.bz2 It was released along with a little Ludum Dare jam entry I made using the Kobo II engine in the (rather messy) state it was in at the point. There is a small SDL + console test program included with ChipSound, but the debug sound test dialog in the game is probably more useful. It requires OpenGL though, as it's built using the in-game GUI toolkit. The game also includes a tiny MIDI sequencer, BTW...! :-D Might turn that into some kind of live ChipSound code editor with MIDI support later on. I've realized I rather like just using a text editor, and having all the sounds and everything right there. A bit like working with a tracker (Amiga style), but more free-form, or something. All I want is instant automatic recompiles, and being able to record a melody or a few chords from MIDI once in a while - other than that, I'm not really missing the world of Cubase clones much. :-) LD entry page: http://www.ludumdare.com/compo/ludum-dare-22/?action=previewuid=2901 Source downloads: http://eel.olofson.net/news.html I intend to keep the whole set of engines (EEL with API bindings, physics engine etc, ZeeSpace and ChipSound) Free/Open Source. Most of it is LGPL, but ChipSound doesn't actually have a license at this point. It'll be either LGPL or something like the zlib license. -- //David Olofson - Consultant, Developer, Artist, Open Source Advocate .--- Games, examples, libraries, scripting, sound, music, graphics ---. | http://consulting.olofson.net http://olofsonarcade.com | '-' -- 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
David, How did you mix all the sounds in the song? On 2/22/12, Jerry Evans je...@novadsp.com wrote: On 22/02/2012 19:33, David Olofson wrote: There is a version here, actually: http://eel.olofson.net/download/ChipSound-20111207.tar.bz2 It was released along with a little Ludum Dare jam entry I made using the Kobo II engine in the (rather messy) state it was in at the point. There is a small SDL + console test program included with ChipSound, but the debug sound test dialog in the game is probably more useful. It requires OpenGL though, as it's built using the in-game GUI toolkit. Excellent and thanks. As soon as I get the mythical 5 minutes ... -- 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
What was the algorithm though? It sounds pretty high-end to me. On 2/22/12, David Olofson da...@olofson.net wrote: On Wednesday 22 February 2012, at 21.06.59, Adam Puckett adotsdothmu...@gmail.com wrote: David, How did you mix all the sounds in the song? No mixer, fx chains or anything just yet, so all voices mix into a single output buffer. In fact, mixing is not even stereo yet - I'm just adding a simple stereo feedback delay before final output conversion. :-) For the mp3s, I used JAMin to add a bit of EQ and multiband compression, to bring loudness a bit closer to standard. -- //David Olofson - Consultant, Developer, Artist, Open Source Advocate .--- Games, examples, libraries, scripting, sound, music, graphics ---. | http://consulting.olofson.net http://olofsonarcade.com | '-' -- 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 Thursday 23 February 2012, at 03.16.10, Adam Puckett adotsdothmu...@gmail.com wrote: How are you not getting samples out of range with all those voices? Just the usual deal: Scale amplitudes down. :-) I generally compensate instruments so they all land at reasonable levels regardless of internal voice count, and from there it's just like working with any normal synth. Also, levels are not that much of a problem with large numbers of voices, as they don't add up in a linear fashion. For all practical matters, it becomes more like adding up white noise sources; something like sqrt(2) greater peak amplitude for doubling the number of sources. -- //David Olofson - Consultant, Developer, Artist, Open Source Advocate .--- Games, examples, libraries, scripting, sound, music, graphics ---. | http://consulting.olofson.net http://olofsonarcade.com | '-' -- 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
Yes, I have a Focus 40 Braille display. They are made by Freedom Scientific, who also makes a screen reading product called JAWS. I use a combination of speech and Braille to ensure speedy code reading so I can get an idea of the algorithms or messages. On 2/20/12, Jerry lancebo...@qwest.net wrote: On Feb 20, 2012, at 5:43 PM, Adam Puckett wrote: Jerry and Emanuel, I program using a text editor, Notepad++, a screen reader (NVDA), and I didn't know about this. Pretty cool. http://www.nvda-project.org/ The video there didn't seem to show or mention Braille. I gather there is some kind of Braille output device. Jerry -- 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
you're not related to Miller Puckett, are you? just curious. and you're still welcome to the group no matter the answer. -- 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
Re: [music-dsp] a little about myself
No, I'm not related to Miller Puckette. On 2/21/12, robert bristow-johnson r...@audioimagination.com wrote: you're not related to Miller Puckett, are you? just curious. and you're still welcome to the group no matter the answer. -- 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 -- 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
hey adam, yep, that also includes me .. have you ever read curtis roads - the computer music tutorial ? it was one of my main sources to get my degree in ee .. maybe there is a translation to braille or a digital version .. it is completely based on csound and i love it .. cheers, bastian Am 21.02.2012 um 16:43 schrieb Didier Dambrin: True, I've never been able to install or figure out CSound, or make it do anything. Watching on YT, I see it can do realtime stuff? I've always thought it was all command-line offline stuff (last time I tried in 2007). -Message d'origine- From: Emanuel Landeholm Sent: Tuesday, February 21, 2012 3:54 PM To: A discussion list for music-related DSP Subject: Re: [music-dsp] a little about myself But, if you don't mind me asking, what is it that you do music-dsp wise? Mostly csound stuff? It's just that the thought of a blind person using csound simply blows my mind. csound is powerful alright, but most people, blind or not, can't even hope to install it, much less use it for something.. kind regards, Emanuel -- 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 - Aucun virus trouve dans ce message. Analyse effectuee par AVG - www.avg.fr Version: 2012.0.1913 / Base de donnees virale: 2113/4822 - Date: 20/02/2012 -- 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 21/02/2012 15:43, Didier Dambrin wrote: True, I've never been able to install or figure out CSound, or make it do anything. Watching on YT, I see it can do realtime stuff? I've always thought it was all command-line offline stuff (last time I tried in 2007). It's been real-time for at least a decade, so was already real-time in 2007 (much has been added since then), comes with full installers for Windows, OS X and Linux, and has a large number of GUI front-ends available, many supporting custom controls. Many users are ~only~ using it in real-time contexts, whether via MIDI, OSC or Wiimotes, or whatever. The current version is 5.16, released this month: http://sourceforge.net/projects/csound/files/csound5/ 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
Well. I need to start using csound. To actually do things in the real world instead of just solving idle mind puzzles. On Tue, Feb 21, 2012 at 10:02 PM, Victor victor.lazzar...@nuim.ie wrote: i have been running csound in realtime since about 1998, which makes it what? about fourteen years, however i remember seeing code for RT audio in the version i picked up from cecelia.media.mit.edu back in 94. So, strictly this capability has been there for the best part of twenty years. -- 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
It's very easy to use Csound to solve idle mind puzzles! I think many of us, certainly myself, find ourselves becoming distracted by the technical work involved in making computer music, as opposed to the superficially easier but in reality far more difficult work of composing. Regards, Mike On Tue, Feb 21, 2012 at 7:53 PM, Emanuel Landeholm emanuel.landeh...@gmail.com wrote: Well. I need to start using csound. To actually do things in the real world instead of just solving idle mind puzzles. On Tue, Feb 21, 2012 at 10:02 PM, Victor victor.lazzar...@nuim.ie wrote: i have been running csound in realtime since about 1998, which makes it what? about fourteen years, however i remember seeing code for RT audio in the version i picked up from cecelia.media.mit.edu back in 94. So, strictly this capability has been there for the best part of twenty years. -- 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 -- Michael Gogins Irreducible Productions http://www.michael-gogins.com Michael dot Gogins at gmail dot com -- 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
Hi Adam, Welcome to the list. It's slow right now, but no doubt it'll flare up again soon! best, douglas On 2/18/12 9:55 PM, Adam Puckett wrote: Hey list, My name is Adam Puckett. I am a totally blind C programmer with an associates degree in IT and an interest in DSP. I use a program called Csound to create music, and I also play many instruments: guitar, piano (sometimes), drums, bass, accordion, and violin. (I played trumpet in high school, but I usually don't count that as I wasn't very good at it ;)). I enjoy all types of music, including rock, pop and classical, from country to jazz. -- 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 -- ... http://artbots.org .douglas.irving http://dorkbot.org .. http://music.columbia.edu/cmc/music-dsp ...repetto. http://music.columbia.edu/organism ... http://music.columbia.edu/~douglas -- 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
Hi Adam, Please forgive my ignorance, but being blind, how are you able to program? Jerry On Feb 18, 2012, at 7:55 PM, Adam Puckett wrote: Hey list, My name is Adam Puckett. I am a totally blind C programmer with an associates degree in IT and an interest in DSP. I use a program called Csound to create music, and I also play many instruments: guitar, piano (sometimes), drums, bass, accordion, and violin. (I played trumpet in high school, but I usually don't count that as I wasn't very good at it ;)). I enjoy all types of music, including rock, pop and classical, from country to jazz. -- 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
Adam, I am also curious as to how you interface with a development environment. Moreover, what are you working on? Also, wasn't there a blind contributor around a few years ago? Your name does not ring a bell for me, so I can only guess that you are number two (minimum)! Also, isn't this a golden opportunity for all of us to introduce themselves? Anyway, my name is Emanuel. I'm a computer programmer from Sweden who loves pre-post-doc math (because post-doc math is way over my tiny head). I am also a web developer, so the Linux/Apache/Mysql/PHP stack is what brings lunch to my table (you like fries with that?). I'm a very occasional contributor to the list. My post are infrequent, random and intuitive, and for the most part safe to ignore. I do however read every word posted to the list. music-dsp for me represents the intersection of my love for electronic music (Cabaret Voltaire, Kraftwerk, Aphex Twin..) and vector space formalisms. cheers, Emanuel On Mon, Feb 20, 2012 at 11:43 PM, Jerry lancebo...@qwest.net wrote: Hi Adam, Please forgive my ignorance, but being blind, how are you able to program? Jerry -- 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
Welcome Adam. On Feb 18, 2012, at 6:55 PM, Adam Puckett wrote: Hey list, My name is Adam Puckett. I am a totally blind C programmer with an associates degree in IT and an interest in DSP. I use a program called Csound to create music, and I also play many instruments: guitar, piano (sometimes), drums, bass, accordion, and violin. (I played trumpet in high school, but I usually don't count that as I wasn't very good at it ;)). I enjoy all types of music, including rock, pop and classical, from country to jazz. -- 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
