Re: [music-dsp] google's non-sine
On 25/02/2012 09:40, Andy Farnell wrote: .. On the subject of creating worlds, I've missed this conversation entirely because of a courageous attempt to degooglify my life great word! I wonder though if it should be more like degooglise, as you are changing or reducing state, rather than actively making something, which is what the 'ify' suffix would suggest. Such questions are of great importance, as once enshrined in the OED words are frozen for all time. And the harsh truth is that no competing search engine will succeeed unless its name works well as a verb. I heard only the other day on a news bulletin the reference to James Dyson as someone who had invented a new hoover. 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] google's non-sine
Of course, I know I'm being didactic, creative design is great and I'm 100% in favor of doing things wrong. I just thought doing a wacky sinewave animation would have been more interesting than doing a wacky non-sinewave animation. Maybe I've just seen too many non-sines drawn by students who aren't being creative, they just don't get the difference (yet!) between two half-circles and a sinewave. douglas On 2/25/12 4:40 AM, Andy Farnell wrote: When the lovely people at MIT added some extra cool graphics to my book cover I was initially dismayed to see the usual funky oscilloscope trace with a blue tint, looking like an electric spark. But everyone I showed it to, my friends and family all thought it was amazing and futuristic! So I quickly got over my pedantry and embraced a new found ability to create signals that go backwards in time as well as forwards. Graphic designers create their worlds, we create ours. -- ... 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] music-dsp Digest, Vol 98, Issue 66
douglas repetto wrote Sat Feb 25 08:21:23 EST 2012: non-sinewave animation. Maybe I've just seen too many non-sines drawn by students who aren't being creative, they just don't get the difference (yet!) between two half-circles and a sinewave. Serious engineering students (who else wouldbe the future leaders of the technology of software ?) shouldn't find it hard to do some simple analysis like a Taylor expansion, or rather simplistic trigonometric considerations. More advanced ones shouldn't even find it impossible to qualitatively or quantitatively transform their curves or the circular considerations into a (repeated wave) frequency analysis, either by formalisms of the Fourier type or by using an FFT library/program! It wouldn't hurt to consider the variations of such wave with times and trying to characterize those, and considering how those waves come across through normal reverberation effects, or at least some singular sound sheeres along a wall. Theo V. -- 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] Boulez
On Feb 25, 2012, at 6:34 AM, Andy Farnell wrote: And whereas I do agree with Pierre Boulez here, maybe it is misguided to turn to reductionism and simplicity for their own sake. It may be equally hopeless to embark on a quest for authenticity this way. Hi Andy- I should apologize for hastily listing the publication date of the book. The book collects his Darmstadt lectures from 1954-56, so it comes from a much earlier time. I don't think Boulez would have changed his mind on things though. Sounds like you come from a much more Schaefferian era. Isn't the point not to take sides, but recognize the tension? Cultures that are busily exploring harmonic relations, haven't simultaneously plunged deep into the world of rhythm. Music is just too big a subject, and some of its properties exist in a dialectical relation to others. Although we all enjoy a sweet dessert, we don't put sugar in everything. (Unless you're the Nestle company!) My point was that the checkpoint raised by callbacks feeding a sample buffer may come from resistances outside the technical world. Boulez sees timbre as the enemy of harmony. Could very well be that the callback is the result of a cultural outlook, and not the result of engineering design… Best, 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
Re: [music-dsp] Boulez
Would it be possible to design a callback that dynamically filled the buffer as it was being called, or if the buffer didn't exist, create it and put one sample in it? that way there wouldn't be any dropped calls in the process. Or am I missing something? On 2/25/12, Charles Turner vze26...@optonline.net wrote: On Feb 25, 2012, at 6:34 AM, Andy Farnell wrote: And whereas I do agree with Pierre Boulez here, maybe it is misguided to turn to reductionism and simplicity for their own sake. It may be equally hopeless to embark on a quest for authenticity this way. Hi Andy- I should apologize for hastily listing the publication date of the book. The book collects his Darmstadt lectures from 1954-56, so it comes from a much earlier time. I don't think Boulez would have changed his mind on things though. Sounds like you come from a much more Schaefferian era. Isn't the point not to take sides, but recognize the tension? Cultures that are busily exploring harmonic relations, haven't simultaneously plunged deep into the world of rhythm. Music is just too big a subject, and some of its properties exist in a dialectical relation to others. Although we all enjoy a sweet dessert, we don't put sugar in everything. (Unless you're the Nestle company!) My point was that the checkpoint raised by callbacks feeding a sample buffer may come from resistances outside the technical world. Boulez sees timbre as the enemy of harmony. Could very well be that the callback is the result of a cultural outlook, and not the result of engineering design… Best, 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] google's non-sine
On 2/25/12 8:43 AM, Theo Verelst wrote: douglas repetto wrote Sat Feb 25 08:21:23 EST 2012: non-sinewave animation. Maybe I've just seen too many non-sines drawn by students who aren't being creative, they just don't get the difference (yet!) between two half-circles and a sinewave. Serious engineering students (who else wouldbe the future leaders of the technology of software ?) shouldn't find it hard to do some simple analysis like a Taylor expansion, or rather simplistic trigonometric considerations. My students tend to be musicians and artists who often think they're bad at math or hate math. So when I start talking about unit circles and sinewaves or Ohm's Law and basic algebra, they're often a bit worried... But usually they get really excited when they realize that a lot of this stuff is pretty simple even if you don't have much/any math/engineering background. To me that's the most exciting thing, getting non-experts to realize that their non-expertise is not a barrier to them doing creative things with something like DSP or electronics. So maybe it's dumb/ironic that I'm complaining about Google doing something wacky with an animation, since my students and I certainly do wacky/unconventional things with code and electronics! Anywho, I went back and looked at the animation some more and I agree that it's pretty charming and that there's really no reason why it should be a sinewave. Sorry for wasting bandwidth! douglas -- ... 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] google's non-sine
I rather enjoy math and programming. That's why I read Csound opcodes in source form. On 2/25/12, Theo Verelst theo...@tiscali.nl wrote: douglas repetto douglas wrote Sat Feb 25 12:07:19 EST 2012: Sorry for wasting bandwidth! I'll be darned if I'd have to call a serious discussion a waste of a couple of milliseconds router-time, so by no means do I prefer to be accused of saying that ! I should like to think more than a few conservatory students (both male and female) have sufficient interest in these subjects, so maybe you're right it's a good calling to alleviate some of the need for mathematics. And concerning Andy's point about boringness, I recall that when drum computer were invented they too were called boring, and producing music with them as spawning headaches... Theo V. -- 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
[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
I wonder if your ISP is eating them somehow. Usually when posts don't go through a bounce message is generated. BTW, several people have had trouble posting recently because they were sending HTML mail to the list. Please remember that you can only send plaintext and no attachments. best, douglas On 2/25/12 1:38 PM, Brad Garton wrote: and some go through, some don't... I don't see anything clearly spam-like in the posts that got dropped. brad On Feb 25, 2012, at 1: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 -- 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] 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] list postings
I've had problems in the past when html-style font tags make their way into the email. For instance, this happens in Apple's Mail.app. Even though it's not an html email, per se, they sometimes get rejected (but not always). If I do Make Plain Text from the Format menu before sedning, then they always get through—there is no visible change to the email either (because they are just some default font tags—I'm not really formatting the text). On Feb 25, 2012, at 10:38 AM, 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
Re: [music-dsp] list postings
It may be that Apple is adding something to the header indicating rich text/html even though you don't end up with offending characters in the email. The list software rejects email based on the headers, not on the actual content. There's no fundamental reason why the list can't accept html mail, btw. So if people really want it we can make a change. In the past it's been about spam control and saving bandwidth, but those issues aren't such big concerns anymore, I think. Although I personally find that reading a list like this in different fonts/colors/styles can be unpleasant. douglas On 2/25/12 2:02 PM, Nigel Redmon wrote: I've had problems in the past when html-style font tags make their way into the email. For instance, this happens in Apple's Mail.app. Even though it's not an html email, per se, they sometimes get rejected (but not always). If I do Make Plain Text from the Format menu before sedning, then they always get through—there is no visible change to the email either (because they are just some default font tags—I'm not really formatting the text). On Feb 25, 2012, at 10:38 AM, 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 -- ... 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] list postings
I've never had an email get through to this list, and I've never gotten a rejection notice, which is sad b/c once or twice I've actually had something constructive to say. (on two occasions, I've just email the original posters) With this email, I am explicitly setting the format to plain, as suggested, and we'll see. It's annoying because gmail filters out sent mail from received mail, so it doesn't show you list mail that you sent, and since I don't get a bounce for some reason, there's no way to know the email is missed! The best I can do is check the archives after its sent :-P bjorn On Feb 25, 2012, at 2:07 PM, douglas repetto wrote: It may be that Apple is adding something to the header indicating rich text/html even though you don't end up with offending characters in the email. The list software rejects email based on the headers, not on the actual content. There's no fundamental reason why the list can't accept html mail, btw. So if people really want it we can make a change. In the past it's been about spam control and saving bandwidth, but those issues aren't such big concerns anymore, I think. Although I personally find that reading a list like this in different fonts/colors/styles can be unpleasant. douglas On 2/25/12 2:02 PM, Nigel Redmon wrote: I've had problems in the past when html-style font tags make their way into the email. For instance, this happens in Apple's Mail.app. Even though it's not an html email, per se, they sometimes get rejected (but not always). If I do Make Plain Text from the Format menu before sedning, then they always get through—there is no visible change to the email either (because they are just some default font tags—I'm not really formatting the text). On Feb 25, 2012, at 10:38 AM, 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 -- ... 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 - Bjorn Roche http://www.xonami.com Audio Collaboration http://blog.bjornroche.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] list postings
And btw, you should receive a message from the list software with links to the list FAQs, which detail various reasons why your messages might not make it through. http://music.columbia.edu/cmc/music-dsp/musicdspFAQ.admin.html best, douglas On 2/25/12 2:20 PM, douglas repetto wrote: Well it looks like the problem was that you were sending non-plaintext! The reason that you don't receive a rejection notice when sending non-plaintext is that the messages aren't bounced, they're held for moderation. In the old days I'd go in and approve such messages. Today we get THOUSANDS of spam messages a day, so the server just deletes all held messages each day. SPAM bots have really made mailing lists, wiki maintenance, etc., annoying. best, douglas On 2/25/12 2:14 PM, Bjorn Roche wrote: I've never had an email get through to this list, and I've never gotten a rejection notice, which is sad b/c once or twice I've actually had something constructive to say. (on two occasions, I've just email the original posters) With this email, I am explicitly setting the format to plain, as suggested, and we'll see. It's annoying because gmail filters out sent mail from received mail, so it doesn't show you list mail that you sent, and since I don't get a bounce for some reason, there's no way to know the email is missed! The best I can do is check the archives after its sent :-P bjorn On Feb 25, 2012, at 2:07 PM, douglas repetto wrote: It may be that Apple is adding something to the header indicating rich text/html even though you don't end up with offending characters in the email. The list software rejects email based on the headers, not on the actual content. There's no fundamental reason why the list can't accept html mail, btw. So if people really want it we can make a change. In the past it's been about spam control and saving bandwidth, but those issues aren't such big concerns anymore, I think. Although I personally find that reading a list like this in different fonts/colors/styles can be unpleasant. douglas On 2/25/12 2:02 PM, Nigel Redmon wrote: I've had problems in the past when html-style font tags make their way into the email. For instance, this happens in Apple's Mail.app. Even though it's not an html email, per se, they sometimes get rejected (but not always). If I do Make Plain Text from the Format menu before sedning, then they always get through—there is no visible change to the email either (because they are just some default font tags—I'm not really formatting the text). On Feb 25, 2012, at 10:38 AM, 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 -- ... 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 - Bjorn Roche http://www.xonami.com Audio Collaboration http://blog.bjornroche.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 -- ... 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] list postings
Here's an example of a basic RTF document:
{\rtf1\ansi\ansicpg1252\cocoartf1038\cocoasubrtf360
{\fonttbl\f0\fswiss\fcharset0 Helvetica;}
{\colortbl;\red255\green255\blue255;}
\paperw11900\paperh16840\margl1440\margr1440\vieww9000\viewh8400\viewkind0
\pard\tx566\tx1133\tx1700\tx2267\tx2834\tx3401\tx3968\tx4535\tx5102\tx5669\tx6236\tx6803\ql\qnatural\pardirnatural
\f0\fs24 \cf0 This is a basic rtf document\
}
I don't know what headers Apple's Mail.app sends out with this, but I can see
why you wouldn't want to read that as plain text. Even if it got through (eg if
the headers were ok) we'd still struggle to read it.
(The file was saved from Apple's TextEdit.app, in case anyone wants to know
where the example came from)
T.
On 25 Feb 2012, at 19:07, douglas repetto wrote:
It may be that Apple is adding something to the header indicating rich
text/html even though you don't end up with offending characters in the
email. The list software rejects email based on the headers, not on the
actual content.
There's no fundamental reason why the list can't accept html mail, btw. So if
people really want it we can make a change. In the past it's been about spam
control and saving bandwidth, but those issues aren't such big concerns
anymore, I think. Although I personally find that reading a list like this in
different fonts/colors/styles can be unpleasant.
douglas
On 2/25/12 2:02 PM, Nigel Redmon wrote:
I've had problems in the past when html-style font tags make their
way into the email. For instance, this happens in Apple's Mail.app.
Even though it's not an html email, per se, they sometimes get
rejected (but not always). If I do Make Plain Text from the Format
menu before sedning, then they always get through—there is no visible
change to the email either (because they are just some default font
tags—I'm not really formatting the text).
On Feb 25, 2012, at 10:38 AM, 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
--
... 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
--
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
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] list postings
Reading rich text email is email client dependent. Modern clients look
at the headers and interpret the email accordingly.
I guess that's another argument against allowing non-plaintext -- it
makes it really difficult to read the list in old school email clients
that have no rich text parsing.
douglas
On 2/25/12 2:22 PM, Tom Wiltshire wrote:
Here's an example of a basic RTF document:
{\rtf1\ansi\ansicpg1252\cocoartf1038\cocoasubrtf360
{\fonttbl\f0\fswiss\fcharset0 Helvetica;}
{\colortbl;\red255\green255\blue255;}
\paperw11900\paperh16840\margl1440\margr1440\vieww9000\viewh8400\viewkind0
\pard\tx566\tx1133\tx1700\tx2267\tx2834\tx3401\tx3968\tx4535\tx5102\tx5669\tx6236\tx6803\ql\qnatural\pardirnatural
\f0\fs24 \cf0 This is a basic rtf document\ }
I don't know what headers Apple's Mail.app sends out with this, but I
can see why you wouldn't want to read that as plain text. Even if it
got through (eg if the headers were ok) we'd still struggle to read
it.
(The file was saved from Apple's TextEdit.app, in case anyone wants
to know where the example came from)
T.
On 25 Feb 2012, at 19:07, douglas repetto wrote:
It may be that Apple is adding something to the header indicating
rich text/html even though you don't end up with offending
characters in the email. The list software rejects email based on
the headers, not on the actual content.
There's no fundamental reason why the list can't accept html mail,
btw. So if people really want it we can make a change. In the past
it's been about spam control and saving bandwidth, but those issues
aren't such big concerns anymore, I think. Although I personally
find that reading a list like this in different fonts/colors/styles
can be unpleasant.
douglas
On 2/25/12 2:02 PM, Nigel Redmon wrote:
I've had problems in the past when html-style font tags make
their way into the email. For instance, this happens in Apple's
Mail.app. Even though it's not an html email, per se, they
sometimes get rejected (but not always). If I do Make Plain Text
from the Format menu before sedning, then they always get
through—there is no visible change to the email either (because
they are just some default font tags—I'm not really formatting
the text).
On Feb 25, 2012, at 10:38 AM, 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
-- ...
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
-- 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] list postings
On Feb 25, 2012, at 2:21 PM, douglas repetto wrote: And btw, you should receive a message from the list software with links to the list FAQs, which detail various reasons why your messages might not make it through. http://music.columbia.edu/cmc/music-dsp/musicdspFAQ.admin.html Nothing there about rtf. just html. It also says I should have received a bounce. Perhaps that should be clarified. Reading rich text email is email client dependent. Modern clients look at the headers and interpret the email accordingly. I guess that's another argument against allowing non-plaintext -- it makes it really difficult to read the list in old school email clients that have no rich text parsing. I used to use mutt and pine and I never had a problem with this. Even if they can't parse the formatted text, most clients send a plain text version along with the formatted version as alternative views, but maybe things have changed. bjorn - Bjorn Roche http://www.xonami.com Audio Collaboration http://blog.bjornroche.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 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] Boulez
While raw speed does reduce the risk of missing deadlines, you need an infinitely fast computer to guarantee hard realtime performance with code that isn't designed for it. Also, theoretically, not even that helps, unless you also have a realtime OS. And then there's I/O, synchronization and blocking calls... True. Real time is certainly something we might approach asymptotically, but exceptionally bad code we cannot really do anything about. But I remain optimistic. Our descendants should be able to emulate most of our endeavours with high enough degree of accuracy. -- 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] guitar physical model
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
Re: [music-dsp] Boulez
On 2/25/12 9:23 AM, Charles Turner wrote: My point was that the checkpoint raised by callbacks feeding a sample buffer may come from resistances outside the technical world. Boulez sees timbre as the enemy of harmony. Could very well be that the callback is the result of a cultural outlook, and not the result of engineering design… I think there's an interesting analogy to things that happened with Western musical notation in the 20th century. Standard Western notation treats measures a bit like buffers -- they need to be there whether there's anything happening or not. A full orchestral score can be largely made of up thousands of rests. Measures mark time in a more or less linear way. A measure can be subdivided up into a certain number of chunks and all of those chunks need to be accounted for in every measure. Etc. But lots of composers have resisted these things, and the 20th century saw many experiments with either tweaking traditional notation or just inventing totally new ways of describing music on a page. A curious aspect of both filling buffers with samples and putting notes and rests on a page is that there's an assumption that the musicians (or the algorithms or whatever) are always on, but that sometimes they're just not making any sound. But that's not really how live musicians tend to think of it. It's not like a violinist keeps her bow moving at all times and only touches it to the strings when there's a note to be played. But that's kinda what sending zeros to a buffer when there's no sound is like. On the other hand, if you work directly in hardware (say using an analog synth, hooking up logical oscillators, or programming a microcontroller) you can take a very different approach. You twiddle some output pins when you want sound and when you don't want sound you can just go off and do other things. In many ways I think that's a lot more like what many musicians do -- when you're not playing (either because you've got a bunch of rests, or maybe you're playing improvised music and you're just sitting out for awhile, or whatever) you don't really sit there counting off the beats. You stop playing. You might think about other things. After awhile hopefully you'll notice that the conductor is about to cue you in, or you get an idea and decide to join the improvisation, etc. I've seen people reading books in Broadway orchestra pits... I don't know that there's a useful connection to different ways of thinking about writing DSP routines, but I think the analogy is interesting. douglas -- ... 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] Boulez
On Sunday 26 February 2012, at 01.53.49, Emanuel Landeholm emanuel.landeh...@gmail.com wrote: While raw speed does reduce the risk of missing deadlines, you need an infinitely fast computer to guarantee hard realtime performance with code that isn't designed for it. Also, theoretically, not even that helps, unless you also have a realtime OS. And then there's I/O, synchronization and blocking calls... True. Real time is certainly something we might approach asymptotically, but exceptionally bad code we cannot really do anything about. But I remain optimistic. Our descendants should be able to emulate most of our endeavours with high enough degree of accuracy. It certainly helps when you can do interesting stuff in suboptimal ways, and still end up using only a few percent of one of your many CPU cores. :-) -- //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] 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
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] Boulez
It certainly helps when you can do interesting stuff in suboptimal ways, and still end up using only a few percent of one of your many CPU cores. :-) Actually, this is my routine for determining whether or not I'm living in the future: look up suboptimal in the dictionary. If it isn't there, I'm living in the future. Another check is: does my personal computing device have orders of magnitude more RAM than the major image processing research main frame at Linköping Tech had back when I studied there. (check!) -- 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
