From douglas at music.columbia.edu Fri Aug 1 00:00:01 2008 From: douglas at music.columbia.edu (douglas repetto) Date: Fri Aug 1 00:00:05 2008 Subject: [music-dsp] [admin] music-dsp FAQ Message-ID: <20080801040001.2A8BB30140663@music.columbia.edu> Hi, Just a reminder that if you are new to the list you should read the music-dsp FAQ. It contains answers to both technical _and_ adminstrative questions that often come up on the list. If your question appears in the FAQ it is safe to assume that it has been discussed on the list many times in the past, and you should probably have a look through the list archives before posting your question to the list. http://music.columbia.edu/cmc/music-dsp/musicdspFAQ.html Also of interest to new and not-so-new list members: The music-dsp list archives http://music.columbia.edu/cmc/music-dsp/musicdsparchives.html The music-dsp source code archive http://www.musicdsp.org music-dsp books and reviews http://music.columbia.edu/cmc/music-dsp/dspbooks.html All this and more at: http://music.columbia.edu/cmc/music-dsp Hasta la pasta, douglas (this is an automated message sent out on the 1st and 15th of each month) From chriswareham at chriswareham.demon.co.uk Wed Aug 6 10:11:15 2008 From: chriswareham at chriswareham.demon.co.uk (Chris Wareham) Date: Wed Aug 6 10:11:30 2008 Subject: [music-dsp] Sample Dump Standard utility for Linux? Message-ID: <4899B103.3050203@chriswareham.demon.co.uk> Hi, I've recently acquired an Emu SP-12 drum machine, which supports 12bit sampling. To archive samples, I'd like to use the SDS support which I believe the SP-12 has to store them on my computer. An hour or so spent searching the web suggests there aren't any existing utilities for Linux that support SDS. I've written a number of MIDI utilities in the past, most notably a patch editor and librarian for the Roland Alpha/Juno family of synths, so I've decided to write my own SDS utility - however, I thought I'd ask on this list first in case anyone has already written some suitable code that they'd be willing to share. Regards, Chris From mdsp-erikd at mega-nerd.com Wed Aug 6 16:18:29 2008 From: mdsp-erikd at mega-nerd.com (Erik de Castro Lopo) Date: Wed Aug 6 16:18:47 2008 Subject: [music-dsp] Sample Dump Standard utility for Linux? In-Reply-To: <4899B103.3050203@chriswareham.demon.co.uk> References: <4899B103.3050203@chriswareham.demon.co.uk> Message-ID: <20080807061829.8127b5c0.mdsp-erikd@mega-nerd.com> On Wed, 06 Aug 2008 15:11:15 +0100 Chris Wareham wrote: > Hi, > > I've recently acquired an Emu SP-12 drum machine, which supports 12bit > sampling. To archive samples, I'd like to use the SDS support which I > believe the SP-12 has to store them on my computer. An hour or so spent > searching the web suggests there aren't any existing utilities for Linux > that support SDS. libsndfile (which is developed on Linux but is also cross platform) reads and writes SDS files. That allows you to read you SDS files into any one of the common Linux sound file editors like Audacity or Sweep, or load in other files and save them as SDS. Is that what you are after? Cheers, Erik -- Erik de Castro Lopo From chriswareham at chriswareham.demon.co.uk Wed Aug 6 17:06:52 2008 From: chriswareham at chriswareham.demon.co.uk (Chris Wareham) Date: Wed Aug 6 17:07:09 2008 Subject: [music-dsp] Sample Dump Standard utility for Linux? In-Reply-To: <20080807061829.8127b5c0.mdsp-erikd@mega-nerd.com> References: <4899B103.3050203@chriswareham.demon.co.uk> <20080807061829.8127b5c0.mdsp-erikd@mega-nerd.com> Message-ID: <489A126C.6060409@chriswareham.demon.co.uk> Erik de Castro Lopo said on 06/08/08 21:18: > On Wed, 06 Aug 2008 15:11:15 +0100 > Chris Wareham wrote: > >> Hi, >> >> I've recently acquired an Emu SP-12 drum machine, which supports 12bit >> sampling. To archive samples, I'd like to use the SDS support which I >> believe the SP-12 has to store them on my computer. An hour or so spent >> searching the web suggests there aren't any existing utilities for Linux >> that support SDS. > > libsndfile (which is developed on Linux but is also cross platform) > reads and writes SDS files. That allows you to read you SDS files > into any one of the common Linux sound file editors like Audacity > or Sweep, or load in other files and save them as SDS. > > Is that what you are after? > > Cheers, > Erik Hi Erik, I've had a look thought the libsndfile API, and I now have the impression that the SDS is not only a way to transmit data between devices, but is also a standard "encoding" for sample data. In other words, the 12bit SDS data from one device, say an Emu SP-12 is in the same format as that from another 12bit sampler like the Ensoniq Mirage. (I seem to recall that the Mirage is 12bit - but I hope you get the point I'm trying to make even if it isn't). If I'm understanding correctly, it means that once I have retrieved a sample dump from the SP-12, I can load it into a suitable version of Audacity, as it uses libsndfile to convert from SDS to WAV format. Would this impression be correct? If so, then all I have to do is use something like the ALSA "raw MIDI" API to perform the dump, and save the results to a file. It was actually the performing of the dump itself that I was initially asking about, but it would be great to know that once I've managed this I can edit samples on my computer! Regards, Chris From mdsp-erikd at mega-nerd.com Wed Aug 6 18:17:43 2008 From: mdsp-erikd at mega-nerd.com (Erik de Castro Lopo) Date: Wed Aug 6 18:18:04 2008 Subject: [music-dsp] Sample Dump Standard utility for Linux? In-Reply-To: <489A126C.6060409@chriswareham.demon.co.uk> References: <4899B103.3050203@chriswareham.demon.co.uk> <20080807061829.8127b5c0.mdsp-erikd@mega-nerd.com> <489A126C.6060409@chriswareham.demon.co.uk> Message-ID: <20080807081743.05e23f2c.mdsp-erikd@mega-nerd.com> On Wed, 06 Aug 2008 22:06:52 +0100 Chris Wareham wrote: > I've had a look thought the libsndfile API, and I now have the > impression that the SDS is not only a way to transmit data between > devices, but is also a standard "encoding" for sample data. Yep, its mainly a sample interchange and storage format. > In other > words, the 12bit SDS data from one device, say an Emu SP-12 is in the > same format as that from another 12bit sampler like the Ensoniq Mirage. Its a long time since I read it, but I think the SDS standard even specifies what to do when the bit widths don't match. > If I'm understanding > correctly, it means that once I have retrieved a sample dump from the > SP-12, I can load it into a suitable version of Audacity, as it uses > libsndfile to convert from SDS to WAV format. It doesn't so much convert from SDS to WAV but reads any format understood by libsndfile into its own internal data representation. It can also write from that internal data representation to any format supported by libsndfile. I would expect that most sound file editors have their own internal data representation and only convert to disk formats like AIFF, WAV, AU, SDS etc when reading/writing from/to disk. > If so, then all I have to do is use something like the ALSA > "raw MIDI" API to perform the dump, and save the results to a file. I haven't tried this myself, but yes I expect so. The Linux-Audio-Users mailing list would be a good place to ask questions if you have trouble. > It was actually the performing of the dump itself that I was initially > asking about, but it would be great to know that once I've managed this > I can edit samples on my computer! I think the only thing really missing is the ability to edit loop points in the SDS file. That is definitely something that could be added to libsndfile without too much trouble. Cheers, Erik -- Erik de Castro Lopo From chriswareham at chriswareham.demon.co.uk Wed Aug 6 19:01:04 2008 From: chriswareham at chriswareham.demon.co.uk (Chris Wareham) Date: Wed Aug 6 19:01:18 2008 Subject: [music-dsp] Sample Dump Standard utility for Linux? In-Reply-To: <20080807081743.05e23f2c.mdsp-erikd@mega-nerd.com> References: <4899B103.3050203@chriswareham.demon.co.uk> <20080807061829.8127b5c0.mdsp-erikd@mega-nerd.com> <489A126C.6060409@chriswareham.demon.co.uk> <20080807081743.05e23f2c.mdsp-erikd@mega-nerd.com> Message-ID: <489A2D30.5050201@chriswareham.demon.co.uk> Erik de Castro Lopo said on 06/08/08 23:17: > On Wed, 06 Aug 2008 22:06:52 +0100 > Chris Wareham wrote: > >> I've had a look thought the libsndfile API, and I now have the >> impression that the SDS is not only a way to transmit data between >> devices, but is also a standard "encoding" for sample data. > > Yep, its mainly a sample interchange and storage format. > Great, I'll hopefully be able to use Audacity to see of I've dumped valid samples or just a bunch of random bytes! >> In other >> words, the 12bit SDS data from one device, say an Emu SP-12 is in the >> same format as that from another 12bit sampler like the Ensoniq Mirage. > > Its a long time since I read it, but I think the SDS standard even > specifies what to do when the bit widths don't match. > I got the impression you simply pad the most significant bits with zero when converting to a wider bit width, and truncate the most significant bits if you're converting to a narrower bit width. I'm probably just being naive though ... It also seems that while MIDI messages are little endian, SDS data within a SysEx message is big endian. >> If I'm understanding >> correctly, it means that once I have retrieved a sample dump from the >> SP-12, I can load it into a suitable version of Audacity, as it uses >> libsndfile to convert from SDS to WAV format. > > It doesn't so much convert from SDS to WAV but reads any format > understood by libsndfile into its own internal data representation. > It can also write from that internal data representation to any format > supported by libsndfile. > > I would expect that most sound file editors have their own internal > data representation and only convert to disk formats like AIFF, WAV, > AU, SDS etc when reading/writing from/to disk. > >> If so, then all I have to do is use something like the ALSA >> "raw MIDI" API to perform the dump, and save the results to a file. > > I haven't tried this myself, but yes I expect so. The Linux-Audio-Users > mailing list would be a good place to ask questions if you have trouble. > I'll subscribe to that list and the ALSA developers one, as I've now had a further look through the docs for the ALSA library and it looks like I can choose between the "Raw MIDI" and "Sequencer" API's. I'll probably use the former, as I can then write a simple wrapper around the OSS compatible library available on NetBSD (my preferred Unix-like operating system). >> It was actually the performing of the dump itself that I was initially >> asking about, but it would be great to know that once I've managed this >> I can edit samples on my computer! > > I think the only thing really missing is the ability to edit loop points > in the SDS file. That is definitely something that could be added to > libsndfile without too much trouble. > I'm pretty sure the SP-12 doesn't support the loop point messages, as I understand that they were a later addition to the SDS. Unfortunately, the SP-12 manual doesn't even include a MIDI implementation chart, so I'm only assuming that it event support the core of the SDS because several editors and librarians existed for the Apple Mac! > Cheers, > Erik Regards, Chris From andym00 at gmail.com Thu Aug 7 04:49:10 2008 From: andym00 at gmail.com (andy) Date: Thu Aug 7 04:49:31 2008 Subject: [music-dsp] Sample Dump Standard utility for Linux? In-Reply-To: <489A126C.6060409@chriswareham.demon.co.uk> References: <4899B103.3050203@chriswareham.demon.co.uk> <20080807061829.8127b5c0.mdsp-erikd@mega-nerd.com> <489A126C.6060409@chriswareham.demon.co.uk> Message-ID: On Wed, Aug 6, 2008 at 11:06 PM, Chris Wareham wrote: > > (I seem to recall that the Mirage is 12bit - but I hope you get the > point I'm trying to make even if it isn't). The Mirage was 8bit :) From pfultz2 at yahoo.com Sat Aug 9 11:02:23 2008 From: pfultz2 at yahoo.com (paul Fultz) Date: Sat Aug 9 11:02:39 2008 Subject: [music-dsp] All Pass Filters Message-ID: <273103.97356.qm@web90601.mail.mud.yahoo.com> Hi, i was trying to work with all pass filters to reduce the phase shift from filters. So i tried using the all pass from the cookbook formula, im not sure exactly how to use it, but i had to invert the response(take the reciprocal of the transfer function) to get it to be useful, here is what i did, first i used a lowpass and then an allpass both using Q=0.707, which didnt seem to help unless i move the frequency up an octave for the allpass, and then that did reduce the phase for at least the passband part. Secondly, i tried using a fourth order butterworth and then the allpass set to Q=0.707 again(but not moving the frequency up an octave) and then it did really well in reducing the phase shift. Thirdly, i tried using two second order butterworth(essiently a linkwitz-riley) and then the allpass set to Q=0.707, this actually equalized the phase back to zero, getting a constant group delay across all frequencies. Is this the way to use the allpass? and is there another way to set an allpass to get zero-phase using just a second-order butterworth and the allpass? or even the fourth order and the allpass? thanks, paul From rbj at audioimagination.com Sat Aug 9 15:12:37 2008 From: rbj at audioimagination.com (robert bristow-johnson) Date: Sat Aug 9 15:12:56 2008 Subject: [music-dsp] All Pass Filters Message-ID: <20080809191237.408D554D6B8@ws6-9.us4.outblaze.com> > ----- Original Message ----- > From: "paul Fultz" > To: music-dsp@music.columbia.edu > Subject: [music-dsp] All Pass Filters > Date: Sat, 9 Aug 2008 08:02:23 -0700 (PDT) > > > Hi, i was trying to work with all pass filters to reduce the phase shift from > filters. So i tried using the all pass from the cookbook formula, im not sure > exactly how to use it, but i had to invert the response (take the reciprocal > of the transfer function) to get it to be useful, that doesn't result in an unstable filter??? an APF has poles inside the unit circle and zeros outside. recipocating the transfer function would swap the poles and zeros. > here is what i did, first i > used a lowpass and then an allpass both using Q=0.707, which didnt seem to > help unless i move the frequency up an octave for the allpass, and then that > did reduce the phase for at least the passband part. Secondly, i tried using > a fourth order butterworth and then the allpass set to Q=0.707 again(but not > moving the frequency up an octave) and then it did really well in reducing > the phase shift. Thirdly, i tried using two second order > butterworth(essiently a linkwitz-riley) and then the allpass set to Q=0.707, > this actually equalized the phase back to zero, getting a constant group > delay across all frequencies. Is this the way to use the allpass? and > is there another way to set an allpass to get zero-phase using just a > second-order butterworth and the allpass? or even the fourth order and the > allpass? i don't have the book with me (Claude Lindquist's "Active Filter Design"), but he illustrates what this is about. what you want to look at is the group delay of both the LPF and the APF, which can be derived from the transfer functions. i think it comes out looking like the log-magnitude LPF response (of the APF denominator) but scaled. essentially, you have two parameters of the APF to play around with, the resonant frequency and the Q. i think the thing to do is set the Q to sqrt(0.5) or whatever makes the group delay maximally flat (the APF group delay looks like an LPF magnitude response with a "cutoff" region and a rounded corner). then you adjust the resonant frequency of the APF to slightly below the resonant frequency of the LPF so that the upward slope of that little "lip" in the LPF group delay is matched with the downward slope of the APF group delay. that gives you even more group delay (the sum of the LPF and APF delays) in the passband region and that nastly little bump in the LPF group delay is beaten down by the falling slope of the APF group delay. that's the best that i can recall from that book. i do not know of a perfectly analytical or optimal way to use an APF to fix the non-constant delay of an IIR filter. -- r b-j rbj@audioimagination.com "Imagination is more important than knowledge." From bogac at bteaudio.com Sat Aug 9 16:02:26 2008 From: bogac at bteaudio.com (Bogac Topaktas) Date: Sat Aug 9 16:02:47 2008 Subject: [music-dsp] All Pass Filters Message-ID: <92e8ae82ee818820523668d71794d08d@bteaudio.com> Hi Paul, Following papers contain all the relevant theory: "SELECTIVE LINEAR PHASE DIGITAL FILTERS: THEORY AND APPLICATION" by Ljiljana D. Milic and Miroslav D. Lutovac http://factaee.elfak.ni.ac.yu/facta9902/ilja10.html http://factaee.elfak.ni.ac.yu/facta9902/ilja10.pdf "DESIGN OF LINEAR PHASE IIR FILTERS VIA WEIGHTED LEAST-SQUARES APPROXIMATION" by Chengshan Xiao, Jan C. Olivier, Pan Agathoklis http://citeseerx.ist.psu.edu/viewdoc/summary?doi=10.1.1.3.9087 "On design techniques for approximately linear phase recursive digital filters" by Lawson, S.S. Circuits and Systems, 1997. ISCAS apos;97., Proceedings of 1997 IEEE International Symposium on Volume 4, Issue , 9-12 Jun 1997 Page(s):2212 - 2215 vol.4 bogac. -----Original message----- From: paul Fultz pfultz2@yahoo.com Date: Sat, 09 Aug 2008 07:02:46 -0700 To: music-dsp@music.columbia.edu Subject: [music-dsp] All Pass Filters > Hi, i was trying to work with all pass filters to reduce the phase shift from filters. So i tried using the all pass from the cookbook formula, im not sure exactly how to use it, but i had to invert the response(take the reciprocal of the transfer function) to get it to be useful, here is what i did, first i used a lowpass and then an allpass both using Q=0.707, which didnt seem to help unless i move the frequency up an octave for the allpass, and then that did reduce the phase for at least the passband part. Secondly, i tried using a fourth order butterworth and then the allpass set to Q=0.707 again(but not moving the frequency up an octave) and then it did really well in reducing the phase shift. Thirdly, i tried using two second order butterworth(essiently a linkwitz-riley) and then the allpass set to Q=0.707, this actually equalized the phase back to zero, getting a constant group delay across all frequencies. Is this the way to use the allpass? and > is there another way to set an allpass to get zero-phase using just a second-order butterworth and the allpass? or even the fourth order and the allpass? > thanks, > paul > > > > -- > dupswapdrop -- the music-dsp mailing list and website: > subscription info, FAQ, source code archive, list archive, book reviews, dsp links > http://music.columbia.edu/cmc/music-dsp > http://music.columbia.edu/mailman/listinfo/music-dsp From pfultz2 at yahoo.com Tue Aug 12 16:32:14 2008 From: pfultz2 at yahoo.com (paul Fultz) Date: Tue Aug 12 16:32:23 2008 Subject: [music-dsp] All Pass Filters In-Reply-To: <20080809191237.408D554D6B8@ws6-9.us4.outblaze.com> Message-ID: <843123.89263.qm@web90603.mail.mud.yahoo.com> yea, the filter is unstable when you invert the response, i hadnt realize that. Measuring the group delay, i can see how i can create a more constant group delay. thanks for the help. Does anyone know the math behind it to optimize this for the best response? also, how would i go about setting up the all pass for a corresponding peak eq? thanks, paul --- On Sat, 8/9/08, robert bristow-johnson wrote: > From: robert bristow-johnson > Subject: Re: [music-dsp] All Pass Filters > To: "A discussion list for music-related DSP" > Date: Saturday, August 9, 2008, 3:12 PM > > ----- Original Message ----- > > From: "paul Fultz" > > To: music-dsp@music.columbia.edu > > Subject: [music-dsp] All Pass Filters > > Date: Sat, 9 Aug 2008 08:02:23 -0700 (PDT) > > > > > > Hi, i was trying to work with all pass filters to > reduce the phase shift from > > filters. So i tried using the all pass from the > cookbook formula, im not sure > > exactly how to use it, but i had to invert the > response (take the reciprocal > > of the transfer function) to get it to be useful, > > > that doesn't result in an unstable filter??? an APF > has poles inside the unit circle and zeros outside. > recipocating the transfer function would swap the poles and > zeros. > > > here is what i did, first i > > used a lowpass and then an allpass both using Q=0.707, > which didnt seem to > > help unless i move the frequency up an octave for the > allpass, and then that > > did reduce the phase for at least the passband part. > Secondly, i tried using > > a fourth order butterworth and then the allpass set to > Q=0.707 again(but not > > moving the frequency up an octave) and then it did > really well in reducing > > the phase shift. Thirdly, i tried using two second > order > > butterworth(essiently a linkwitz-riley) and then the > allpass set to Q=0.707, > > this actually equalized the phase back to zero, > getting a constant group > > delay across all frequencies. Is this the way to use > the allpass? and > > is there another way to set an allpass to get > zero-phase using just a > > second-order butterworth and the allpass? or even the > fourth order and the > > allpass? > > i don't have the book with me (Claude Lindquist's > "Active Filter Design"), but he illustrates what > this is about. what you want to look at is the group delay > of both the LPF and the APF, which can be derived from the > transfer functions. i think it comes out looking like the > log-magnitude LPF response (of the APF denominator) but > scaled. > > essentially, you have two parameters of the APF to play > around with, the resonant frequency and the Q. i think the > thing to do is set the Q to sqrt(0.5) or whatever makes the > group delay maximally flat (the APF group delay looks like > an LPF magnitude response with a "cutoff" region > and a rounded corner). then you adjust the resonant > frequency of the APF to slightly below the resonant > frequency of the LPF so that the upward slope of that little > "lip" in the LPF group delay is matched with the > downward slope of the APF group delay. that gives you even > more group delay (the sum of the LPF and APF delays) in the > passband region and that nastly little bump in the LPF group > delay is beaten down by the falling slope of the APF group > delay. > > that's the best that i can recall from that book. i do > not know of a perfectly analytical or optimal way to use an > APF to fix the non-constant delay of an IIR filter. > > -- > > r b-j rbj@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 From stephen.blinkhorn at audiospillage.com Tue Aug 12 17:14:24 2008 From: stephen.blinkhorn at audiospillage.com (Stephen Blinkhorn) Date: Wed Aug 13 17:13:55 2008 Subject: [music-dsp] overdriving the DAC Message-ID: <845A0CB7-DA60-436A-8154-333CA491D2DB@audiospillage.com> hi, something I always wondered about is exactly what 'goes on' when you feed a really loud signal into a DAC? it's always sounded pretty nice to me, much nice than just doing hard clipping. sounds like i can hear some sort of filtering. just curious. stephen From douglas at music.columbia.edu Fri Aug 15 00:00:00 2008 From: douglas at music.columbia.edu (douglas repetto) Date: Fri Aug 15 00:00:09 2008 Subject: [music-dsp] [admin] music-dsp FAQ Message-ID: <20080815040000.CEFEF34494B0E@music.columbia.edu> Hi, Just a reminder that if you are new to the list you should read the music-dsp FAQ. It contains answers to both technical _and_ adminstrative questions that often come up on the list. If your question appears in the FAQ it is safe to assume that it has been discussed on the list many times in the past, and you should probably have a look through the list archives before posting your question to the list. http://music.columbia.edu/cmc/music-dsp/musicdspFAQ.html Also of interest to new and not-so-new list members: The music-dsp list archives http://music.columbia.edu/cmc/music-dsp/musicdsparchives.html The music-dsp source code archive http://www.musicdsp.org music-dsp books and reviews http://music.columbia.edu/cmc/music-dsp/dspbooks.html All this and more at: http://music.columbia.edu/cmc/music-dsp Hasta la pasta, douglas (this is an automated message sent out on the 1st and 15th of each month) From padawan12 at obiwannabe.co.uk Fri Aug 15 10:56:17 2008 From: padawan12 at obiwannabe.co.uk (Andy Farnell) Date: Fri Aug 15 10:56:22 2008 Subject: [music-dsp] overdriving the DAC In-Reply-To: <845A0CB7-DA60-436A-8154-333CA491D2DB@audiospillage.com> References: <845A0CB7-DA60-436A-8154-333CA491D2DB@audiospillage.com> Message-ID: <20080815155617.4481fae4.padawan12@obiwannabe.co.uk> I think this is an "it depends" situation. While they're generally quite similar there's a variety of soundcard designs with different oversampling systems, filters, DC traps. Overdriving one of my cheap machine's AC97 gets a lovely "warmed up", almost analogue distortion. Trying the same thing with the same software talking to a Creamware Pulsar produces the most horrible spiked digital distortion that sounds like something is about to break. On Tue, 12 Aug 2008 15:14:24 -0600 Stephen Blinkhorn wrote: > hi, > something I always wondered about is exactly what 'goes on' when you > feed a really loud signal into a DAC? it's always sounded pretty nice > to me, much nice than just doing hard clipping. sounds like i can > hear some sort of filtering. just curious. > > stephen > -- > dupswapdrop -- the music-dsp mailing list and website: > subscription info, FAQ, source code archive, list archive, book reviews, dsp links > http://music.columbia.edu/cmc/music-dsp > http://music.columbia.edu/mailman/listinfo/music-dsp -- Use the source From decoy at iki.fi Fri Aug 15 17:18:42 2008 From: decoy at iki.fi (Sampo Syreeni) Date: Fri Aug 15 17:18:58 2008 Subject: [music-dsp] overdriving the DAC In-Reply-To: <20080815155617.4481fae4.padawan12@obiwannabe.co.uk> References: <845A0CB7-DA60-436A-8154-333CA491D2DB@audiospillage.com> <20080815155617.4481fae4.padawan12@obiwannabe.co.uk> Message-ID: On 2008-08-15, Andy Farnell wrote: > I think this is an "it depends" situation. Hmm. Are we talking about DAC's or ADC's? In theory, you should not be able to overdrive a DAC even with full-scale digital inputs, whereas there is no comparable guarantee on the analog side of an ADC. Of course, that isn't the full picture. There are special, atypical signals that are guaranteed to kill the headroom in every DAC as well. (The prototype, if I recall it correctly, is the "..., +fs, -fs, +fs, +fs, -fs, +fs,..." one which yields an arbitrarily high reconstructed output spike in the ideal.) But with practical, and especially with musical signals (which tend to have a more or less random and Gaussian distribution thanks to reverb combined with the central limit theorem, except for the physical power constraint at the edges of the distribution, which then enables us to not clip at all), that more or less never happens. As such, if your DAC routinely clips with high level signals, there is something wrong with the design. Typically the analog output amplifiers or the stability of the delta-sigma architecture that was employed. If the question was then actually about ADC's, ask. I have a reasonably good picture of what happens there as well, but I'm also too tired to flesh it out right now. -- Sampo Syreeni, aka decoy - mailto:decoy@iki.fi, tel:+358-50-5756111 student/math+cs/helsinki university, http://www.iki.fi/~decoy/front openpgp: 050985C2/025E D175 ABE5 027C 9494 EEB0 E090 8BA9 0509 85C2 From stephen.blinkhorn at audiospillage.com Sat Aug 16 13:13:23 2008 From: stephen.blinkhorn at audiospillage.com (Stephen Blinkhorn) Date: Sat Aug 16 13:13:38 2008 Subject: [music-dsp] overdriving the DAC In-Reply-To: References: <845A0CB7-DA60-436A-8154-333CA491D2DB@audiospillage.com> <20080815155617.4481fae4.padawan12@obiwannabe.co.uk> Message-ID: <0DB76A6B-A3A5-4353-AA80-CC87650487F3@audiospillage.com> On 15 Aug 2008, at 15:18, Sampo Syreeni wrote: > On 2008-08-15, Andy Farnell wrote: > >> I think this is an "it depends" situation. > > Hmm. Are we talking about DAC's or ADC's? DACs > Of course, that isn't the full picture. There are special, atypical > signals that are guaranteed to kill the headroom in every DAC as > well. (The prototype, if I recall it correctly, is the "..., +fs, - > fs, +fs, +fs, -fs, +fs,..." one which yields an arbitrarily high > reconstructed output spike in the ideal.) But with practical, and > especially with musical signals (which tend to have a more or less > random and Gaussian distribution thanks to reverb combined with the > central limit theorem, except for the physical power constraint at > the edges of the distribution, which then enables us to not clip at > all), that more or less never happens Specifically I'm referring to the act of turning the gain up within software such that the resulting signal is unusually high and spends a lot of time well above full scale (if one can go above full scale of course). I do this sometimes with single drum hits or even a whole rhythm track or mix. Just for effect. I don't know if 'overdriving' is the right term really but it is reasonably descriptive. I'm interested as my attempts to implement similar hard clipping have so far sounded.. cacky handed you might say. > If the question was then actually about ADC's, ask. I have a > reasonably good picture of what happens there as well, but I'm also > too tired to flesh it out right now. From my experience there is a bigger difference in sound character between devices when coming the other way (overdriving ADC) and it seems like the better the sound card/sampler the nicer it sounds. I'm interested in that too. Stephen From john.lazzaro at gmail.com Sat Aug 16 14:35:32 2008 From: john.lazzaro at gmail.com (John Lazzaro) Date: Sat Aug 16 14:35:41 2008 Subject: [music-dsp] overdriving the DAC Message-ID: <302f570808161135t2065205csde664a3a7b5bcb0d@mail.gmail.com> > Stephen Blinkhorn wrote: >> something I always wondered about is exactly what 'goes on' when you >> feed a really loud signal into a DAC? it's always sounded pretty nice >> to me, much nice than just doing hard clipping. sounds like i can >> hear some sort of filtering. just curious. [I'm fairly sure my comment below is accurate, but there a lot of people on this list who know this lore better than I, so feel free to correct me, thanks.] Let's be concrete ... if we think of sending 16-bit sign-magnitude digital samples to a DAC, and map the most-positive number (0x7FFF) to a 1.0V analog output, it's important to realize that its possible to send a series of samples to the DAC such that a perfect reconstruction filter would generate an instantaneous analog voltage > 1.0V at some point in the waveform. What the DAC does for that case (especially if its power supply is at 1.0V, and thus it has no way to generate a > 1.0V signal) is one factor that goes into how the DAC sounds when you drive it with a series of samples near full scale. But not the only one. It's quite possible to design a DAC that will be non-ideal even for a series of samples that reconstruction <= 1.0V :-). When you are creating a file for distribution to be played on unknown audio hardware, to get predictable results its a good idea to normalize a little short of full-scale (-0.1 dB is a recommendation I've seen along these lines). But if what you're doing is overdriving your particular DAC to get an effect, which you then A/D back into your DAW to get a final track, then its all up to your ears. -- John Lazzaro http://www.cs.berkeley.edu/~lazzaro john [dot] lazzaro [at] gmail [dot] com From rob.belcham at zen.co.uk Fri Aug 22 07:50:39 2008 From: rob.belcham at zen.co.uk (Rob Belcham) Date: Fri Aug 22 07:50:59 2008 Subject: [music-dsp] Audio DSP Vacancy In-Reply-To: <003d01c8dd23$c97f34d0$6701a8c0@acer> References: <82b447220807021648s3dc23f8ej5334a050e3409ecd@mail.gmail.com> <003d01c8dd23$c97f34d0$6701a8c0@acer> Message-ID: <000001c9044d$4ca870b0$0201a8c0@stara> Hi All, We have a position vacant for a software engineer at a Pro-Audio company based in the Midlands (UK). We're looking for someone with experience of Analog Devices SHARC DSP & embedded C++ programming that also has an interest in music-dsp. Anyone who is interested and would like to find out more about the position should contact Paul Hodges at EPP Executive Search Ltd (paul.hodges@eppexec.com) Regards Rob From hans at fugal.net Fri Aug 22 18:21:42 2008 From: hans at fugal.net (Hans Fugal) Date: Fri Aug 22 18:22:10 2008 Subject: [music-dsp] modified Constant-Q Fast Filter Bank Message-ID: <48AF3BF6.6000809@fugal.net> I'm trying to follow and implement the modified Constant-Q Fast Filter Bank described in [1], but I'm getting lost in the math of the FFB. I follow the creation of the transfer function H_34(z) but I don't understand how to make the jump from that transfer function to the impulse response h_p. It seems to be taken for granted that one knows how to do that. Maybe it's something I should know but have forgotten. Also I'm not entirely clear where they get 256 for the number of points in the sDFT. Perhaps any N is fine, and it's just a tradeoff between resolution and computation time? In that case, is it always channel Q, e.g. channel 34 for quarter-tone resolution whether N = 256 or N = 1024? Thanks 1. http://www.lps.ufrj.br/profs/sergioln/papers/IC26.pdf 2. http://www.spsoc.ntu.edu.sg/limyc/CAS/1992_FFB.pdf -- Hans Fugal ; http://hans.fugal.net There's nothing remarkable about it. All one has to do is hit the right keys at the right time and the instrument plays itself. -- Johann Sebastian Bach From pericius at gmail.com Sat Aug 23 06:51:22 2008 From: pericius at gmail.com (Pericius) Date: Sat Aug 23 06:51:40 2008 Subject: [music-dsp] Beginning DSP Message-ID: <48AFEBAA.9060201@gmail.com> First, hello to all on music-dsp! I've been listening synthethic music for a while now and have some composing and playing experiences and I'd like to delve a little in sound synthesis and digital music creation. So, could anyone suggest a path to sound synthesis if I: - don't want to use third-party applications (but can live with libraries), - want to create sound from scratch (not using samples etc.), - want to do it in Python and/or C, - want to do it cross-platform? As I could dig out by myself, PortAudio could be the library of choice? If it is, where to from there? Thanks in advance! From gogins at pipeline.com Sat Aug 23 08:06:49 2008 From: gogins at pipeline.com (Michael Gogins) Date: Sat Aug 23 08:07:02 2008 Subject: [music-dsp] Beginning DSP Message-ID: <31073828.1219493209321.JavaMail.root@mswamui-blood.atl.sa.earthlink.net> Csound Sound processing language written in C with some C++, Python API Cmix Sound processing system written in Objective C, has its own scripting language Pure Data Data flow multimedia processing language written in C with some C++, Python externals SuperCollider Sound processing language written in C, Python API Open Sound World Data flow multimedia processing language written in C++ STK Sound processing class library written in C++ CLAM Sound processing class library written in C++ Create Signal Library (CSL) Sound processing class library written in C++ Synz (Lance Putnam, watch out for porno girls with same name) Sound processing class library written in C++, Lua API in Vessel SndObj Sound processing class library written in C++, Python API These are all free or open source, all cross platform, and most or all use PortAudio. They accept plugins or externals written in C (as far as I know), so are good homes for DSP experiments -- you don't have to create your own complete system in order to do some DSP programming. Myself, I use Csound. Another good alternative is to write VST plugins using STK or Synz or something like that, and use the plugins in one of the above systems or in a sequencer. Regards, Mike -----Original Message----- >From: Pericius >Sent: Aug 23, 2008 6:51 AM >To: music-dsp@music.columbia.edu >Subject: [music-dsp] Beginning DSP > >First, hello to all on music-dsp! > >I've been listening synthethic music for a while now and have some >composing and playing experiences and I'd like to delve a little in >sound synthesis and digital music creation. >So, could anyone suggest a path to sound synthesis if I: > - don't want to use third-party applications (but can live with >libraries), > - want to create sound from scratch (not using samples etc.), > - want to do it in Python and/or C, > - want to do it cross-platform? > >As I could dig out by myself, PortAudio could be the library of choice? >If it is, where to from there? > >Thanks in advance! >-- >dupswapdrop -- the music-dsp mailing list and website: >subscription info, FAQ, source code archive, list archive, book reviews, dsp links >http://music.columbia.edu/cmc/music-dsp >http://music.columbia.edu/mailman/listinfo/music-dsp From Victor.Lazzarini at nuim.ie Sat Aug 23 08:48:50 2008 From: Victor.Lazzarini at nuim.ie (victor) Date: Sat Aug 23 08:49:07 2008 Subject: [music-dsp] Beginning DSP References: <31073828.1219493209321.JavaMail.root@mswamui-blood.atl.sa.earthlink.net> Message-ID: <001a01c9051e$978d56f0$0201a8c0@family> Python API for SuperCollider? That is news to me. ----- Original Message ----- From: "Michael Gogins" To: "A discussion list for music-related DSP" Sent: Saturday, August 23, 2008 1:06 PM Subject: Re: [music-dsp] Beginning DSP > Csound > Sound processing language written in C with some C++, Python API > > Cmix > Sound processing system written in Objective C, has its own scripting > language > > Pure Data > Data flow multimedia processing language written in C with some C++, > Python externals > > SuperCollider > Sound processing language written in C, Python API > > Open Sound World > Data flow multimedia processing language written in C++ > > STK > Sound processing class library written in C++ > > CLAM > Sound processing class library written in C++ > > Create Signal Library (CSL) > Sound processing class library written in C++ > > Synz (Lance Putnam, watch out for porno girls with same name) > Sound processing class library written in C++, Lua API in Vessel > > SndObj > Sound processing class library written in C++, Python API > > These are all free or open source, all cross platform, and most or all use > PortAudio. > > They accept plugins or externals written in C (as far as I know), so are > good homes for DSP experiments -- you don't have to create your own > complete system in order to do some DSP programming. > > Myself, I use Csound. > > Another good alternative is to write VST plugins using STK or Synz or > something like that, and use the plugins in one of the above systems or in > a sequencer. > > Regards, > Mike > > > > -----Original Message----- >>From: Pericius >>Sent: Aug 23, 2008 6:51 AM >>To: music-dsp@music.columbia.edu >>Subject: [music-dsp] Beginning DSP >> >>First, hello to all on music-dsp! >> >>I've been listening synthethic music for a while now and have some >>composing and playing experiences and I'd like to delve a little in >>sound synthesis and digital music creation. >>So, could anyone suggest a path to sound synthesis if I: >> - don't want to use third-party applications (but can live with >>libraries), >> - want to create sound from scratch (not using samples etc.), >> - want to do it in Python and/or C, >> - want to do it cross-platform? >> >>As I could dig out by myself, PortAudio could be the library of choice? >>If it is, where to from there? >> >>Thanks in advance! >>-- >>dupswapdrop -- the music-dsp mailing list and website: >>subscription info, FAQ, 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 From k.s.matheussen at notam02.no Sat Aug 23 09:01:52 2008 From: k.s.matheussen at notam02.no (Kjetil S. Matheussen) Date: Sat Aug 23 09:02:09 2008 Subject: [music-dsp] Re: Beginning DSP In-Reply-To: <20080823124908.D0CCC35FF772A@music.columbia.edu> References: <20080823124908.D0CCC35FF772A@music.columbia.edu> Message-ID: victor: > Python API for SuperCollider? That is news to me. There might be very well be others, but here's one, sort of, tiny: http://pure-data.svn.sourceforge.net/viewvc/pure-data/trunk/externals/supercollider/python/supercollider.py?view=markup It was really made for using scheme to control supercollider via python running inside pd though... :D From renick at gmail.com Sat Aug 23 09:07:20 2008 From: renick at gmail.com (Renick Bell) Date: Sat Aug 23 09:07:33 2008 Subject: [music-dsp] Beginning DSP In-Reply-To: <001a01c9051e$978d56f0$0201a8c0@family> References: <31073828.1219493209321.JavaMail.root@mswamui-blood.atl.sa.earthlink.net> <001a01c9051e$978d56f0$0201a8c0@family> Message-ID: > Python API for SuperCollider? That is news to me. Python for SuperCollider http://www.ixi-audio.net/content/body_backyard_python.html Scheme for SuperCollider http://www.slavepianos.org/rd/f/306948/ Meaning to try both, but I don't have direct experience with either yet. -- Renick Bell http://the3rd2nd.com From Victor.Lazzarini at nuim.ie Sat Aug 23 11:26:24 2008 From: Victor.Lazzarini at nuim.ie (victor) Date: Sat Aug 23 11:26:36 2008 Subject: [music-dsp] Beginning DSP References: <31073828.1219493209321.JavaMail.root@mswamui-blood.atl.sa.earthlink.net> <001a01c9051e$978d56f0$0201a8c0@family> Message-ID: <001d01c90534$9ae1fe30$0201a8c0@family> Ah, it's just a means of sending OSC messages is it not? Not really an API as such (since SC3 is not a library). That was what confused me. Victor ----- Original Message ----- From: "Renick Bell" To: "A discussion list for music-related DSP" Sent: Saturday, August 23, 2008 2:07 PM Subject: Re: [music-dsp] Beginning DSP >> Python API for SuperCollider? That is news to me. > > Python for SuperCollider > > http://www.ixi-audio.net/content/body_backyard_python.html > > Scheme for SuperCollider > > http://www.slavepianos.org/rd/f/306948/ > > Meaning to try both, but I don't have direct experience with either yet. > > -- > Renick Bell > http://the3rd2nd.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 From martin.eisenberg at udo.edu Sat Aug 23 12:11:15 2008 From: martin.eisenberg at udo.edu (Martin Eisenberg) Date: Sat Aug 23 12:08:01 2008 Subject: [music-dsp] modified Constant-Q Fast Filter Bank References: <48AF3BF6.6000809@fugal.net> Message-ID: <000501c9053a$e26b61a0$0c01a8c0@Arbeitsgruppe> From: "Hans Fugal" > I'm trying to follow and implement the modified Constant-Q > Fast Filter Bank described in [1], but I'm getting lost in the > math of the FFB. I just took a look at the paper so might be mistaken, but... > I follow the creation of the transfer function H_34(z) but I don't > understand how to make the jump from that transfer function > to the impulse response h_p. All you need is the IRs of halfband filters G (in [1], H in [2]). And although they don't say I think those filters are meant to be FIR, so an IR would pop out of the design routine. See: http://groups.google.com/groups/search?num=50&q=group:comp.dsp+ha lfband+fir > Also I'm not entirely clear where they get 256 for the number > of points in the sDFT. Perhaps any N is fine, and it's just a > tradeoff between resolution and computation time? N comes from eq. (3). In Example 1, the samplerate is implicitly chosen to yield a value that satisfies (5). > In that case, is it always channel Q, e.g. channel 34 for > quarter-tone resolution whether N = 256 or N = 1024? Yes, because each CQT channel k is defined as bin Q of the N_k-long DFT, whatever N_k turns out to be. Martin From radarsat1 at gmail.com Sat Aug 23 13:28:03 2008 From: radarsat1 at gmail.com (Stephen Sinclair) Date: Sat Aug 23 13:28:17 2008 Subject: [music-dsp] programming languages for real-time audio Message-ID: <9b3e2dc20808231028i20f2bf0do4704af908057adfd@mail.gmail.com> Hello, Lately I've been wondering a lot about what programming languages are useful for real-time audio other than C/C++. I think the main reason we stick to these languages is the deterministic memory management and native code performance. However, many dynamic languages actually have quite well-optimized JIT compilers, so occasionally I have come across an application, for example, that uses Java for real-time audio synthesis. (Though not necessarily as efficiently as a C program might have done it, according to my CPU meter and the occasional underrun!) I often wonder which other dynamic languages might have the potential for real-time audio. So, I would like to ask 2 questions to the list: Have you used any languages other than C/C++ for real-time audio? If so, how did it go? Secondly, what benchmarks would be best for testing a language? If a language is able to synthesis a sine wave, for example, this doesn't necessarily mean it's able to do more complex synthesis, so what would make a good test case? I was thinking perhaps additive synthesis with some large number of oscillators, or similarly modal synthesis with N resonators. Perhaps there are more appropriate tasks, like FFT analysis/synthesis. Would it be necessary to test both vectorizable and non-vectorizable code? I'd like to compare imperative and functional languages, pre-compiled and JIT-compiled languages, bytecode vs. interpreted languages, different VMs (mono vs. java, vs. LLVM, vs. Parrot?), etc. If such a comparison has previously been done, I'd be interested in a link. Such comparisons are often done between languages, but it seems never with real-time audio processing in mind, which I think is indeed a special case. Steve From Victor.Lazzarini at nuim.ie Sat Aug 23 15:17:20 2008 From: Victor.Lazzarini at nuim.ie (victor) Date: Sat Aug 23 15:17:36 2008 Subject: [music-dsp] programming languages for real-time audio References: <9b3e2dc20808231028i20f2bf0do4704af908057adfd@mail.gmail.com> Message-ID: <002e01c90554$dd7d06c0$0201a8c0@family> I suppose we can use a scripting language, but that is cheating because all the critical code is C or C++ wrapped up. But if you are considering that case, I have used Python and Tcl for that purpose and there are plenty of Lisp examples around. Regards Victor ----- Original Message ----- From: "Stephen Sinclair" To: "A discussion list for music-related DSP" Sent: Saturday, August 23, 2008 6:28 PM Subject: [music-dsp] programming languages for real-time audio > Hello, > > Lately I've been wondering a lot about what programming languages are > useful for real-time audio other than C/C++. I think the main reason > we stick to these languages is the deterministic memory management and > native code performance. However, many dynamic languages actually > have quite well-optimized JIT compilers, so occasionally I have come > across an application, for example, that uses Java for real-time audio > synthesis. (Though not necessarily as efficiently as a C program > might have done it, according to my CPU meter and the occasional > underrun!) I often wonder which other dynamic languages might have > the potential for real-time audio. > > So, I would like to ask 2 questions to the list: > > Have you used any languages other than C/C++ for real-time audio? If > so, how did it go? > > Secondly, what benchmarks would be best for testing a language? If a > language is able to synthesis a sine wave, for example, this doesn't > necessarily mean it's able to do more complex synthesis, so what would > make a good test case? I was thinking perhaps additive synthesis with > some large number of oscillators, or similarly modal synthesis with N > resonators. Perhaps there are more appropriate tasks, like FFT > analysis/synthesis. Would it be necessary to test both vectorizable > and non-vectorizable code? > > I'd like to compare imperative and functional languages, pre-compiled > and JIT-compiled languages, bytecode vs. interpreted languages, > different VMs (mono vs. java, vs. LLVM, vs. Parrot?), etc. If such a > comparison has previously been done, I'd be interested in a link. > Such comparisons are often done between languages, but it seems never > with real-time audio processing in mind, which I think is indeed a > special case. > > > Steve > -- > dupswapdrop -- the music-dsp mailing list and website: > subscription info, FAQ, source code archive, list archive, book reviews, > dsp links > http://music.columbia.edu/cmc/music-dsp > http://music.columbia.edu/mailman/listinfo/music-dsp From gogins at pipeline.com Sat Aug 23 15:21:55 2008 From: gogins at pipeline.com (Michael Gogins) Date: Sat Aug 23 15:22:09 2008 Subject: [music-dsp] Beginning DSP Message-ID: <9932162.1219519315368.JavaMail.root@elwamui-polski.atl.sa.earthlink.net> SuperCollider on Windows. Regards, Mike -----Original Message----- >From: victor >Sent: Aug 23, 2008 8:48 AM >To: A discussion list for music-related DSP >Subject: Re: [music-dsp] Beginning DSP > >Python API for SuperCollider? That is news to me. >----- Original Message ----- >From: "Michael Gogins" >To: "A discussion list for music-related DSP" >Sent: Saturday, August 23, 2008 1:06 PM >Subject: Re: [music-dsp] Beginning DSP > > >> Csound >> Sound processing language written in C with some C++, Python API >> >> Cmix >> Sound processing system written in Objective C, has its own scripting >> language >> >> Pure Data >> Data flow multimedia processing language written in C with some C++, >> Python externals >> >> SuperCollider >> Sound processing language written in C, Python API >> >> Open Sound World >> Data flow multimedia processing language written in C++ >> >> STK >> Sound processing class library written in C++ >> >> CLAM >> Sound processing class library written in C++ >> >> Create Signal Library (CSL) >> Sound processing class library written in C++ >> >> Synz (Lance Putnam, watch out for porno girls with same name) >> Sound processing class library written in C++, Lua API in Vessel >> >> SndObj >> Sound processing class library written in C++, Python API >> >> These are all free or open source, all cross platform, and most or all use >> PortAudio. >> >> They accept plugins or externals written in C (as far as I know), so are >> good homes for DSP experiments -- you don't have to create your own >> complete system in order to do some DSP programming. >> >> Myself, I use Csound. >> >> Another good alternative is to write VST plugins using STK or Synz or >> something like that, and use the plugins in one of the above systems or in >> a sequencer. >> >> Regards, >> Mike >> >> >> >> -----Original Message----- >>>From: Pericius >>>Sent: Aug 23, 2008 6:51 AM >>>To: music-dsp@music.columbia.edu >>>Subject: [music-dsp] Beginning DSP >>> >>>First, hello to all on music-dsp! >>> >>>I've been listening synthethic music for a while now and have some >>>composing and playing experiences and I'd like to delve a little in >>>sound synthesis and digital music creation. >>>So, could anyone suggest a path to sound synthesis if I: >>> - don't want to use third-party applications (but can live with >>>libraries), >>> - want to create sound from scratch (not using samples etc.), >>> - want to do it in Python and/or C, >>> - want to do it cross-platform? >>> >>>As I could dig out by myself, PortAudio could be the library of choice? >>>If it is, where to from there? >>> >>>Thanks in advance! >>>-- >>>dupswapdrop -- the music-dsp mailing list and website: >>>subscription info, FAQ, 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 From gogins at pipeline.com Sat Aug 23 15:38:37 2008 From: gogins at pipeline.com (Michael Gogins) Date: Sat Aug 23 15:38:50 2008 Subject: [music-dsp] programming languages for real-time audio Message-ID: <13077381.1219520317328.JavaMail.root@elwamui-polski.atl.sa.earthlink.net> I have used Java and C++. I also am a Csound developer, which is its own language and is written almost all in C. My benchmarks were based on using the logistic equation to generate a score and then rendering the score with a frequency modulation instrument with an exponential envelope. This was re-implemented for each language. Csound was fastest because it could use blocks of samples (ksmps); Csound at 15 ksmps is about 3 times as fast as C++ at 1 ksmps. At 1 ksmp for both, C++ was faster than Csound by a little bit, and much faster than anything else. Forget Java or anything except C/C++ if you really, truly want speed. My own always on the back burner design for a state of the art software synthesis system (Silence) has now mutated. It used to be C++ unit generators wrapped in Python or Lua and processing equal blocks of samples (for what it's worth, C++ wrapped in Lua processing blocks of samples was as efficient as Csound). My design has now become all-C++ with a shell program that hides the C++ compiler from the user. This is based on realizing that's how snd-rt works -- the Stalin compiler turns scheme into really fast C code, which gcc compiles. I would use the same garbage collected memory manager that snd-rt uses because that would make it possible for novices to write music in C++. I would use the same scheduling algorithm that Vessel and VST hosts use: unit generators process blocks of samples, but the blocks can vary in size and any new control event always begins a new block of samples. That gives you better than Csound efficiency in processing, plus ChucK accuracy (also better than Csound) in scheduling, plus the most raw power of any sound processing language. In this system, the composer writes C++ using classes that simplify the language, and presses a button to compile, load, and run the generated code. No makefiles or build commands. I have done this previously using SAOL, a Csound successor, so I know it can work well. I think you can evaluate languages for music processing fairly by looking at benchmarks for linear algebra (vector arithmetic pretty much equivalent to DSP code) and streaming file access. For these benchmarks, C and C++ remain superior and I expect them to continue to be superior. Regards, Mike -----Original Message----- >From: Stephen Sinclair >Sent: Aug 23, 2008 1:28 PM >To: A discussion list for music-related DSP >Subject: [music-dsp] programming languages for real-time audio > >Hello, > >Lately I've been wondering a lot about what programming languages are >useful for real-time audio other than C/C++. I think the main reason >we stick to these languages is the deterministic memory management and >native code performance. However, many dynamic languages actually >have quite well-optimized JIT compilers, so occasionally I have come >across an application, for example, that uses Java for real-time audio >synthesis. (Though not necessarily as efficiently as a C program >might have done it, according to my CPU meter and the occasional >underrun!) I often wonder which other dynamic languages might have >the potential for real-time audio. > >So, I would like to ask 2 questions to the list: > >Have you used any languages other than C/C++ for real-time audio? If >so, how did it go? > >Secondly, what benchmarks would be best for testing a language? If a >language is able to synthesis a sine wave, for example, this doesn't >necessarily mean it's able to do more complex synthesis, so what would >make a good test case? I was thinking perhaps additive synthesis with >some large number of oscillators, or similarly modal synthesis with N >resonators. Perhaps there are more appropriate tasks, like FFT >analysis/synthesis. Would it be necessary to test both vectorizable >and non-vectorizable code? > >I'd like to compare imperative and functional languages, pre-compiled >and JIT-compiled languages, bytecode vs. interpreted languages, >different VMs (mono vs. java, vs. LLVM, vs. Parrot?), etc. If such a >comparison has previously been done, I'd be interested in a link. >Such comparisons are often done between languages, but it seems never >with real-time audio processing in mind, which I think is indeed a >special case. > > >Steve >-- >dupswapdrop -- the music-dsp mailing list and website: >subscription info, FAQ, source code archive, list archive, book reviews, dsp links >http://music.columbia.edu/cmc/music-dsp >http://music.columbia.edu/mailman/listinfo/music-dsp From bthrew at gmail.com Sat Aug 23 18:11:55 2008 From: bthrew at gmail.com (barry threw) Date: Sat Aug 23 18:12:31 2008 Subject: [music-dsp] programming languages for real-time audio In-Reply-To: <9b3e2dc20808231028i20f2bf0do4704af908057adfd@mail.gmail.com> References: <9b3e2dc20808231028i20f2bf0do4704af908057adfd@mail.gmail.com> Message-ID: <860667A7-7566-4042-B2B8-842B46274A9A@gmail.com> Supercollider is a good way to go. Powerful smalltalk based language, extendable in C, good sounding. bt On Aug 23, 2008, at 10:28 AM, Stephen Sinclair wrote: > Hello, > > Lately I've been wondering a lot about what programming languages are > useful for real-time audio other than C/C++. I think the main reason > we stick to these languages is the deterministic memory management and > native code performance. However, many dynamic languages actually > have quite well-optimized JIT compilers, so occasionally I have come > across an application, for example, that uses Java for real-time audio > synthesis. (Though not necessarily as efficiently as a C program > might have done it, according to my CPU meter and the occasional > underrun!) I often wonder which other dynamic languages might have > the potential for real-time audio. > > So, I would like to ask 2 questions to the list: > > Have you used any languages other than C/C++ for real-time audio? If > so, how did it go? > > Secondly, what benchmarks would be best for testing a language? If a > language is able to synthesis a sine wave, for example, this doesn't > necessarily mean it's able to do more complex synthesis, so what would > make a good test case? I was thinking perhaps additive synthesis with > some large number of oscillators, or similarly modal synthesis with N > resonators. Perhaps there are more appropriate tasks, like FFT > analysis/synthesis. Would it be necessary to test both vectorizable > and non-vectorizable code? > > I'd like to compare imperative and functional languages, pre-compiled > and JIT-compiled languages, bytecode vs. interpreted languages, > different VMs (mono vs. java, vs. LLVM, vs. Parrot?), etc. If such a > comparison has previously been done, I'd be interested in a link. > Such comparisons are often done between languages, but it seems never > with real-time audio processing in mind, which I think is indeed a > special case. > > > Steve > -- > dupswapdrop -- the music-dsp mailing list and website: > subscription info, FAQ, source code archive, list archive, book > reviews, dsp links > http://music.columbia.edu/cmc/music-dsp > http://music.columbia.edu/mailman/listinfo/music-dsp barry threw Media Art and Technology San Francisco, CA Work: 857-544-3967 Email: bthrew (at) gmail (dot) com Web: www.barrythrew.com From radarsat1 at gmail.com Sat Aug 23 18:14:21 2008 From: radarsat1 at gmail.com (Stephen Sinclair) Date: Sat Aug 23 18:14:34 2008 Subject: [music-dsp] programming languages for real-time audio In-Reply-To: <002e01c90554$dd7d06c0$0201a8c0@family> References: <9b3e2dc20808231028i20f2bf0do4704af908057adfd@mail.gmail.com> <002e01c90554$dd7d06c0$0201a8c0@family> Message-ID: <9b3e2dc20808231514j64bbfe9ek6cf05fa5f98b71ab@mail.gmail.com> Hi! On Sat, Aug 23, 2008 at 3:17 PM, victor wrote: > I suppose we can use a scripting language, but that is > cheating because all the critical code is C or C++ > wrapped up. But if you are considering that > case, I have used Python and Tcl for that purpose and > there are plenty of Lisp examples around. Thanks, I should have specified, I'm well aware of the paradigm for using scripting languages to "glue" blocks of C audio routines together, like in Pd, Chuck, or SuperCollider, for example, or some systems that use Python or Lisp to do it. But I'm interested in the current state of JIT languages for doing the actual time-critical computations. I know there are lots of audio-specific languages out there, but I'm more interested in general-purpose languages that can be used to build a whole system. Maybe it's a somewhat vague question, if so I apologize. Steve From k.s.matheussen at notam02.no Sat Aug 23 18:15:43 2008 From: k.s.matheussen at notam02.no (Kjetil S. Matheussen) Date: Sat Aug 23 18:16:04 2008 Subject: [music-dsp] Re: programming languages for real-time audio In-Reply-To: <20080823192219.CCF533618B17C@music.columbia.edu> References: <20080823192219.CCF533618B17C@music.columbia.edu> Message-ID: "Stephen Sinclair": > > Lately I've been wondering a lot about what programming languages are > useful for real-time audio other than C/C++. I think the main reason > we stick to these languages is the deterministic memory management and > native code performance. However, many dynamic languages actually > have quite well-optimized JIT compilers, so occasionally I have come > across an application, for example, that uses Java for real-time audio > synthesis. (Though not necessarily as efficiently as a C program > might have done it, according to my CPU meter and the occasional > underrun!) I often wonder which other dynamic languages might have > the potential for real-time audio. > Two systems comes to mind: Faust: http://faust.grame.fr snd-rt: http://www.notam02.no/arkiv/doc/snd-rt/ There's also saol, but I don't know whether it's still being developed... I'm going to demonstrate snd-rt on wednesday at the icmc conference, for those being there. Snd-rt also uses the rollendurchmesserzeitsammler garbage collector, which theoretically can make most programming languages able to do realtime DSP processing. Languages such as Clean, ML, Haskell and Common Lisp comes first to mind, but Java is another alternative. Michael Gogins: > I would use the same > scheduling algorithm that Vessel and VST hosts use: unit generators > process blocks of samples, but the blocks can vary > in size and any new control event always begins a new block of samples. > That gives you better than Csound efficiency in > processing, plus ChucK accuracy (also better than Csound) in scheduling, > plus the most raw power of any sound > processing language. > snd-rt actually does all this plus that it process individual samples so you don't have to write unit generators in C++. Perhaps writing a syntactic frontend to snd-rt would be an option? From Victor.Lazzarini at nuim.ie Sat Aug 23 18:21:29 2008 From: Victor.Lazzarini at nuim.ie (victor) Date: Sat Aug 23 18:21:48 2008 Subject: [music-dsp] programming languages for real-time audio References: <9b3e2dc20808231028i20f2bf0do4704af908057adfd@mail.gmail.com> <860667A7-7566-4042-B2B8-842B46274A9A@gmail.com> Message-ID: <001501c9056e$97774f90$0201a8c0@family> But again, this seems to miss the original post's point: SCLang is not used to implement RT audio. That is done by the server, a different software, written in C/C++. The language is just issuing OSC commands that control the server. Provided that you have an engine, any scripting language will do, but it is not doing the number crunching itself. Just about any Computer Music Language since MUSIC III will do audio at varying levels of efficiency. But they are just controlling synthesis engines that are written in some implementation language. I think Mike's reply was probably the bottom line: if you want speed and efficiency, it has to be C or C++ (or a similar compiled language). Java appears to be the alternative, but not as efficient. Victor ----- Original Message ----- From: "barry threw" To: "A discussion list for music-related DSP" Sent: Saturday, August 23, 2008 11:11 PM Subject: Re: [music-dsp] programming languages for real-time audio > Supercollider is a good way to go. Powerful smalltalk based language, > extendable in C, good sounding. > > bt > > > > On Aug 23, 2008, at 10:28 AM, Stephen Sinclair wrote: > >> Hello, >> >> Lately I've been wondering a lot about what programming languages are >> useful for real-time audio other than C/C++. I think the main reason >> we stick to these languages is the deterministic memory management and >> native code performance. However, many dynamic languages actually >> have quite well-optimized JIT compilers, so occasionally I have come >> across an application, for example, that uses Java for real-time audio >> synthesis. (Though not necessarily as efficiently as a C program >> might have done it, according to my CPU meter and the occasional >> underrun!) I often wonder which other dynamic languages might have >> the potential for real-time audio. >> >> So, I would like to ask 2 questions to the list: >> >> Have you used any languages other than C/C++ for real-time audio? If >> so, how did it go? >> >> Secondly, what benchmarks would be best for testing a language? If a >> language is able to synthesis a sine wave, for example, this doesn't >> necessarily mean it's able to do more complex synthesis, so what would >> make a good test case? I was thinking perhaps additive synthesis with >> some large number of oscillators, or similarly modal synthesis with N >> resonators. Perhaps there are more appropriate tasks, like FFT >> analysis/synthesis. Would it be necessary to test both vectorizable >> and non-vectorizable code? >> >> I'd like to compare imperative and functional languages, pre-compiled >> and JIT-compiled languages, bytecode vs. interpreted languages, >> different VMs (mono vs. java, vs. LLVM, vs. Parrot?), etc. If such a >> comparison has previously been done, I'd be interested in a link. >> Such comparisons are often done between languages, but it seems never >> with real-time audio processing in mind, which I think is indeed a >> special case. >> >> >> Steve >> -- >> dupswapdrop -- the music-dsp mailing list and website: >> subscription info, FAQ, source code archive, list archive, book reviews, >> dsp links >> http://music.columbia.edu/cmc/music-dsp >> http://music.columbia.edu/mailman/listinfo/music-dsp > > > > barry threw > Media Art and Technology > > San Francisco, CA > Work: 857-544-3967 > Email: bthrew (at) gmail (dot) com > Web: www.barrythrew.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 From Victor.Lazzarini at nuim.ie Sat Aug 23 18:28:43 2008 From: Victor.Lazzarini at nuim.ie (victor) Date: Sat Aug 23 18:28:55 2008 Subject: [music-dsp] Re: programming languages for real-time audio References: <20080823192219.CCF533618B17C@music.columbia.edu> Message-ID: <004701c9056f$9a5af210$0201a8c0@family> But then snd-rt is a bit like all other Music Prog Languages, which can process individual samples too (eg. I can build a custom filter in Csound just using arithmetic operators and maths functions). FAUST also does not process code itself, but compiles to a variety of outputs. None of these fit the bill (as far as I can understand Stephen's post). Victor ----- Original Message ----- From: "Kjetil S. Matheussen" To: Sent: Saturday, August 23, 2008 11:15 PM Subject: [music-dsp] Re: programming languages for real-time audio > > "Stephen Sinclair": >> >> Lately I've been wondering a lot about what programming languages are >> useful for real-time audio other than C/C++. I think the main reason >> we stick to these languages is the deterministic memory management and >> native code performance. However, many dynamic languages actually >> have quite well-optimized JIT compilers, so occasionally I have come >> across an application, for example, that uses Java for real-time audio >> synthesis. (Though not necessarily as efficiently as a C program >> might have done it, according to my CPU meter and the occasional >> underrun!) I often wonder which other dynamic languages might have >> the potential for real-time audio. >> > > Two systems comes to mind: > > Faust: http://faust.grame.fr > snd-rt: http://www.notam02.no/arkiv/doc/snd-rt/ > > There's also saol, but I don't know whether it's > still being developed... > > I'm going to demonstrate snd-rt on wednesday at the > icmc conference, for those being there. > > Snd-rt also uses the rollendurchmesserzeitsammler > garbage collector, which theoretically can make most > programming languages able to do realtime DSP > processing. Languages such as Clean, ML, Haskell > and Common Lisp comes first to mind, but Java > is another alternative. > > > Michael Gogins: >> I would use the same >> scheduling algorithm that Vessel and VST hosts use: unit generators >> process blocks of samples, but the blocks can vary >> in size and any new control event always begins a new block of samples. >> That gives you better than Csound efficiency in >> processing, plus ChucK accuracy (also better than Csound) in scheduling, >> plus the most raw power of any sound >> processing language. >> > > snd-rt actually does all this plus that it process individual > samples so you don't have to write unit generators in C++. > Perhaps writing a syntactic frontend to snd-rt > would be an option? > -- > dupswapdrop -- the music-dsp mailing list and website: subscription info, > FAQ, source code archive, list archive, book reviews, dsp links > http://music.columbia.edu/cmc/music-dsp > http://music.columbia.edu/mailman/listinfo/music-dsp From Victor.Lazzarini at nuim.ie Sat Aug 23 18:34:56 2008 From: Victor.Lazzarini at nuim.ie (victor) Date: Sat Aug 23 18:35:10 2008 Subject: [music-dsp] Re: programming languages for real-time audio References: <20080823192219.CCF533618B17C@music.columbia.edu> Message-ID: <007001c90570$78918ad0$0201a8c0@family> We seem to be in the same session. It'd be nice to meet you there. Victor > I'm going to demonstrate snd-rt on wednesday at the > icmc conference, for those being there. > From radarsat1 at gmail.com Sat Aug 23 18:42:19 2008 From: radarsat1 at gmail.com (Stephen Sinclair) Date: Sat Aug 23 18:42:45 2008 Subject: [music-dsp] programming languages for real-time audio In-Reply-To: <001501c9056e$97774f90$0201a8c0@family> References: <9b3e2dc20808231028i20f2bf0do4704af908057adfd@mail.gmail.com> <860667A7-7566-4042-B2B8-842B46274A9A@gmail.com> <001501c9056e$97774f90$0201a8c0@family> Message-ID: <9b3e2dc20808231542h2aa9c13w1c5e7fc11184f9a1@mail.gmail.com> On Sat, Aug 23, 2008 at 6:21 PM, victor wrote: > > I think Mike's reply was probably the bottom line: if you want speed > and efficiency, it has to be C or C++ (or a similar compiled language). > Java appears to be the alternative, but not as efficient. Of course, I'll grudgingly accept the status quo that C or C++ is the only real answer here. For what it's worth, though I've had this question for a while, this line of thinking was yet again spawned in my head by the recent news about the Mozilla JavaScript optimizations that claim around 10x improvement, and that the final goal is to have it run "as fast as C code." And then there's the (endlessly debatable) claims in the last 5 years or so that Java is now just as fast as C. (If I understand JIT, the important sections of code should get compiled to native machine code that executes at much faster speed than the interpreted code... this seems pretty ideal to me if the compiler can be convinced to JIT the entire audio routine.) So, if real-time audio is mainly just about speed, I'd really like to be able to take advantage of these dynamic languages for building audio systems. (I'm not really a big fan of Java but it's just an example.) It's not, of course; it's also about memory management, deterministic timing, and I/O latency, etc. But perhaps it's *mainly* about raw speed---calculating that buffer in less time than is required to play it. Anyways, my point remains that all the debate over which language is best, which somehow I find myself reading even though it always goes around in circles, always skips the important issue of whether they are suitable for real-time. It seems an accepted truth that we'll never be able to use anything but C/C++ in this domain, but I can't help but find myself jealous of application developers who get to express themselves in these different languages. Maybe domain-specific languages like Csound and FAUST are the best way to go after all. In any case, I'd still like to know how to go about evaluating different languages for audio processing. I guess if an additive synth can be built with, say, 50 oscillators going we could say that that language is audio-friendly. Bindings to ALSA or other audio back-end might need to be built in C, of course, if they're not already available. Steve From john.lazzaro at gmail.com Sat Aug 23 18:50:40 2008 From: john.lazzaro at gmail.com (John Lazzaro) Date: Sat Aug 23 18:50:55 2008 Subject: [music-dsp] Re: programming languages for real-time audio Message-ID: <302f570808231550o36763d6ewb2db54ba1b5ebd9a@mail.gmail.com> > From: "Kjetil S. Matheussen" > There's also saol, but I don't know whether it's > still being developed... There hasn't been an sfront release in a few years, mostly because the sfront-related project I'm working on at the moment (adding Apple AudioUnit support) isn't the sort of change that has a good incremental release point. Hopefully by the end of 2008 it will be ready, but that may be a bit optimistic. Meanwhile, you can pick up the last release here: http://www.eecs.berkeley.edu/~lazzaro/sa/sfman/user/install/index.html#download And more generally, learn more about SAOl and sfront there: http://www.eecs.berkeley.edu/~lazzaro/sa/index.html -- John Lazzaro http://www.cs.berkeley.edu/~lazzaro john [dot] lazzaro [at] gmail [dot] com From k.s.matheussen at notam02.no Sat Aug 23 18:55:19 2008 From: k.s.matheussen at notam02.no (Kjetil S. Matheussen) Date: Sat Aug 23 18:55:43 2008 Subject: [music-dsp] Re: programming languages for real-time audio In-Reply-To: <20080823224245.A7F1436243424@music.columbia.edu> References: <20080823224245.A7F1436243424@music.columbia.edu> Message-ID: victor: > > But then snd-rt is a bit like all other Music Prog Languages, > which can process individual samples too (eg. I can build a > custom filter in Csound just using arithmetic operators and > maths functions). FAUST also does not process code itself, but compiles > to a variety of outputs. None of these fit the bill (as far > as I can understand Stephen's post). > I'm not quite what you mean, but I think snd-rt fits Stephen's bill exactly. One of the languages it supports is Stalin, which is an R4RS scheme compiler, originally not made for realtime use, but made to do so when running inside the snd-rt environment. Stalin is also very fast, and beats C code in some benchmarks, but I would be surprised if it beats Faust for dsp operations, although I haven't benchmarked anything yet. > > We seem to be in the same session. It'd be nice to meet you > there. > Yes, lets try to do that. But now I really have to pack my stuff. :-) Up early tomorrow.. From magnus at rubidium.dyndns.org Sat Aug 23 19:00:49 2008 From: magnus at rubidium.dyndns.org (Magnus Danielson) Date: Sat Aug 23 19:01:14 2008 Subject: [music-dsp] Re: programming languages for real-time audio In-Reply-To: References: <20080823192219.CCF533618B17C@music.columbia.edu> Message-ID: <48B096A1.8090503@rubidium.dyndns.org> > Snd-rt also uses the rollendurchmesserzeitsammler > garbage collector, which theoretically can make most > programming languages able to do realtime DSP > processing. Languages such as Clean, ML, Haskell > and Common Lisp comes first to mind, but Java > is another alternative. Shouldn't a real time programming language be free of a garbage collector? I helped a friend design a vector feature into his real-time programming enviornment. Precise collection was possible while still maintaining a usefull grammar. You don't want to debug pointer errors and such during a gig. You don't want unpredictable time during a gig. Both was achievabel. Cheers, Magnus From lanceboyle at qwest.net Sat Aug 23 20:43:06 2008 From: lanceboyle at qwest.net (Jerry) Date: Sat Aug 23 20:43:45 2008 Subject: [music-dsp] programming languages for real-time audio In-Reply-To: <9b3e2dc20808231028i20f2bf0do4704af908057adfd@mail.gmail.com> References: <9b3e2dc20808231028i20f2bf0do4704af908057adfd@mail.gmail.com> Message-ID: On Aug 23, 2008, at 10:28 AM, Stephen Sinclair wrote: > Have you used any languages other than C/C++ for real-time audio? If > so, how did it go? I appreciate your question about using other languages, as appropriate. I'm all for having a bunch of languages in one's toolbox to pull out at the right time for the right job. It seems to me that pretty much any compiled language that has a mature compiler should be about as good as any other compiled language, generally speaking. C and C++ can make a reasonable benchmark for speed but mainly because they are popular. I personally do most of my general-purpose programming in Ada on OS X using the excellent and free GNAT compiler which is part of gcc. Ada is similar to C in speed, depending of course on the actual programs being compared. (For example, its object-oriented code tends to run faster than most because, due to its typing requirements, there is no late --read runtime-- binding.) But if you do such a comparison, be sure to compare apples to apples by e.g. turning off array boundary checking and range checking on variables since C doesn't do any of this. Ada's memory management should also be quite predictable. Garbage collection is allowed but rarely implemented as being nearly unnecessary since the memory for Ada objects (Ada uses "objects" more in the everyday sense rather than the OOP sense) is released automatically when the object goes out of scope. The only time that I know of that memory must be explicitly released is if an object has been dynamically allocated with a pointer, a situation which in Ada is rather rare to the point of being a pretty obscure practice. A down side to using Ada is that to access libraries written in C or C ++, one has to either find or write bindings to those libraries. Thanks to the fact that Ada contains extensive facilities to do just that (plus Fortran and Cobol, if you're so inclined), that task is surprisingly easy in most cases. (I have personally written Ada bindings to the PLplot library.) I haven't written any realtime audio processing in Ada but there's no reason other than I haven't had the need to do so yet. I'm not sure why Stephan asks about using non-C/C++ languages, but if it stems from a distaste for C, then he might find Ada a breath of fresh air. Even people who use Ada for only a little while say that it improves their coding practices in other languages. Sorry if this sounds a bit too much like a soapbox speech. Jerry From radarsat1 at gmail.com Sat Aug 23 21:03:17 2008 From: radarsat1 at gmail.com (Stephen Sinclair) Date: Sat Aug 23 21:04:12 2008 Subject: [music-dsp] programming languages for real-time audio In-Reply-To: References: <9b3e2dc20808231028i20f2bf0do4704af908057adfd@mail.gmail.com> Message-ID: <9b3e2dc20808231803k195af023v46ae559dffa3789f@mail.gmail.com> On Sat, Aug 23, 2008 at 8:43 PM, Jerry wrote: > On Aug 23, 2008, at 10:28 AM, Stephen Sinclair wrote: > >> Have you used any languages other than C/C++ for real-time audio? If >> so, how did it go? > > I appreciate your question about using other languages, as appropriate. I'm > all for having a bunch of languages in one's toolbox to pull out at the > right time for the right job. > > It seems to me that pretty much any compiled language that has a mature > compiler should be about as good as any other compiled language, generally > speaking. > > C and C++ can make a reasonable benchmark for speed but mainly because they > are popular. I guess that sums up the basis for my question reasonably well. C is the standard because it allows very low-level memory management and runtime behaviour is very easy to predict. But it seems like every new language that comes out these days makes use of VM technology or uses a lot of run-time memory allocation, and not many people are really designing new languages for use in real-time or embedded environments because C is "good enough" and well-understood. And maybe this is an adequate answer, actually, but I thought it would be fun to discuss the issue nonetheless. > I personally do most of my general-purpose programming in Ada on OS X using > the excellent and free GNAT compiler which is part of gcc. Ada is similar to > C in speed, depending of course on the actual programs being compared. (For > example, its object-oriented code tends to run faster than most because, due > to its typing requirements, there is no late --read runtime-- binding.) But > if you do such a comparison, be sure to compare apples to apples by e.g. > turning off array boundary checking and range checking on variables since C > doesn't do any of this. > > Ada's memory management should also be quite predictable. Garbage collection > is allowed but rarely implemented as being nearly unnecessary since the > memory for Ada objects (Ada uses "objects" more in the everyday sense rather > than the OOP sense) is released automatically when the object goes out of > scope. The only time that I know of that memory must be explicitly released > is if an object has been dynamically allocated with a pointer, a situation > which in Ada is rather rare to the point of being a pretty obscure practice. > > A down side to using Ada is that to access libraries written in C or C++, > one has to either find or write bindings to those libraries. Thanks to the > fact that Ada contains extensive facilities to do just that (plus Fortran > and Cobol, if you're so inclined), that task is surprisingly easy in most > cases. (I have personally written Ada bindings to the PLplot library.) Well, the bindings issue will be there for any language not typically used for audio, so I may have to learn how to write bindings for several languages. Hopefully it won't be a huge issue, because all I need to do is basically read an array and feed it to the audio hardware. (Though now that I think about it, callback vs. blocking implementations of audio processing might be a problem in some languages.) > I haven't written any realtime audio processing in Ada but there's no reason > other than I haven't had the need to do so yet. > > I'm not sure why Stephan asks about using non-C/C++ languages, but if it > stems from a distaste for C, then he might find Ada a breath of fresh air. > Even people who use Ada for only a little while say that it improves their > coding practices in other languages. It's not so much a distaste for C, though perhaps it's verging on a distaste for C++ that I've been accumulating lately. I like C a lot actually. But sometimes object-oriented or higher-level programming is just needed, and in those cases it seems like C++ is the only solution if you want to interact with the same object system in your audio callback. But I'm getting tired of C++, so in those situations where I need OO, I'm trying to see if there are other languages I could use. Also, more generally, I'm just curious, seeing today's fertile development community which seems to spring up a new language every 2 weeks, (some of which I find very nice), whether any dynamic languages have achieved the kind of speed necessary to integrate an audio callback efficiently. It seems to me it shouldn't be entirely necessary for us to just accept that C is the only way to go for real-time work. Of _course_ the question isn't black & white either. There are lots of languages that compile to C, for example-- but what the generated C code does still might not be the most efficient for audio, so I think the question is still valid for these. In any case, maybe I oughtta shut up and just go do some benchmarks.. ;-) > Sorry if this sounds a bit too much like a soapbox speech. No problem, it's exactly what I asked for. I'll take a closer look at Ada, thanks. I haven't really used it at all, but have known about it for quite a while. Never considered it for audio, but I'll definitely read up on it. Steve From gogins at pipeline.com Sat Aug 23 22:08:56 2008 From: gogins at pipeline.com (Michael Gogins) Date: Sat Aug 23 22:09:17 2008 Subject: [music-dsp] Re: programming languages for real-time audio Message-ID: <1655944.1219543736542.JavaMail.root@elwamui-huard.atl.sa.earthlink.net> Thanks for your responses. Stephen: In reality, most software sound synthesis systems are an uneasy mix of layers. Csound, Supercollider, Pure Data and Max, and most others of which I know actually end up running a signal flow graph of unit generators written in C or C++. That's as true of Supercollider or Max as it is of Csound. But the snd-rt approach, and my suggested approach, are similar in actually using the same language for all layers. Kjetil: First, let me see if I understand how snd-rt works. The musician writes Scheme code. He or she can declare special blocks of real-time statements. These blocks are compiled using the Stalin compiler into highly optimized C code that uses your real-time safe garbage collector. Thus, semantically the musician is writing both the high-level composition and the low-level DSP operations, including unit generators, in Scheme. But inside the system, that optimized C code is still compiled by the GNU C compiler into object code. Please correct me if I've misunderstood... So, in ALL of these systems, the running unit generators are C or C++ code. If that's correct, my point is, why not just stick with C++ and have that compiled inside the system? Of course functional programming offers certain advantages, but staying in C++, which is immensely powerful and has the widest selection of libraries, has its own large advantages. Regards, Mike ----- Original Message ----- From: "Kjetil S. Matheussen" To: Sent: Saturday, August 23, 2008 6:15 PM Subject: [music-dsp] Re: programming languages for real-time audio > > "Stephen Sinclair": >> >> Lately I've been wondering a lot about what programming languages are >> useful for real-time audio other than C/C++. I think the main reason >> we stick to these languages is the deterministic memory management and >> native code performance. However, many dynamic languages actually >> have quite well-optimized JIT compilers, so occasionally I have come >> across an application, for example, that uses Java for real-time audio >> synthesis. (Though not necessarily as efficiently as a C program >> might have done it, according to my CPU meter and the occasional >> underrun!) I often wonder which other dynamic languages might have >> the potential for real-time audio. >> > > Two systems comes to mind: > > Faust: http://faust.grame.fr > snd-rt: http://www.notam02.no/arkiv/doc/snd-rt/ > > There's also saol, but I don't know whether it's > still being developed... > > I'm going to demonstrate snd-rt on wednesday at the > icmc conference, for those being there. > > Snd-rt also uses the rollendurchmesserzeitsammler > garbage collector, which theoretically can make most > programming languages able to do realtime DSP > processing. Languages such as Clean, ML, Haskell > and Common Lisp comes first to mind, but Java > is another alternative. > > > Michael Gogins: >> I would use the same >> scheduling algorithm that Vessel and VST hosts use: unit generators >> process blocks of samples, but the blocks can vary >> in size and any new control event always begins a new block of samples. >> That gives you better than Csound efficiency in >> processing, plus ChucK accuracy (also better than Csound) in scheduling, >> plus the most raw power of any sound >> processing language. >> > > snd-rt actually does all this plus that it process individual > samples so you don't have to write unit generators in C++. > Perhaps writing a syntactic frontend to snd-rt > would be an option? > -- > dupswapdrop -- the music-dsp mailing list and website: > subscription info, FAQ, source code archive, list archive, book reviews, dsp links > http://music.columbia.edu/cmc/music-dsp > http://music.columbia.edu/mailman/listinfo/music-dsp From julian_schmidt at chipmusik.de Sun Aug 24 05:13:09 2008 From: julian_schmidt at chipmusik.de (julian Schmidt) Date: Sun Aug 24 05:13:25 2008 Subject: [music-dsp] help with AVR ASM simple resonant RC-Filter Message-ID: <48B12625.8040100@chipmusik.de> hello, i started learning asm and try some DSP stuff on an Atmega644 got some really nice SAW and PWM sounds out of it. but i'm struggeling with the filter I tried to implement a simple resonant RC filter: a += f * ((in - a) + q * (a - b)); b += f * (a - b); the both poles work like a charm as long as i don't add resonance... as soon as i turn up Q i get horrible clipping. I tried scaling down the coeffs by adding gain like this: gain = 0.5; a += f * ((in*gain - a) + q * (a*gain - b)); b += f * (a*gain - b); but to no effect :-/ here is my ASM source with comments... any ideas what i did wrong? because i'm quite an ASM noob. http://chipmusik.de/lp.txt thanks for any hints! julian From lists at grahamwakefield.net Sun Aug 24 11:47:54 2008 From: lists at grahamwakefield.net (Graham Wakefield) Date: Sun Aug 24 11:48:23 2008 Subject: [music-dsp] programming languages for real-time audio In-Reply-To: <9b3e2dc20808231803k195af023v46ae559dffa3789f@mail.gmail.com> References: <9b3e2dc20808231028i20f2bf0do4704af908057adfd@mail.gmail.com> <9b3e2dc20808231803k195af023v46ae559dffa3789f@mail.gmail.com> Message-ID: <453B9BE5-2061-4C05-BA81-E4F14274A6F2@grahamwakefield.net> On Aug 23, 2008, at 6:03 PM, Stephen Sinclair wrote: > On Sat, Aug 23, 2008 at 8:43 PM, Jerry wrote: >> On Aug 23, 2008, at 10:28 AM, Stephen Sinclair wrote: >>> >> It seems to me that pretty much any compiled language that has a >> mature >> compiler should be about as good as any other compiled language, >> generally >> speaking. >> >> C and C++ can make a reasonable benchmark for speed but mainly >> because they >> are popular. > > I guess that sums up the basis for my question reasonably well. C is > the standard because it allows very low-level memory management and > runtime behaviour is very easy to predict. > It's not so much a distaste for C, though perhaps it's verging on a > distaste for C++ that I've been accumulating lately. I like C a lot > actually. But sometimes object-oriented or higher-level programming > is just needed, and in those cases it seems like C++ is the only > solution if you want to interact with the same object system in your > audio callback. But I'm getting tired of C++, so in those situations > where I need OO, I'm trying to see if there are other languages I > could use. D & Objective-C spring to mind. I've looked at D a few times as a potentially more attractive option than C++ for a higher-level kind of C. The gdc compiler should output code just as efficient as C++, AFAICT, but the learning curve that it would impose upon anybody wishing to extend what I'm working on basically put me off. The overwhelming majority of audio code appears to be C or C++, which is a lot of inertia to push against for very little gain. Objective-C is another similar option; and can link with C/C++ code easily, but perhaps not sufficiently different to warrant the effort. I think that's the key point. What about C/C++ is not working well for DSP? I guess C/C++ were not designed with multi-threading or task-parallelism in mind, that's certainly something that a 'better' language could overcome. DSP in Erlang, anyone? Well, there's Intel's TBB, and there's Apple's OpenCL that both look promising (remains to be seen whether this is feasible in a low-latency situation). I guess the other point is the programming interface - maybe a higher level approach, or a more flexibly dynamic one, is desirable from a developer's (or API user's ) standpoint? > > Also, more generally, I'm just curious, seeing today's fertile > development community which seems to spring up a new language every 2 > weeks, (some of which I find very nice), whether any dynamic languages > have achieved the kind of speed necessary to integrate an audio > callback efficiently. It seems to me it shouldn't be entirely > necessary for us to just accept that C is the only way to go for > real-time work. I tried it with Lua, arguably one of the fastest interpreted languages, but for DSP it's really not feasible. About a ten-fold increase in cpu... I also tried with LuaJIT, which compiles to native rather than VM bytecode, and that was more feasible. But- the language really wasn't designed for the kind of math DSP needs... to actually build from scratch the math for a band-limited multi-table oscillator in a language like Lua (or JS, Ruby, Python etc) would be crazy. As an aside, I'm often jealous of the 3D graphics people. They have dedicated hardware in everybody's computers for doing exactly the kind of math they need, very fast, with almost no contention from the OS, and they have a handful of more-or-less open standards for doing this work. We, on the other hand, have black box hardware, and must use (share) general purpose CPUs with (aging) general purpose languages and almost no standards. I mean, nobody should have to write yet another phase accumulating oscillator... it should be in the hardware! Why don't we have audio cards with APUs with standardized programming interfaces? Or, better still, why don't graphics cards also have APUs? g From lists at grahamwakefield.net Sun Aug 24 12:04:07 2008 From: lists at grahamwakefield.net (Graham Wakefield) Date: Sun Aug 24 12:04:23 2008 Subject: [music-dsp] Re: programming languages for real-time audio In-Reply-To: <48B096A1.8090503@rubidium.dyndns.org> References: <20080823192219.CCF533618B17C@music.columbia.edu> <48B096A1.8090503@rubidium.dyndns.org> Message-ID: <6B140B08-D782-4F24-93A0-C04A566977C7@grahamwakefield.net> On Aug 23, 2008, at 4:00 PM, Magnus Danielson wrote: > >> Snd-rt also uses the rollendurchmesserzeitsammler >> garbage collector, which theoretically can make most >> programming languages able to do realtime DSP >> processing. Languages such as Clean, ML, Haskell >> and Common Lisp comes first to mind, but Java >> is another alternative. > > Shouldn't a real time programming language be free of a garbage > collector? Only if the garbage collector implies unpredictable timing. The rollendurchmesserzeitsammler was specifically written to overcome this. > I helped a friend design a vector feature into his real-time > programming enviornment. Precise collection was possible while > still maintaining a usefull grammar. Sounds interesting - could you describe it further? > You don't want to debug pointer errors and such during a gig. You > don't want unpredictable time during a gig. Both was achievabel. > > Cheers, > Magnus > -- > dupswapdrop -- the music-dsp mailing list and website: subscription > info, FAQ, source code archive, list archive, book reviews, dsp > links http://music.columbia.edu/cmc/music-dsp http:// > music.columbia.edu/mailman/listinfo/music-dsp From julian_schmidt at chipmusik.de Sun Aug 24 17:47:00 2008 From: julian_schmidt at chipmusik.de (julian Schmidt) Date: Sun Aug 24 17:46:52 2008 Subject: [music-dsp] help with AVR ASM simple resonant RC-Filter In-Reply-To: <48B12625.8040100@chipmusik.de> References: <48B12625.8040100@chipmusik.de> Message-ID: <48B1D6D4.4070704@chipmusik.de> problem solved over at KVR http://www.kvraudio.com/forum/viewtopic.php?p=3210821#3210821 i had forgotten to hardclipp now the filter resonates good :) http://chipmusik.de/filter_limit.mp3 fm+filtered saw demo http://chipmusik.de/fm.mp3 so long, julian julian Schmidt schrieb: > hello, > > i started learning asm and try some DSP stuff on an Atmega644 > got some really nice SAW and PWM sounds out of it. > but i'm struggeling with the filter > > I tried to implement a simple resonant RC filter: > a += f * ((in - a) + q * (a - b)); > b += f * (a - b); > the both poles work like a charm as long as i don't add resonance... > as soon as i turn up Q i get horrible clipping. > I tried scaling down the coeffs by adding gain like this: > gain = 0.5; > a += f * ((in*gain - a) + q * (a*gain - b)); > b += f * (a*gain - b); > but to no effect :-/ > > here is my ASM source with comments... > any ideas what i did wrong? because i'm quite an ASM noob. > http://chipmusik.de/lp.txt > > thanks for any hints! > julian > -- > dupswapdrop -- the music-dsp mailing list and website: subscription > info, FAQ, source code archive, list archive, book reviews, dsp links > http://music.columbia.edu/cmc/music-dsp > http://music.columbia.edu/mailman/listinfo/music-dsp > From k.s.matheussen at notam02.no Mon Aug 25 07:14:42 2008 From: k.s.matheussen at notam02.no (Kjetil Svalastog Matheussen ) Date: Mon Aug 25 07:14:58 2008 Subject: [music-dsp] (no subject) Message-ID: <3355.143.117.143.210.1219662882.squirrel@webmail.uio.no> > From: Magnus Danielson > Subject: Re: [music-dsp] Re: programming languages for real-time audio > To: A discussion list for music-related DSP > > Message-ID: <48B096A1.8090503@rubidium.dyndns.org> > Content-Type: text/plain; charset=ISO-8859-1; format=flowed > > >> Snd-rt also uses the rollendurchmesserzeitsammler >> garbage collector, which theoretically can make most >> programming languages able to do realtime DSP >> processing. Languages such as Clean, ML, Haskell >> and Common Lisp comes first to mind, but Java >> is another alternative. > > Shouldn't a real time programming language be free of a garbage collector? Not allways. There exist a few ways to make garbage collectors realtime safe. The way rollendurchmesserzeitsammler works is to collect garbage in a separate thread. This is probably the best way to make the garbage collector realtime safe when doing signal processing, because of the increased performance. It does waste quite a bit of memory though. From jamie at postlude.co.uk Sun Aug 31 05:21:16 2008 From: jamie at postlude.co.uk (Jamie Bullock) Date: Sun Aug 31 05:21:31 2008 Subject: [music-dsp] programming languages for real-time audio In-Reply-To: <9b3e2dc20808231028i20f2bf0do4704af908057adfd@mail.gmail.com> References: <9b3e2dc20808231028i20f2bf0do4704af908057adfd@mail.gmail.com> Message-ID: <1220174476.11291.2.camel@aluminium> Hi Stephen, On Sat, 2008-08-23 at 13:28 -0400, Stephen Sinclair wrote: > Lately I've been wondering a lot about what programming languages are > useful for real-time audio other than C/C++. I think the main reason > we stick to these languages is the deterministic memory management and > native code performance. However, many dynamic languages actually > have quite well-optimized JIT compilers, so occasionally I have come > across an application, for example, that uses Java for real-time audio > synthesis. (Though not necessarily as efficiently as a C program > might have done it, according to my CPU meter and the occasional > underrun!) I often wonder which other dynamic languages might have > the potential for real-time audio. I don't really know very much about Erlang, so this may be way off the mark, but this came up today and may be of relevance: http://lambda-the-ultimate.org/node/2954 Jamie -- www.postlude.co.uk http://www.linkedin.com/in/jamiebullock From julian_schmidt at chipmusik.de Sun Aug 31 05:23:31 2008 From: julian_schmidt at chipmusik.de (julian Schmidt) Date: Sun Aug 31 05:23:45 2008 Subject: Your AVR project ([music-dsp] help with AVR ASM simple resonant RC-Filter) In-Reply-To: References: <48B12625.8040100@chipmusik.de> <48B1D6D4.4070704@chipmusik.de> <48B87CA7.9060806@chipmusik.de> Message-ID: <48BA6313.7050105@chipmusik.de> other projects i know of are jareks avr synth - http://www.elby-designs.com/avrsynth/avrsyn-about.htm swinsid - http://www.swinkels.tvtom.pl/swinsid/ hardware chptune project - http://www.linusakesson.net/hardware/chiptune.php and yes, i mixed c and asm, the control chip is written in C, the soundchip in ASM have fun, julian Magnus Eriksson schrieb: > On Sat, 30 Aug 2008, julian Schmidt wrote: > >> there wasn't >> but you inspired me to set up a primitive blog ;) >> http://blog.chipmusik.de/ > > Haha, great. :-) > > I'll go take a look. *Tomorrow*. > > >> I'm quite new to AVRs as well. This is my 1st AVR project and my >> second uC project. I just did some blinkenlights stuff on an PIC >> before, coded with a C compiler. Glad you like it. if you have any >> questions just ask. > > Oh, cool. So this project is mixed C and asm, I guess? (Actually, > nevermind. I should look at the blog first..) > > > Take care, > MAgnus >