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
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
Yeah, no shit just hit the fan... When you least expect it... On Sun, Feb 26, 2012 at 2:26 AM, robert bristow-johnson 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 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
Hi Michael, I agree with you on the below within the "dominant paradigm", but there are a few problematic assumptions that are central to this dicussion. What follows is a somewhat controversial rant, apologies in advance... On 25/02/2012 6:21 AM, Michael Gogins wrote: The two "languages" hidden under the single name "unit generators" are: (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. (2) A metaphor for signal processing operators as being linear time invariant operations inside "little black boxes" (these are what are inside analog synthesizers such as the original modular Moog or the Buchla). The whole LTI thing is incredibly problematic. We've known for a long time that time invarience was just a convenient lie. Things like BIBO stability have been relevant to audio-rate modulation for at least 10 years. Then there is the issue with linearity -- almost nothing "musical" is linear. As I think I said in my previous post, non-linear solvers are now becoming common in analog modelling. Both (1) and (2) assume linear time invariance which guarantees that you can wire up blocks any old way you like and still understand what the result will be, because it will all be linear addition and multiplication. But, in practice, when you open up a block from level (1) you don't usually find smaller more primitive blocks from level (2), with the possible partial exception of Pure Data or Reaktor. What you usually find is gnarly, hard to read procedural C code with loops, arithmetic, and some functions operating in a linear time invariant way on arrays of samples. I don't really agree with you on this "gnarly, hard to read procedural C code" business, except in the case of CSound which is truly gnarly. I always found Cmix ugens to be very clear for example. SuperCollider ugens are pretty good too. In any case, part of the point is, if you want to control the individual samples, and you know C++ then it's not that big a deal. What stands in the way of adopting plain old C++ for software synthesizers is: (a) The metaphor behind (2) is very useful for helping the non-technical musician get a handle on what is going on, especially if they have spent hours fooling around with a Buchla or something like that. 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. 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 only have (1) and maybe a I could pass some of (2) based on industry experience, and I'm starting to study (3).. so I don't yet consider myself qualified. But I know enough about composing and writing software to know that if you want algorithms to be part of your compositional palette (and why else use a computer?) then LTI signal flow is not enough. Of course there are composers who use computers in different ways, say more along the lines of a traditional musical instruments, or as a kind of musical word processor, in this case the pre-requisites are of course different. (c) It is easy to write and, more importantly, to read C++ signal processing code that processes one sample at a time, but only code that processes blocks of at least 20 to 200 samples at a time is really efficient enough to use; unfortunately this kind of code is significantly harder to write, and, more importantly, to understand - the metaphor of (2), and other metaphors, inevitably becomes obscured. I think this can be mostly resolved with a good vectorising compiler (which may or may not exist). That said, I think the runtime environment is also important. A livecoding runtime like extempore is preferable to the traditional C++ toolchain. That said, I still believe that properly written C++ unit generators could be easy to implement, easy to write with, easy to understand, and efficient. But this would be a great deal of work and the very first steps have to be just right or the rest all goes astray. I think it would be important to use blocks that would "look like" individual samples, it would be important to use smart pointers or garbage collection so the composer never has to worry about memory management, and the overall naming conventions would have to be at once concise, elegant, easy to read, and remind one of those
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. P
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] Boulez
On Sunday 26 February 2012, at 01.53.49, Emanuel Landeholm 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] 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] a little about myself
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 -- 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
[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
> 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
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... It's not really about raw speed. On Sunday 26 February 2012, at 01.30.48, Emanuel Landeholm wrote: > In the future, people will be able to emulate our OS:s in real time. > (Kind of like how I am able to emulate a C-64 with minimum latency > right now) So even if we are not quite there yet, our descendants will > know how to run our code, > > > Well, no matter how you go about implementing it, what it comes down to > > is that every sample MUST be in place when the sound card needs it. > > There's just no way around that. :-) > > -- > 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 -- //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] Boulez
In the future, people will be able to emulate our OS:s in real time. (Kind of like how I am able to emulate a C-64 with minimum latency right now) So even if we are not quite there yet, our descendants will know how to run our code, > Well, no matter how you go about implementing it, what it comes down to is > that every sample MUST be in place when the sound card needs it. There's just > no way around that. :-) -- 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 Saturday 25 February 2012, at 15.40.59, Adam Puckett wrote: > 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? Well, no matter how you go about implementing it, what it comes down to is that every sample MUST be in place when the sound card needs it. There's just no way around that. :-) There is one "trick" along those lines, though, often used in video games: Use a shared memory DMA buffer of "substantial" size (half a second or so), and split the mixing code into two parts; 1) one that mixes playing sounds/streams in somewhere down the buffer, for minimal risk of drop-outs, and 2) one that mixes in the initial parts of newly started sounds from pretty the current DMA position (that is, near zero latency), and down to where the other mixer part will take over. However, this won't really eliminate the drop-out problem. All it does is reduce the damage caused by scheduling latency peaks. Instead of the whole stream (soundscape, music, playing effects - everything) glitching or having a dubstep moment, the first few moments of newly started sounds will be lost, while the "old" streams keep playing as usual. I'd say this method is just a complicated band-aid with lots of issues, and not even suitable for musical applications - but if all else fails... -- //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
I get around the Hz spec by calculating
440*2^((x-69)/12)
to get MIDI notes.
On 2/25/12, Brad Garton wrote:
> 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
>
--
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
Hi Charles, > The book collects his Darmstadt lectures from 1954-56 Yes, that era fits better with the ideas conveyed. thanks for the clear up. > Isn't the point not to take sides, but recognize the tension? Definitely. You are absolutely right. That was where I was headed with my remarks. > Could very well be that the callback is the result of a cultural > outlook, and not the result of engineering design… Embellishing my reply to Adam, it's not so much engineering design as engineering circumstance. We find ourselves writing code on general purpose desktop computers with multi-tasking operating systems and a quite unpredictable kernel schedule. Starting from a certain necessity the rest of the design seems to follow quite naturally. 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] Boulez
Hopefully I am not misunderstanding here. I think the big influence on the low level design of music software, viz callbacks &c is that the modern desktop and operating system is such a fiendishly complicated system callback (interrupt led) buffering is essential to mediate the producer consumer problem in this unpredictable runtime. With simpler hardware, and total control over it (as for FPGA), radically different things are possible. I understand why some here like that approach and prefer the idea of a synth or processor being a dedicated _device_. best Andy On Sat, Feb 25, 2012 at 09:40:59AM -0500, Adam Puckett wrote: > 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 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 -- 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's the contents of the headers that triggers bounces/rejections, not
the content of the message. At least for non-plaintext mail. Spam
filtering, of course, also works on message content.
best,
douglas
On 2/25/12 4:33 PM, Tom Wiltshire wrote:
Oh, ok. I assumed that when they said "Rich text" in Mail.app, they
meant the same as when they say "rich text format" in TextEdit. My
mistake.
Checking more carefully, I find you're right. Mail sends "rich text"
messages as "Content-Type: multipart/alternative;" and includes the
"rich text" part in an html attachment
Like this:
This is arich text email
But presumably it's the fact that it's sent as an attachment that
kills delivery to the list since otherwise we'd be reading raw html,
as we can above.
T.
On 25 Feb 2012, at 20:42, Nigel Redmon wrote:
Tom—when Apple says "rich text", they mean that in the generic
sense, not rtf. I don't think Mail has ever sent message in rtf.
On Feb 25, 2012, at 11:22 AM, 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.
-- 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
Oh, ok. I assumed that when they said "Rich text" in Mail.app, they meant the
same as when they say "rich text format" in TextEdit. My mistake.
Checking more carefully, I find you're right. Mail sends "rich text" messages
as "Content-Type: multipart/alternative;" and includes the "rich text" part in
an html attachment
Like this:
This is a rich text
email
But presumably it's the fact that it's sent as an attachment that kills
delivery to the list since otherwise we'd be reading raw html, as we can above.
T.
On 25 Feb 2012, at 20:42, Nigel Redmon wrote:
> Tom—when Apple says "rich text", they mean that in the generic sense, not
> rtf. I don't think Mail has ever sent message in rtf.
>
>
> On Feb 25, 2012, at 11:22 AM, 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.
>>
--
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
Tom—when Apple says "rich text", they mean that in the generic sense, not rtf.
I don't think Mail has ever sent message in rtf.
On Feb 25, 2012, at 11:22 AM, 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
--
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
Even without forcing the message with Make Plain Text (with rich text default), the message gets sent as text/plain—normally. I guess what might happen is some formatting gets bumped in during typing by accident, in which case the message is send as multipart/alternative, with text and html parts, and those messages definitely get rejected. In past versions of mail—years ago—I know I've also seen situations where the font tags were embedded without other html tags, and those were rejected by the list. Mail doesn't seem to behave that way currently, though. On Feb 25, 2012, at 11:07 AM, 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] list postings
Thanks, Bjorn, I've updated the FAQ with more current info. douglas On 2/25/12 2:42 PM, Bjorn Roche wrote: 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 -- ... 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
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] 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] 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] 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
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] 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
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
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
[music-dsp] [OT] Re: google's non-sine
Wow, some of the comments on that article are pretty wacky! +++ Thomas: Another wack job job scientist. His research has lead to 100,000 + deaths in the modern day era, all of these kinds people are sociopaths and murders. +++ Funny that he's so conservative with his conspiracy theory numbers. Surely millions have died as a result of various electromagnetic phenomena! douglas On 2/25/12 2:01 PM, Dave Hoskins wrote: "The waves form a repeating pattern: There's a large blue curve, followed by a shallow red, shallow yellow, deep blue, skinny green, and one final red curve. Those lines match the general shape of Google's traditional logo: Uppercase blue G, small Os, a lowercase g, a skinny green L, and a red E. It's not the most difficult code to decipher, but Google's doodle serves as a lovely metaphor for Hertz's work." http://www.csmonitor.com/Innovation/Horizons/2012/0222/How-Heinrich-Rudolf-Hertz-revealed-the-invisible-world Dave. -- 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
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 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] google's non-sine
"The waves form a repeating pattern: There's a large blue curve, followed by a shallow red, shallow yellow, deep blue, skinny green, and one final red curve. Those lines match the general shape of Google's traditional logo: Uppercase blue G, small Os, a lowercase g, a skinny green L, and a red E. It's not the most difficult code to decipher, but Google's doodle serves as a lovely metaphor for Hertz's work." http://www.csmonitor.com/Innovation/Horizons/2012/0222/How-Heinrich-Rudolf-Hertz-revealed-the-invisible-world Dave. -- 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 24, 2012, at 1:05 PM, 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? Plus the abstracting to levels 'above' plug-ugens allows for different kinds of musical thinking. I love RTcmix's parse language (score language) because of the algorithmic-composition capabilities it opens up. It would be much more difficult if it also had to encompass lower-level DSP specification along with larger 'musical shape' abstractions. 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 24, 2012, at 3:25 AM, Ross Bencina wrote: > 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. Exactly. I've been messing with the idea of rolling up our RTcmix dynamic-loader into a text-edtitor with compilation capabilities to allow direct coding in C/C++ that can then be immediately instantiated in a running audio process, but it still has that separation. And at some point it just gets kind of silly. > 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++). The only language I'm aware of that allows the design of direct sample-massaging code in the language itself is chuck. But it also has a healthy set of unit-generators, because when you reduce the script-execution loop to a sample it becomes *extremely* inefficient. Chuck ugens are coded in C/C++. 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] boulez
Oh that Boulez! Such a comedian! On Feb 25, 2012, at 9:23 AM, Charles Turner wrote: > Could very well be that the callback is the result of a cultural outlook, and > not the result of engineering design… I would invert this -- being more of a techno-determinist I tend to locate contemporary "cultural outlooks" as the result of engineering, or perhaps more specifically 'interface', design. Well, maybe not the whole "cultural outlook" thing, more perhaps the kinds of creativity that arise from our interaction with the tools we use for our creative work. If you'll allow an old[er] guy to indulge in some reminiscing, here's a couple of paragraphs from a paper I wrote back in 1986: "Working with computers to create music during the past several years has made me recognize the integral role played by the interface between my sonic imaginings and their realization. When I pick up a pencil and paper to write a "conventional" piece of music, I automatically adopt a self-established set of assumptions that will fundamentally affect what I compose. Sitting at the keyboard of a terminal does the same thing -- different assumptions, of course. Throw in a mouse and I guarantee that the "set of pieces I might compose" will shift. Different tools make certain activities easier, certain other activities more difficult. This is bound to have at least a subtle effect on what the tools are being used to create. "Throwing in a mouse" points to an aspect of computers that makes them rather unique as musical tools. The interface between myself and computer sound synthesis can be changed with minor hardware changes or (more significantly) by changing the software used to interpret my commands. I find this quite intriguing; being able to control the interface I use to create music gives me a very high-level "conceptual knob" that I can use to change the way I interact with my music making. I might choose to control sound production with a set of stochastic procedures, or I might use graphics software to interpret curves I draw in certain ways, or I might even write an algorithm to translate the words and letters of this paper into sound. In each case, the shape of the resulting piece (and the way I think about it as I produce it) will be different." I know, kind of obvious in a "well, duh..." way, but I still believe this stuff. I do find it slightly dismaying that many of my students now take what is given them (in terms of music-creation tools) without thinking about how those tools alter their view of musical possibility (exhibit A: Abelton). But on the other hand, they now enjoy the luxury of an almost meta-position, when many different approaches are all available. What then becomes important is a heightened awareness of what these tools are doing to creative imaginings. And when they become overly-constraining, explore the potential of altering/designing-your-own system. And I am really excited by the work people are doing in physical computing, new interfaces, new installation-type thingies, the whole NIME approach. I'm just a spectator, being a software guy myself. But it sure is fun! 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
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
[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
[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
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 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
Re: [music-dsp] google's non-sine
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
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] 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 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] 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] 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] 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] google's non-sine
On Sat, Feb 25, 2012 at 10:58:52AM +, Richard Dobson wrote: > On 25/02/2012 09:40, Andy Farnell wrote: > .. > And the harsh truth is that no competing search engine will succeeed > unless its name works well as a verb. Astute. Maybe the duck is doomed already. Unless it becomes normative that doing some research is "Ducking the question". Yes degooglize is much better, particularly with the American z. best 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 Fri, Feb 24, 2012 at 01:21:05PM -0500, Charles Turner wrote: > On Feb 24, 2012, at 1:05 PM, Andy Farnell wrote: > > > Some really interesting thoughts here Ross. At what level of > > granularity does the trade-off of control, flexibility and > > efficiency reach its sweet spot? > > “I understand that the dialectic of composition better contents itself > with neutral objects, not easily identifiable ones, like pure tones or > simple tone aggregates, having no inner profile of dynamics, duration > or timbre. As soon as one shapes elaborated figures, assembles them > into ‘formed’ complexes, and uses them as first-order objects for > composition, one is not to forget [...] that they have lost all > neutrality and acquired a personality, an individuality which makes > them quite unfit for a generalized dialectics of sonic relations.” > > Pierre Boulez: p.45, _Penser la musique aujourd’hui_, (1994) > For me it's strange to see that written in 1994, close to the time I was behind the lines of British pop culture, where the precise opposite was true. Superstar DJs, music media moguls and influential producers romped and rollicked in an entirely sample based, second order culture. The symbols and currency of composition were drum loops, pre-made chord sounds or "stabs and hits", a cappella vocal hooks. Of course that had a profound influence on my own music making, my approach and understanding of what composition is. Pop is precisely about rearranging second order symbols. But as a computer guy, I also noticed how culture influenced the software, how marketing and the values of those deemed successful manipulated the tools, and the tools in turn manipulated the possibilities of new music makers. To this day I love to show my students this funny ad as a warning... http://obiwannabe.co.uk/temp/software.jpg 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. Composition is just very hard work, time consuming and needs diverse human capacities like poetic skills. It's fundamentally at odds with the values of "making things easy". The danger then, in a world where products dominate principles, is to fall into the trap of deliberately making things difficult for yourself. To quote a cohort, Chris McCormick "Making boring techno music is really easy with modern tools, but with live coding, boring techno is much harder." http://news.bbc.co.uk/1/hi/technology/8244003.stm The actual sweet spot is surely different for each person. But you certainly will not find it if you either start with a very strong idea of how music must be made, or are constrained by tools that impose other peoples strong ideas upon you. best, 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] 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
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. On the subject of creating worlds, I've missed this conversation entirely because of a courageous attempt to degooglify my life and get out of the scrutinised bubble. Since switching to the Duck search engine I discovered a whole internet out there. Maybe takes longer to find exact thing, but if you're that desperate to save half a second here and there your life is in trouble anyway, and the plus side is rediscovering the colourful, trashy landscape not interpreted through an individual bourgeois materialist lens. Turns out DSP stands for many different things, so by making more focussed searches and pausing for a moment to think instead of lean on the mental crutch, things actually work out better. On the weird side, LaTeX is more than a document processor. There's even a perfume called Philosophy. On Fri, Feb 24, 2012 at 09:06:59PM +, Tom Wiltshire wrote: > I agree as well. Why should it have to be a sine wave? Hertz didn't invent > the sine wave! A square wave has 'frequency' just as much as a sine does, > and presumably 'frequency' was the point of the googledoodle. Put the odd > harmonics in and get a circular waveform, it's fine by me. > > The amplitude and frequency modulation is a bit weird though! > > T. -- 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
