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 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 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] guitar physical model
Thanks! I always wanted to play the guitar, but I wasn't any good. LISP to the rescue! brad http://music.columbia.edu/~brad On Feb 26, 2012, at 9:50 AM, Andy Farnell wrote: Me too, Some great Steve Hillage like moments in that. On Sun, Feb 26, 2012 at 10:52:12AM +0100, Emanuel Landeholm wrote: http://music.columbia.edu/~brad/music/mp3/Rough_Raga_Riffs.mp3 This. I just listened to it and it put me in a good mood! -- dupswapdrop -- the music-dsp mailing list and website: subscription info, FAQ, source code archive, list archive, book reviews, dsp links http://music.columbia.edu/cmc/music-dsp http://music.columbia.edu/mailman/listinfo/music-dsp -- dupswapdrop -- the music-dsp mailing list and website: subscription info, FAQ, source code archive, list archive, book reviews, dsp links http://music.columbia.edu/cmc/music-dsp http://music.columbia.edu/mailman/listinfo/music-dsp -- dupswapdrop -- the music-dsp mailing list and website: subscription info, FAQ, source code archive, list archive, book reviews, dsp links http://music.columbia.edu/cmc/music-dsp http://music.columbia.edu/mailman/listinfo/music-dsp
Re: [music-dsp] a little about myself
On Feb 26, 2012, at 9:48 AM, Ross Bencina wrote: Then there is the whole schtick of composer as Auteur directing the technical minions to do the programming for him/her. Oh my *favorite* paradigm! Ya just gotta love the cultural model that puts forward, too. brad http://music.columbia.edu/~brad -- dupswapdrop -- the music-dsp mailing list and website: subscription info, FAQ, source code archive, list archive, book reviews, dsp links http://music.columbia.edu/cmc/music-dsp http://music.columbia.edu/mailman/listinfo/music-dsp
[music-dsp] test
sorry... posts not going through for some reason. 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
[music-dsp] list postings
Hey music-dsp-ers -- Has anyone else experienced troubles getting posts to show up on our list? I've sent (and re-sent) several this morning and they just vanished. I've checked with douglas about it, but was wondering if anyone else has had problems. 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] list postings
Ok, my default Apple mail was set to rich text format in my preferences (not HTML, which I know is a no-no). With that as default, somehow some postings go through but others don't (and no, I wasn't doing any fancy italics or nothin'). I switched my default to plain text and it seems to work now. brad http://music.columbia.edu/~brad Hi Charlie! :-) On Feb 25, 2012, at 1:48 PM, charles morrow wrote: Yes, Brad. I have been flummoxed by the gods of music-dsp for a week now On Feb 25, 2012, at 8:38 PM, Brad Garton wrote: Hey music-dsp-ers -- Has anyone else experienced troubles getting posts to show up on our list? I've sent (and re-sent) several this morning and they just vanished. I've checked with douglas about it, but was wondering if anyone else has had problems. 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 charlie morrow Charles Morrow Productions LLC New York Helsinki LA Barton VT www.cmorrow.com +1646 235 7228 -- 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] guitar physical model
Yikes, I'm just posting up a storm here today. Sorry! You might enjoy some older stuff I did back in 1989 -- 1991: http://music.columbia.edu/~brad/music/mp3/Rough_Raga_Riffs.mp3 http://music.columbia.edu/~brad/music/mp3/Almost_Real.mp3 notes: http://music.columbia.edu/~brad/music/commentary/Rough_Raga_Riffs.html http://music.columbia.edu/~brad/music/notes/Rough_Raga_Riffs.html http://music.columbia.edu/~brad/music/notes/Almost_Real.html http://music.columbia.edu/~brad/music/commentary/Almost_Real.html Both pieces were pretty much entirely algorithmically-generated, using the Charlie Sullivan variant of the Karplus-Strong plucked string model and a whole buncha lisp code. A lot of what you describe (fretting, hammer-ons, etc.) happen in my models at a level above the 'instrument' making the sound. Here's an early paper describing some of it: http://music.columbia.edu/~brad/writing/papes/performance_model.pdf (1992 ICMC) and a slightly later one I wrote with Matthew Suttor about style/performance modeling in general: http://music.columbia.edu/~brad/writing/papes/Sense_of_Style.pdf The lisp code I used is also on-line somewhere in my web pages. Or if you have max/msp, check out the help-patcher for my lisp interpreter object [maxlisp]: http://music.columbia.edu/~brad/maxlispj/ It does the 'electric guitar' performance model simulation in real-time (and all the code is there, too). c. 8' 30 in Rough Raga Riffs is when I taught it the halenize function (Eddie Van!). I like that part a lot... brad http://music.columbia.edu/~brad On Feb 25, 2012, at 8:19 PM, Adam Puckett wrote: I've seen code for string physical modeling, so I have a (somewhat) good idea of what all is involved in it. However, I haven't seen any code that accounts for frets, as are on a guitar or banjo. How would one go about implementing the fret sounds/gestures like slide, hammer-on/pull-off? Seems to me like there would be rounding somewhere in the code, as the finger never is supposed to actually touch the fret, or you will get a buzzing sound. Also how is the squeak of the sliding finger implemented? What is the relationship of the frets to one another, as they get shorter the further down the neck you go? -- 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 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] looking for a flexible synthesis system technically and legally appropriate for iOS development
Yes, in fact I've been doing it for years (the rtcmix~ object for max/msp). brad On Feb 8, 2011, at 12:08 AM, Morgan Packard wrote: Brad, It seems there are a number of ways to interpret whether an application which links to a GPL library must be open-sourced as well (based on wikipedia's expert legal advice). But it's great news to me that your interpretation is that RT CMix can be used in closed source applications. Should I consider myself to have the blessing of the controllers of RT Cmix make a billion dollars on the app store after which I will continually express my gratitude in various material and non-material ways? -Morgan On Mon, Feb 7, 2011 at 9:53 PM, Brad Garton gar...@columbia.edu wrote: Hmmm, my understanding of the GPL we adopted was that it only applied to the source of RTcmix, _not_ to the 'enclosing' app. The way we set up the iRTcmix apps, we have a 'manager' class (source provided) that calls into the RTcmix engine. Any mods you would make to the RTcmix source *proper* would need to be published, but the app you develop that uses it would not. I honestly thought I had put up the source for iLooch (it's in the next iRTcmix release), but it looks like the link on the web page is only to the iRTcmix source. Which is what would attach to your app, I *think*. brad On Feb 7, 2011, at 11:41 PM, Morgan Packard wrote: Thanks Brad, Just bought ilooch. Lovely stuff. Unless I'm mistaken though, I'm required to make my source code publicly available if I embed RT CMix because it's licensed under the GPL. I swear, I'm not an _entirely_ evil person, but for a few reasons, I don't think it's going to be possible to open-source my app. However, the fact that I'm running in to this GPL license again and again does make me think that maybe I should reconsider this and see if maybe I can talk myself (and my programming partner) in to it. Though, now that I look, I don't see the iLooch source code posted anywhere. Can you confirm that RT Cmix is an option only if I make the source code to my app publicly available? thanks, -Morgan On Mon, Feb 7, 2011 at 9:25 PM, Brad Garton gar...@columbia.edu wrote: No, it's usable. I have an app already in the App store: http://music.columbia.edu/~brad/ilooch/ We have a new release up in the next few days. brad On Feb 7, 2011, at 8:25 PM, douglas repetto wrote: Brad Garton has RTcmix running on the iPhone: http://music.columbia.edu/~brad/iRTcmix/ Dunno what the license is though... On 2/7/11 8:09 PM, Morgan Packard wrote: (First post to this list. Sent this a few days ago and it doesn't seem to have gone through, so trying again.) Hi There, I've been writing low-level code for my iOS app, Thicket, pretty much myself, with the exception of a sine oscillator and an envelope borrowed from STK. I'd like to be able to work on this platform in a much faster way than I have been, simply plugging unit generators in to one another, not having to stop and think about how to, for example, go from a mono oscillator signal to a stereo reverb signal. I'd like to be able to work more like I work in SuperCollider, writing higher-level code to create a signal path, trusting that the connections will be efficiently managed for me. In other words, I'd like to spend a little less time being a fairly incompetent engineer, and more time being a halfway-decent artist. I'm finding that my list of options is surprisingly small SuperCollider -- GPL licence, would require that I open-source my app ChucK -- GPL license, would require that I open-source my app CSound -- the FAQ indicates that I need to make arrangements with MIT to put it to commercial use. Worth looking in to, perhaps. JSyn -- java, not gonna work on iOS MusicKit -- looks very interesting, but doesn't seem to be a very active project, and I don't think anyone has gotten it running on iOS yet Pure Data -- seems like my best option. more permissive license, but I'm wary of the visual programming paradigm, and have at least one technical detail which is making me a bit uncomfortable Am I missing something? Is there anything -- free, or not, which I should look at for iOS development besides Pure Data? Are there not hundreds of other people with the same needs that I have? Are my options really limited to: Pure Data or rolling my own, or open-sourcing my app? I sincerely appreciate any info or thoughts any of you are able to share with me. thanks, -Morgan -- Web: http://www.morganpackard.com Music/Art: Latest album: Moment Again Elsewhere iOS app Thicket available on iTunes store. -- ... http://artbots.org .douglas.irving http://dorkbot.org .. http://music.columbia.edu/cmc/music-dsp
Re: [music-dsp] looking for a flexible synthesis system technically and legally appropriate for iOS development
This is how I did the sc3~ object for max/msp. RTcmix is set up to compile as a static or dynamic library, so it's a bit more tightly-coupled. brad http://music.columbia.edu/~brad On Feb 8, 2011, at 3:43 AM, Dan Stowell wrote: Morgan - I don't know RTCmix but the situation you describe is similar to that with SuperCollider: if you run SC's audio engine as a background process and call into the engine usually using OSC, your calling application is separate and doesn't need to be GPL'd. I don't know how convenient this architecture (audio engine as separate process) is on iOS, but it's certainly working on Android, in fact the Java-ish frontend on Android makes it a kinda convenient approach. Dan On 08/02/2011 05:08, Morgan Packard wrote: Brad, It seems there are a number of ways to interpret whether an application which links to a GPL library must be open-sourced as well (based on wikipedia's expert legal advice). But it's great news to me that your interpretation is that RT CMix can be used in closed source applications. Should I consider myself to have the blessing of the controllers of RT Cmix make a billion dollars on the app store after which I will continually express my gratitude in various material and non-material ways? -Morgan On Mon, Feb 7, 2011 at 9:53 PM, Brad Gartongar...@columbia.edu wrote: Hmmm, my understanding of the GPL we adopted was that it only applied to the source of RTcmix, _not_ to the 'enclosing' app. The way we set up the iRTcmix apps, we have a 'manager' class (source provided) that calls into the RTcmix engine. Any mods you would make to the RTcmix source *proper* would need to be published, but the app you develop that uses it would not. I honestly thought I had put up the source for iLooch (it's in the next iRTcmix release), but it looks like the link on the web page is only to the iRTcmix source. Which is what would attach to your app, I *think*. brad On Feb 7, 2011, at 11:41 PM, Morgan Packard wrote: Thanks Brad, Just bought ilooch. Lovely stuff. Unless I'm mistaken though, I'm required to make my source code publicly available if I embed RT CMix because it's licensed under the GPL. I swear, I'm not an _entirely_ evil person, but for a few reasons, I don't think it's going to be possible to open-source my app. However, the fact that I'm running in to this GPL license again and again does make me think that maybe I should reconsider this and see if maybe I can talk myself (and my programming partner) in to it. Though, now that I look, I don't see the iLooch source code posted anywhere. Can you confirm that RT Cmix is an option only if I make the source code to my app publicly available? thanks, -Morgan On Mon, Feb 7, 2011 at 9:25 PM, Brad Gartongar...@columbia.edu wrote: No, it's usable. I have an app already in the App store: http://music.columbia.edu/~brad/ilooch/ We have a new release up in the next few days. brad On Feb 7, 2011, at 8:25 PM, douglas repetto wrote: Brad Garton has RTcmix running on the iPhone: http://music.columbia.edu/~brad/iRTcmix/ Dunno what the license is though... On 2/7/11 8:09 PM, Morgan Packard wrote: (First post to this list. Sent this a few days ago and it doesn't seem to have gone through, so trying again.) Hi There, I've been writing low-level code for my iOS app, Thicket, pretty much myself, with the exception of a sine oscillator and an envelope borrowed from STK. I'd like to be able to work on this platform in a much faster way than I have been, simply plugging unit generators in to one another, not having to stop and think about how to, for example, go from a mono oscillator signal to a stereo reverb signal. I'd like to be able to work more like I work in SuperCollider, writing higher-level code to create a signal path, trusting that the connections will be efficiently managed for me. In other words, I'd like to spend a little less time being a fairly incompetent engineer, and more time being a halfway-decent artist. I'm finding that my list of options is surprisingly small SuperCollider -- GPL licence, would require that I open-source my app ChucK -- GPL license, would require that I open-source my app CSound -- the FAQ indicates that I need to make arrangements with MIT to put it to commercial use. Worth looking in to, perhaps. JSyn -- java, not gonna work on iOS MusicKit -- looks very interesting, but doesn't seem to be a very active project, and I don't think anyone has gotten it running on iOS yet Pure Data -- seems like my best option. more permissive license, but I'm wary of the visual programming paradigm, and have at least one technical detail which is making me a bit uncomfortable Am I missing something? Is there anything -- free, or not, which I should look at for iOS development besides Pure Data? Are there not hundreds of other people
Re: [music-dsp] looking for a flexible synthesis system technically and legally appropriate for iOS development
Wow, that's longer than the tests I've done! brad On Feb 8, 2011, at 3:55 PM, Andy Farnell wrote: Also on Brad's RTCmix, I have never found anything more reliable for basic functions, in a test I had a sound server installation mixing wavs to make random ambient textures, it ran for 4 months without a glitch. -- 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
