Re: [music-dsp] confirm 29f9d07aca460a7584879c1831b9e3298c4
Perhaps it would be as well for the unsubscribe function on the list management page to be parked behind a password, rather than accessible without? At the moment, anyone can do this kind of drive-by unsubscription of anyone whose email address they have, without even going to the trouble of spoofing that email address - just type it into the webpage and click twice. Hiding it behind a password would at least make it a little bit more difficult. -- gwenhwyfaer On 28/07/2016, Stefan Stenzel <stefan.sten...@waldorfmusic.de> wrote: > Robert is the gist of this list, he can rant, spam and complain as he > pleases, his mails are either very informative or funny, mostly both. > > You, Bruno, have not contributed anything besides your recent oeuvre which > is neither related to music nor suitable to sustain the considerate way we > use to communicate here. > > Stefan > > >> On 28 Jul 2016, at 1:39 , Bruno Afonso <bafo...@gmail.com> wrote: >> >> Could you please stop spamming the list? Much appreciated >> >> On Wed, Jul 27, 2016 at 16:09 robert bristow-johnson >> <r...@audioimagination.com> wrote: >> sorry, i just ain't getting the hint. >> >> i'm sorta dense that way. >> >> >> >> Original Message >> >> Subject: confirm 29f9d07aca460a7584879c1831b9e3298c4 >> From: music-dsp-requ...@music.columbia.edu >> Date: Wed, July 27, 2016 10:37 am >> To: r...@audioimagination.com >> -- >> >> > Mailing list removal confirmation notice for mailing list music-dsp >> > >> > We have received a request for the removal of your email address, >> > "r...@audioimagination.com" from the music-dsp@music.columbia.edu >> > mailing list. To confirm that you want to be removed from this >> > mailing list, simply reply to this message, keeping the Subject: >> > header intact. Or visit this web page: >> > >> > https://lists.columbia.edu/mailman/confirm/music-dsp/29f9d07aca460a7584879c1831b9e3298c4 >> > >> > >> > Or include the following line -- and only the following line -- in a >> > message to music-dsp-requ...@music.columbia.edu: >> > >> > confirm 29f9d07aca460a7584879c1831b9e3298c4 >> > >> > Note that simply sending a `reply' to this message should work from >> > most mail readers, since that usually leaves the Subject: line in the >> > right form (additional "Re:" text in the Subject: is okay). >> > >> > If you do not wish to be removed from this list, please simply >> > disregard this message. If you think you are being maliciously >> > removed from the list, or have any other questions, send them to >> > music-dsp-ow...@music.columbia.edu. >> > >> > >> >> >> -- >> >> >> >> r b-j r...@audioimagination.com >> >> >> >> "Imagination is more important than knowledge." >> >> ___ >> dupswapdrop: music-dsp mailing list >> music-dsp@music.columbia.edu >> https://lists.columbia.edu/mailman/listinfo/music-dsp >> ___ >> dupswapdrop: music-dsp mailing list >> music-dsp@music.columbia.edu >> https://lists.columbia.edu/mailman/listinfo/music-dsp > > ___ > dupswapdrop: music-dsp mailing list > music-dsp@music.columbia.edu > https://lists.columbia.edu/mailman/listinfo/music-dsp > > ___ dupswapdrop: music-dsp mailing list music-dsp@music.columbia.edu https://lists.columbia.edu/mailman/listinfo/music-dsp
Re: [music-dsp] Did anybody here think about signal integrity
Well, bandlimited to a bandwidth fs/2 (but the distinction isn't useful for audio), and given perfect reconstruction circuitry. But as far as I can gather, Theo's concern is what happens when, as is inevitable in practice, the reconstruction circuitry is imperfect? And that is an interesting question, academically speaking, if there really isn't a body of theory to cover reconstructive imperfection - if only to be certain that all the improvements made to DAC technology in the last three decades have actually been _improvements_. But I think all of this is probably covered by existing research anyway. Minimising phase disruption in digital filters is well understood; LSB errors and resistor chain nonlinearities are fairly obvious, sources of relatively predictable badness, and can be assessed in the same way as nonlinearity in general; clock jitter is easy to simulate... and then there are analogue reconstruction filters. Unless I've missed any, I don't think there's anything else to look at, unless he wants to disprove or augment Nyquist-Shannon. Which would be an achievement, true, but... I would humbly submit that there might be more fruitful avenues towards seeing Verelst theorem in the indices of 22nd-century audio textbooks. Still, I understand great white whales all too well; and if Theo _needs_ to harpoon this one, we should perhaps not stand in his way. On 05/06/2015, Stefan Stenzel stefan.sten...@waldorfmusic.de wrote: Theo, Any continuous function bandlimited to frequencies fs/2 is completely determined by its samples. That’s the essence of the sampling theorem, which answers all your questions. Stefan On 03 Jun 2015, at 22:47 , Theo Verelst theo...@theover.org wrote: Hi, Playing with analog and digital processing, I came to the conclusion I'd like to contemplate about certain digital signal processing considerations, I'm sure have been in the minds of pioneering people quite a while ago, concerning let's say how accurate theoretically and practically all kinds of basic DSP subjects really are. For instance, I care about what happens with a perfect sine wave getting either digitized or mathematically and with an accurate computer program put into a sequence of signal samples. When a close to perfect sample (in the sense of a list of signal samples) gets played over a Digital to Analog Converter, how perfect is the analog signal getting out of there? And if it isn't all perfect, where are the errors? As a very crude thinking example, suppose a square wave oscillator like in a synthesizer or an electronic circuit test generator is creating a near perfect square wave, and it is also digitized or an attempt is made in software to somehow turn the two voltages of the square wave into samples. Maybe a more reasonable idea is to take into account what a DAC will do with the signal represented in the samples that are taken as music, speech, a musical instrument's tones, or sound effects. For instance, what does the digital reconstruction window and the build in oversampling make of a exponential curve (like the part of an envelope could easily be) with it's given (usually FIR) filter length. In that context, you could wonder what happens if we shift a given exponential signal (or signal component) by half a sample ? Add to the consideration that a function a*exp(b*x+c) defines a unique function for each a,b and c. Anyone here think and/or work on these kinds of subjects, I'd like to hear. (I think it's an interesting subject, so I'm serious about it) T. Verelst -- dupswapdrop -- the music-dsp mailing list and website: subscription info, FAQ, source code archive, list archive, book reviews, dsp links http://music.columbia.edu/cmc/music-dsp http://music.columbia.edu/mailman/listinfo/music-dsp -- dupswapdrop -- the music-dsp mailing list and website: subscription info, FAQ, source code archive, list archive, book reviews, dsp links http://music.columbia.edu/cmc/music-dsp http://music.columbia.edu/mailman/listinfo/music-dsp -- dupswapdrop -- the music-dsp mailing list and website: subscription info, FAQ, source code archive, list archive, book reviews, dsp links http://music.columbia.edu/cmc/music-dsp http://music.columbia.edu/mailman/listinfo/music-dsp
Re: [music-dsp] Dither video and articles
On 12/02/2015, gwenhwyfaer gwenhwyf...@gmail.com wrote: On 11/02/2015, Andrew Simper a...@cytomic.com replied to me: ... I made 7 sawtooth waves with random (static) phases and one straightforward sawtooth wave, with all partials in phase. I just listened to it again, to check my memory. On a half-decent pair of headphones, the difference between the all-partials-in-phase sawtooth and the random-phase ones is readily audible, but it was rather harder to tell the difference between the various random-phase waves; they all kind of sounded pulse-wavey. On a pair of speakers through the same amp and soundcard, though, I can still *jst about* pick out the in-phase sawtooth - but I couldn't confidently tell the difference between the 7 other waves. Which I'm guessing has something to do with the difference between the fairly one-dimensional travel of sound from headphone to ear, vs the bouncing-in-from-all-kinds-of-directions speaker-ear journey. Have you considered that headphones don't have crossovers? Nope. Good point. Indeed, it does seem to be a bit easier to pick out the in-phase sawtooth on the hideous tinny laptop piezo-buzzers I've got in front of me... but I'm not randomising the order of them or anything, and I really should be doing that, so interpret my report as subject to confirmation bias. Crest factor? I can't easily find out, but a visual inspection shows that all the waves are hitting one rail or the other. Which makes me think I normalised each wave individually, which means I introduced RMS differences as a means of distinguishing them... OK, forget I said anything. *pipes down* -- dupswapdrop -- the music-dsp mailing list and website: subscription info, FAQ, source code archive, list archive, book reviews, dsp links http://music.columbia.edu/cmc/music-dsp http://music.columbia.edu/mailman/listinfo/music-dsp
Re: [music-dsp] Dither video and articles
On 11/02/2015, Andrew Simper a...@cytomic.com replied to me: ... I made 7 sawtooth waves with random (static) phases and one straightforward sawtooth wave, with all partials in phase. I just listened to it again, to check my memory. On a half-decent pair of headphones, the difference between the all-partials-in-phase sawtooth and the random-phase ones is readily audible, but it was rather harder to tell the difference between the various random-phase waves; they all kind of sounded pulse-wavey. On a pair of speakers through the same amp and soundcard, though, I can still *jst about* pick out the in-phase sawtooth - but I couldn't confidently tell the difference between the 7 other waves. Which I'm guessing has something to do with the difference between the fairly one-dimensional travel of sound from headphone to ear, vs the bouncing-in-from-all-kinds-of-directions speaker-ear journey. Have you considered that headphones don't have crossovers? Nope. Good point. -- dupswapdrop -- the music-dsp mailing list and website: subscription info, FAQ, source code archive, list archive, book reviews, dsp links http://music.columbia.edu/cmc/music-dsp http://music.columbia.edu/mailman/listinfo/music-dsp
Re: [music-dsp] Dither video and articles
On 10/02/2015, Didier Dambrin di...@skynet.be wrote: Pretty easy to check the obvious difference between a pure low sawtooth, and the same sawtooth with all partials starting at random phases. Ah, this again? Good times. I remember playing. I made 7 sawtooth waves with random (static) phases and one straightforward sawtooth wave, with all partials in phase. I just listened to it again, to check my memory. On a half-decent pair of headphones, the difference between the all-partials-in-phase sawtooth and the random-phase ones is readily audible, but it was rather harder to tell the difference between the various random-phase waves; they all kind of sounded pulse-wavey. On a pair of speakers through the same amp and soundcard, though, I can still *jst about* pick out the in-phase sawtooth - but I couldn't confidently tell the difference between the 7 other waves. Which I'm guessing has something to do with the difference between the fairly one-dimensional travel of sound from headphone to ear, vs the bouncing-in-from-all-kinds-of-directions speaker-ear journey. I'm only a data point, though, so I'm not brave enough to actually conclude anything. At least, not any more. ;) -- dupswapdrop -- the music-dsp mailing list and website: subscription info, FAQ, source code archive, list archive, book reviews, dsp links http://music.columbia.edu/cmc/music-dsp http://music.columbia.edu/mailman/listinfo/music-dsp
Re: [music-dsp] 14-bit MIDI controls, how should we do Coarse and Fine?
Well, from the synth's point of view, it may receive controller messages from multiple controllers, but it seems a safe assumption that any controller will either send only MSBs, or will send LSBs interspersed with the occasional MSB. So how about this? While a synth only receives MSBs for a given controller, it sets the LSB to the same as the MSB; however, as soon as an LSB is received for a synth, it notes that the controller has entered 14-bit mode, and when it receives an MSB, then depending on the previous value of the MSB, it either resets the LSB to 0 (if the MSB has increased) or 0x7F (it it's decreased). That'll solve the specific glitching problem Robert's highlighting. And two MSBs sent in succession should be enough to switch the controller back to 7-bit mode. What new problems will this raise that haven't occurred to me? -- dupswapdrop -- the music-dsp mailing list and website: subscription info, FAQ, source code archive, list archive, book reviews, dsp links http://music.columbia.edu/cmc/music-dsp http://music.columbia.edu/mailman/listinfo/music-dsp
Re: [music-dsp] 14-bit MIDI controls, how should we do Coarse and Fine?
On 06/02/2015, gwenhwyfaer gwenhwyf...@gmail.com wrote: LSB to the same as the MSB; however, as soon as an LSB is received for a synth*, it notes that the controller has entered 14-bit mode, and *for a CONTROLLER. Must learn to proofread better. -- dupswapdrop -- the music-dsp mailing list and website: subscription info, FAQ, source code archive, list archive, book reviews, dsp links http://music.columbia.edu/cmc/music-dsp http://music.columbia.edu/mailman/listinfo/music-dsp
Re: [music-dsp] R: Sallen Key with sin only coefficient computation
On 24/12/2014, Nigel Redmon earle...@earlevel.com wrote: Naw, mhos is a one-off. It's fun, pronounceable, and in common use (since 1883!). Don't get carried away. Besides, it makes me think of The Three Stooges, and smile. Which in turn makes me wonder what would be measured in curlhis or lharris? -- dupswapdrop -- the music-dsp mailing list and website: subscription info, FAQ, source code archive, list archive, book reviews, dsp links http://music.columbia.edu/cmc/music-dsp http://music.columbia.edu/mailman/listinfo/music-dsp
Re: [music-dsp] R: Introducing: Axoloti
On 09/12/2014, Johannes Taelman johannes.tael...@gmail.com wrote: With all the questions about ports: is there anything wrong with the Axoloti hardware as I plan (besides not being available currently)? I think you might have answered your own question there... However, if it runs on a platform as cheaply and readily available as the STM32F4Discovery (I've got one sat around doing nothing), I'd say you've done due diligence as far as giving people something to run right now is concerned. The only thing I would suggest is that maybe it's worth making the Discovery the default platform until your hardware is ready, if it's easy to do. Take it as a compliment. People are interested in playing with your software even before your hardware is ready and showing it off. Nice going. :) -- dupswapdrop -- the music-dsp mailing list and website: subscription info, FAQ, source code archive, list archive, book reviews, dsp links http://music.columbia.edu/cmc/music-dsp http://music.columbia.edu/mailman/listinfo/music-dsp
Re: [music-dsp] FFT and harmonic distortion (short note)
On 08/12/2014, robert bristow-johnson r...@audioimagination.com wrote: it's about 2. Windowing (and the effects thereof) and the 3. Periodic extension inherent to the DFT (and the effects thereof). That's the key, it seems to me. Theo saw a sawtooth whose cycle length doesn't match the FFT width, and complained that the spectrum looked wrong. I saw a hard sync'd sawtooth wave of matching cycle length, and apparently so did the FFT, because the spectrum looks just right for that. Duckrabbit. -- dupswapdrop -- the music-dsp mailing list and website: subscription info, FAQ, source code archive, list archive, book reviews, dsp links http://music.columbia.edu/cmc/music-dsp http://music.columbia.edu/mailman/listinfo/music-dsp
Re: [music-dsp] FFT and harmonic distortion (short note)
On 08/12/2014, Jerry lancebo...@qwest.net wrote: I think the OP is a bit of a beginner and that the usual generous response of this list would be helpful. That's, um, not how Theo represents himself. -- dupswapdrop -- the music-dsp mailing list and website: subscription info, FAQ, source code archive, list archive, book reviews, dsp links http://music.columbia.edu/cmc/music-dsp http://music.columbia.edu/mailman/listinfo/music-dsp
Re: [music-dsp] Some DSP with a dsPIC33F
Sounds nifty! I read suggestions that the internal DAC was quite noisy, but it doesn't sound that way. Have you found that there are certain things you need to avoid to make it acceptably quiet, or is it just OK in practice? On 13/10/2014, Scott Gravenhorst music.ma...@gte.net wrote: Ethan Duni wrote: Sounds like a fun project Scott. One question though: Sample rate is approximately 44.6 kHz. What's with the non-standard sampling rate? E The delta-sigma DAC is internal to the dsPIC IC and it's clock is derived from the CPU clock. Unfortunately, when clocking at max, the available sample rates are not standard. I used a 20 MHz external crystal for the CPU clock which allows the CPU to run at it's maximum clock of (internally PLL generated) 160 MHz yielding 40 MIPS performance. -- dupswapdrop -- the music-dsp mailing list and website: subscription info, FAQ, source code archive, list archive, book reviews, dsp links http://music.columbia.edu/cmc/music-dsp http://music.columbia.edu/mailman/listinfo/music-dsp -- dupswapdrop -- the music-dsp mailing list and website: subscription info, FAQ, source code archive, list archive, book reviews, dsp links http://music.columbia.edu/cmc/music-dsp http://music.columbia.edu/mailman/listinfo/music-dsp
Re: [music-dsp] Nyquista?Shannon sampling theorem
On 27/03/2014, Doug Houghton doug_hough...@sympatico.ca wrote: consider this from a wiki page A bandlimited signal can be fully reconstructed from its samples, provided that the sampling rate exceeds twice the maximum frequency in the bandlimited signal. Actually twice the *bandwidth*. In music the distinction isn't terribly important, because the lower limit of the bandwidth is about 20Hz; other applications may find it more useful. -- dupswapdrop -- the music-dsp mailing list and website: subscription info, FAQ, source code archive, list archive, book reviews, dsp links http://music.columbia.edu/cmc/music-dsp http://music.columbia.edu/mailman/listinfo/music-dsp
Re: [music-dsp] Best way to do sine hard sync?
On 26/02/2014, Risto Holopainen rist...@hotmail.com wrote: When it comes to programming hard sync, I would use oversampling. I'm not saying that you should, I'm just lazy enough to do it the easy way. You need to oversample a *lot* to chase away aliasing, though. The Alesis Fusion - and its descendant, the M-Audio Venom, does the same - does hard sync naively, by resetting the slave oscillator's phase to 0 every time the master crosses from negative to positive... only it doesn't oversample at all and does the comparison on sample boundaries, with the result that hard sync sounds *lousy* on the Fusion. I've done a couple of experiments which appear to suggest that the aliasing caused by this is *far* worse than that caused by not bandlimiting the actual discontinuity - for example, by using a hidden master oscillator (actually a fractional multiplier of the phase counter) to read from a wavetable corrected only to the frequency of the slave. In fact, you can bandlimit the discontinuity as much as you please, and it'll *still* sound awful, because you're essentially randomising the pitch of the oscillator. Worse, even if your slave is running at exactly the same frequency as its master, you'll STILL get random glitches in the sound as its phase is reset to exactly 0 when the master's phase is some tiny fraction greater than 0. And the sad thing is, there's no justification for it. In the Venom, for example, you're always syncing to oscillator 1 - which means that you know the frequency ratio between the two oscillators. Moreover, you're syncing against a known waveform - which means you also know when exactly that waveform will cross from negative to positive. Therefore, when your slave detects that it did, rather than resetting itself to 0, it can reset itself to the difference between the actual phase of the master and the phase at which the master would have crossed 0, multiplied by the slave:master frequency ratio. For sawtooth and pulse waves, of course, that's particularly simple - there's only one zero-crossing per cycle, and if you make sure that zero-crossing is always at the point where the phase is 0, you can use the carry of the master's phase accumulator to detect sync, then multiply the master's current phase by the slave:master ratio and set the slave's phase to that. And lo! - no more random-frequency-wibbling alias. *Then* you can start worrying about how to bandlimit the slave's phase. Sorry for going on at length about something that is surely obvious to everyone else here (I know nowt about owt) but it really bugs me - and clearly it wasn't obvious to Alesis when they designed the Fusion. And in fairness, the Fusion could sync to itss noise generator or an arbitrary signal coming into the audio inputs (can any other VA do this? Nord Modular, perhaps?) at which point the naive approach is the best you can do without either intepolating between input samples (which needs division) or upping the input sample rate - but even so, 99% of the time the Fusion is still syncing to another oscillator whose frequency and waveform it necessarily knows. And there's just no excuse for the Venom. *spent and tremulous, returns to hiding under desk* -- dupswapdrop -- the music-dsp mailing list and website: subscription info, FAQ, source code archive, list archive, book reviews, dsp links http://music.columbia.edu/cmc/music-dsp http://music.columbia.edu/mailman/listinfo/music-dsp
Re: [music-dsp] Best way to do sine hard sync?
bandlimit the slave's phase - bandlimit the slave's output. oops. and I do know how to spell interpolation, honest. -- dupswapdrop -- the music-dsp mailing list and website: subscription info, FAQ, source code archive, list archive, book reviews, dsp links http://music.columbia.edu/cmc/music-dsp http://music.columbia.edu/mailman/listinfo/music-dsp
Re: [music-dsp] Best way to do sine hard sync?
On 26/02/2014, Risto Holopainen rist...@hotmail.com wrote: Now, for my part, I find soft sync much more useful. I don't know what attempts there have been to do soft sync in digital oscillators, if anyone knows I'd be interested. Nobody agrees on whether soft sync is knock the waveform into reverse (the Alesis Ion did that, and within the limitations of Alesis' sync implementation generally it did sound interesting) or only sync if the slave is within a threshold, which is what your samples sound like (I don't know if any synth does that). But you'd think both would be easy (once you've conquered the bandlimiting problem) on a phase-accumulator based synth: the first example negates the phase increment on sync; and the second only resets the slave's phase if it's lower than the threshold (where both are fractions), so turn the threshold up to 100% and it becomes hard sync. But both require master and slave to have independent phase accumulators, and as rbj mentions it's much easier in digital land to simply derive the slave's phase straight from the master's. -- dupswapdrop -- the music-dsp mailing list and website: subscription info, FAQ, source code archive, list archive, book reviews, dsp links http://music.columbia.edu/cmc/music-dsp http://music.columbia.edu/mailman/listinfo/music-dsp
Re: [music-dsp] family of soft clipping functions.
On 03/11/2013, robert bristow-johnson r...@audioimagination.com wrote: the point is that if you upsample, then soft-clip, then LPF, and finally downsample back to the original sample rate, you need only prevent the aliases from getting back into your *original* baseband. it doesn't matter that *some* of the images have folded over and become non-harmonic aliases, just as long as they do not survive into the final output. i don't know how better to explain it, without a drawing. Oh, hang on, I think I get it. So an nth-order polynomial expands the spectrum produced by n times. Let's say a 3rd-order poly turns a bandwidth of 22kHz into one of 66kHz. What you're saying is that you only need to upsample a 44.1kHz signal by 2, do the shaping, and run a low pass at the original 22kHz - because whilst everything above 44.1kHz will fold back, it'll only fold back down to frequencies above 22.3kHz and leave your original 0-22kHz bandwidth alone, right? (But, say, a 4th-order poly would require upsampling by more than 2, otherwise it'd produce harmonics up to 88kHz, which would fold back into your desired bandwidth.) Have I understood properly? -- dupswapdrop -- the music-dsp mailing list and website: subscription info, FAQ, source code archive, list archive, book reviews, dsp links http://music.columbia.edu/cmc/music-dsp http://music.columbia.edu/mailman/listinfo/music-dsp
Re: [music-dsp] [admin] Re: note onset detection
I can see the above binary, which implies that attaching a pretty explanatory image can be done without resorting to HTML (just not in line). So I'll say no HTML too. (I use gmail myself, but I use it on a text-based browser. I also occasionally use mailx to access gmail.) What sort of email programs are people using that can't handle html? Useful ones. Too useful for anyone to be grumbling about ticking one checkbox. -- dupswapdrop -- the music-dsp mailing list and website: subscription info, FAQ, source code archive, list archive, book reviews, dsp links http://music.columbia.edu/cmc/music-dsp http://music.columbia.edu/mailman/listinfo/music-dsp
Re: [music-dsp] need help with gnuplot and octave on my mac.
On 26/10/2012, robert bristow-johnson r...@audioimagination.com wrote:
say, any among you using a Mac and Octave and gnuplot? i used to be
able to plot with Octave, it would start up X11 and if i set the
variable GNUTERM=x11 before starting Octave this would work. now it
doesn't :-(
anybody know what i'm doing wrong? i could use some help. thanks for any.
Hmm. I don't know Macs, but from the error messages, it looks as
though something installed a new version of fontconfig without
updating freetype to match. Have you installed anything since last
using Octave/gnuplot that could have autoupgraded (or autodowngraded,
or otherwise mucked about with) half, but not all, of your X11
subsystem?
(I empathise with luddism. I still use Slackware 11.0. It makes things
simple - absolutely nothing compiles, ever...)
Last login: Wed Dec 31 16:01:14 on console
Roberts-PowerBook-G4-15:~ Robert$ GNUTERM=x11
/Applications/Octave.app/Contents/Resources/bin/octave
GNU Octave, version 3.2.3
Copyright (C) 2009 John W. Eaton and others.
This is free software; see the source code for copying conditions.
There is ABSOLUTELY NO WARRANTY; not even for MERCHANTABILITY or
FITNESS FOR A PARTICULAR PURPOSE. For details, type `warranty'.
Octave was configured for powerpc-apple-darwin8.11.1.
Additional information about Octave is available at http://www.octave.org.
Please contribute if you find this software useful.
For more information, visit http://www.octave.org/help-wanted.html
Report bugs to b...@octave.org (but first, please read
http://www.octave.org/bugs.html to learn how to write a helpful report).
For information about changes from previous versions, type `news'.
octave-3.2.3:1 x=linspace(-1,1);
octave-3.2.3:2 y=x.^2;
octave-3.2.3:3 plot(x,y);
dyld: Library not loaded: /usr/X11/lib/libfreetype.6.dylib
Referenced from: /usr/X11R6/lib/libfontconfig.1.dylib
Reason: Incompatible library version: libfontconfig.1.dylib requires
version 13.0.0 or later, but libfreetype.6.dylib provides version 10.0.0
dyld: Library not loaded: /usr/X11/lib/libfreetype.6.dylib
Referenced from: /usr/X11R6/lib/libfontconfig.1.dylib
Reason: Incompatible library version: libfontconfig.1.dylib requires
version 13.0.0 or later, but libfreetype.6.dylib provides version 10.0.0
/Applications/Gnuplot.app/Contents/Resources/bin/gnuplot: line 71: 1014
Trace/BPT trap GNUTERM=${GNUTERM}
GNUPLOT_HOME=${GNUPLOT_HOME} PATH=${PATH}
DYLD_LIBRARY_PATH=${DYLD_LIBRARY_PATH} HOME=${HOME}
GNUHELP=${GNUHELP} DYLD_FRAMEWORK_PATH=${DYLD_FRAMEWORK_PATH}
GNUPLOT_PS_DIR=${GNUPLOT_PS_DIR} DISPLAY=${DISPLAY}
GNUPLOT_DRIVER_DIR=${GNUPLOT_DRIVER_DIR} ${ROOT}/bin/gnuplot-4.2.6 $@
error: you must have gnuplot installed to display graphics; if you have
gnuplot installed in a non-standard location, see the 'gnuplot_binary'
function
octave-3.2.3:4
/Applications/Gnuplot.app/Contents/Resources/bin/gnuplot: line 71: 1012
Trace/BPT trap GNUTERM=${GNUTERM}
GNUPLOT_HOME=${GNUPLOT_HOME} PATH=${PATH}
DYLD_LIBRARY_PATH=${DYLD_LIBRARY_PATH} HOME=${HOME}
GNUHELP=${GNUHELP} DYLD_FRAMEWORK_PATH=${DYLD_FRAMEWORK_PATH}
GNUPLOT_PS_DIR=${GNUPLOT_PS_DIR} DISPLAY=${DISPLAY}
GNUPLOT_DRIVER_DIR=${GNUPLOT_DRIVER_DIR}
--
r b-j r...@audioimagination.com
Imagination is more important than knowledge.
--
dupswapdrop -- the music-dsp mailing list and website:
subscription info, FAQ, source code archive, list archive, book reviews, dsp
links
http://music.columbia.edu/cmc/music-dsp
http://music.columbia.edu/mailman/listinfo/music-dsp
--
dupswapdrop -- the music-dsp mailing list and website:
subscription info, FAQ, source code archive, list archive, book reviews, dsp
links
http://music.columbia.edu/cmc/music-dsp
http://music.columbia.edu/mailman/listinfo/music-dsp
Re: [music-dsp] need help with gnuplot and octave on my mac.
On 27/10/2012, gwenhwyfaer gwenhwyf...@gmail.com wrote: On 26/10/2012, robert bristow-johnson r...@audioimagination.com wrote: say, any among you using a Mac and Octave and gnuplot? i used to be able to plot with Octave, it would start up X11 and if i set the variable GNUTERM=x11 before starting Octave this would work. now it doesn't :-( anybody know what i'm doing wrong? i could use some help. thanks for any. Hmm. I don't know Macs, but from the error messages, it looks as though something installed a new version of fontconfig without updating freetype to match. Have you installed anything since last using Octave/gnuplot that could have autoupgraded (or autodowngraded, or otherwise mucked about with) half, but not all, of your X11 subsystem? The other possibility is that there's more than one version of either library on your system, and somehow the DYLD_LIBRARY_PATH inherited by gnuplot points to the wrong one. I bet that's going to be fun to debug. Shared libraries - Satan's preferred method of software reuse... -- dupswapdrop -- the music-dsp mailing list and website: subscription info, FAQ, source code archive, list archive, book reviews, dsp links http://music.columbia.edu/cmc/music-dsp http://music.columbia.edu/mailman/listinfo/music-dsp
Re: [music-dsp] OSC problem on STM32F4Discovery
On 09/04/2012, Julian Schmidt julian_schm...@chipmusik.de wrote: yes exactly. it's cheaper than buying the cortex m4 chip alone. and you get a stereo codec (with limiter and equalizer) Stupid question, but the limiter is turned off, isn't it...? -- dupswapdrop -- the music-dsp mailing list and website: subscription info, FAQ, source code archive, list archive, book reviews, dsp links http://music.columbia.edu/cmc/music-dsp http://music.columbia.edu/mailman/listinfo/music-dsp
Re: [music-dsp] FM Synthesis
On 18/09/2011, Rainer Buchty rai...@buchty.net wrote: On Thu, 15 Sep 2011, Gwenhwyfaer wrote: The SY77 has more algorithms and three arbitrary feedback loops - and in fact, will allow entirely arbitrary operator patching over MIDI, with each operator able to accept two scaled inputs. Did the according sysex parameters for crafting your very own operator chain and feedback loops pop up somewhere on the net apart from the known how to select algorithm 45 sequence? I'm sure they did, that I first realised it could be arbitrarily patched on reading the SysEx specs, and that I have a copy of them saved somewhere... but as yet, I have no idea where it is. Which is annoying me quite considerably. On the other hand, Yamaha make almost all their manuals available for free online, and I'm sure it can be found there. ...And I just found it again. The filename is 'sy99e2.pdf', the MIDI implementation chart, and it's all in table 1-7 - but cunningly, not everything is specified, so some experimentation would have to be done to find out exactly what the details are. However, by the looks of it, each operator can select two of 10 input modulators (prior operators, 3 registers, noise and AWM - but which is which is unspecified!), subject each input and its own output to 8 levels of attenuation, and send its output to one of 3 intermediate registers (accumulators?) or the sound output (although that's not fully explained; the output accumulator has two inputs, and the first can select from two sources... *shrug*). Unfortunately, that's as far as I can go, because despite my best efforts I don't have an SY77, TG77 or SY99. -- dupswapdrop -- the music-dsp mailing list and website: subscription info, FAQ, source code archive, list archive, book reviews, dsp links http://music.columbia.edu/cmc/music-dsp http://music.columbia.edu/mailman/listinfo/music-dsp
Re: [music-dsp] FM Synthesis
A few points: On 12/09/2011, Andy Farnell padawa...@obiwannabe.co.uk wrote: If you are heading towards DX7 style FM then notice that only two of the oscillators (2 and 6) can have feedback, and that this is self feedback. Not so - for example, in algorithm 4, operator 4 feeds back to op 6. (However, it is true of 4-op FM synths, where feedback is always operator 4 to itself.) The SY77 has more algorithms and three arbitrary feedback loops - and in fact, will allow entirely arbitrary operator patching over MIDI, with each operator able to accept two scaled inputs. On 12/09/2011, Tom Wiltshire t...@electricdruid.net wrote: As others have said, it shouldn't be more expensive. Assume a buffer size of eight samples: Instead of doing A eight times, then B eight times, then C eight times, etc, you do ABCDEFG, ABCDEFG, etc, eight times. Olivier Gillet found the opposite while developing the Shruthi-1 firmware: http://mutable-instruments.net/node/11683 He uses 40-sample buffers, though. I suspect that the shorter the buffers used, the less it pays off to do depth-first rendering, down to there being no point at all when you're processing each sample at a time. On 14/09/2011, Tom Wiltshire t...@electricdruid.net wrote: On 14 Sep 2011, at 10:29, Emanuel Landeholm wrote: The sad news is that FM with feedback cannot be done the naïve way. You need to account for aliasing. How did Yamaha deal with this in in 1983? The big problem with FM feedback is that you tend to get high frequency oscillations at half the sampling frequency (assuming a 1-sample feedback delay; I suspect it's actually at Fs/(1+delay)). Double-sampling pushes it out of the audio range; I suspect that's why the DX7 used a 57kHz sampling rate. Lightly filtering the feedback loop will sort it too. On 14/09/2011, Richard Dobson richarddob...@blueyonder.co.uk wrote: Not too much of a problem if you use table lookup, which is what I assume the DX 7 did. Without interpolation or even multiplication, no less. It's always puzzled me why, when the DX (indeed, even the FS1r) implementation of FM is such a hacky approximation, software FM synths take up such vast amounts of CPU. All you need is a barrel shifter and lookup table for exponentiation, a phase accumulator, and a reasonably long (2k) log-cosine lookup table; any old ARM7 MCU ought to be able to emulate, and even exceed, a DX synth. (Or a Synergy, for that matter; those things didn't even use logarithms, but used the fact that cos(a+b) - cos(a-b) = 2*sin(b)*sin(a) ~= 2*b*sin(a). However, that limits the possible modulation index to 1 - well, 2 - which in turn limits FM's tonal range somewhat.) Have we now reached the point where FM sounds are back in fashion? I think it's more that FM has become integrated into a broader palette, rather than having to do everything on its own. It's a lot easier to work with when you can twiddle some knobs, get something weird and interesting, and then chisel off the clangorous brightness with a filter. -- dupswapdrop -- the music-dsp mailing list and website: subscription info, FAQ, source code archive, list archive, book reviews, dsp links http://music.columbia.edu/cmc/music-dsp http://music.columbia.edu/mailman/listinfo/music-dsp
Re: [music-dsp] looking for a flexible synthesis system technically and legally appropriate for iOS development
On 17/02/2011, Michael Gogins michael.gog...@gmail.com wrote: LuaJIT is being ported by its impressive author, Mike Pall, to PowerPC architecture, for pay. So with an iPad and a whip-round...? ;) -- dupswapdrop -- the music-dsp mailing list and website: subscription info, FAQ, source code archive, list archive, book reviews, dsp links http://music.columbia.edu/cmc/music-dsp http://music.columbia.edu/mailman/listinfo/music-dsp
Re: [music-dsp] looking for a flexible synthesis system technically and legally appropriate for iOS development
On 17/02/2011, Michael Gogins michael.gog...@gmail.com wrote: What is a whip-round? An impromptu collection of money, generally for a benevolent cause. -- dupswapdrop -- the music-dsp mailing list and website: subscription info, FAQ, source code archive, list archive, book reviews, dsp links http://music.columbia.edu/cmc/music-dsp http://music.columbia.edu/mailman/listinfo/music-dsp
Re: [music-dsp] damn patents (was New patent application on uniformly partitioned convolution) [OT]
On 31/01/2011, Ross Bencina rossb-li...@audiomulch.com wrote: Scenario: I invest 1000s of person-years devising a completely original ultra-fast zero-latency convolution algorithm. Might I humbly suggest that the life extension technology which would enable you to take thousands of person-years to develop anything on your own would be of considerably more commercial value than pretty much anything you would choose to develop? -- dupswapdrop -- the music-dsp mailing list and website: subscription info, FAQ, source code archive, list archive, book reviews, dsp links http://music.columbia.edu/cmc/music-dsp http://music.columbia.edu/mailman/listinfo/music-dsp
Re: [music-dsp] Interpolation for SRC, applications and methods
*emerges from cover, looks around timidly* ...have the big scary beasts finished their territory skirmish now...? *hears noise, startles, scuttles back behind cover* -- dupswapdrop -- the music-dsp mailing list and website: subscription info, FAQ, source code archive, list archive, book reviews, dsp links http://music.columbia.edu/cmc/music-dsp http://music.columbia.edu/mailman/listinfo/music-dsp
Re: [music-dsp] Interpolation for SRC, applications and methods
*emerges from cover, looks around timidly* ...have the big scary beasts finished their territory skirmish now...? *hears noise, startles, scuttles back behind cover* -- dupswapdrop -- the music-dsp mailing list and website: subscription info, FAQ, source code archive, list archive, book reviews, dsp links http://music.columbia.edu/cmc/music-dsp http://music.columbia.edu/mailman/listinfo/music-dsp
Re: [music-dsp] [OT] vinyl? No, thanks...
On 22/11/2010, Stephen Blinkhorn stephen.blinkh...@audiospillage.com wrote: Consistency and order - that's what we need more of today! ;) Only in sound reproduction terms, trust me ;) Vinyl is like a good synth - some days it just doesn't work out right but when it does it's magic. CDs are like a sampler - you know what you're going to get every day. I think Prophet 5 rev1 and Creamware Pro 12 ASB might be better points of comparison. You still get most of the magic - but you don't get the horrible failure nodes, and that's an acceptable price to pay for the top couple of percent more you could have got on a REALLY good day. -- dupswapdrop -- the music-dsp mailing list and website: subscription info, FAQ, source code archive, list archive, book reviews, dsp links http://music.columbia.edu/cmc/music-dsp http://music.columbia.edu/mailman/listinfo/music-dsp
