You can subscribe to this list here.
2004 
_{Jan}

_{Feb}

_{Mar}

_{Apr}

_{May}

_{Jun}

_{Jul}

_{Aug}

_{Sep}

_{Oct}

_{Nov}
(40) 
_{Dec}
(29) 

2005 
_{Jan}
(7) 
_{Feb}
(12) 
_{Mar}
(28) 
_{Apr}
(27) 
_{May}

_{Jun}
(13) 
_{Jul}
(4) 
_{Aug}
(7) 
_{Sep}
(1) 
_{Oct}
(2) 
_{Nov}
(32) 
_{Dec}
(49) 
2006 
_{Jan}
(31) 
_{Feb}
(16) 
_{Mar}
(15) 
_{Apr}
(15) 
_{May}
(21) 
_{Jun}
(1) 
_{Jul}
(1) 
_{Aug}
(5) 
_{Sep}
(2) 
_{Oct}
(21) 
_{Nov}

_{Dec}
(6) 
2007 
_{Jan}
(21) 
_{Feb}

_{Mar}

_{Apr}
(5) 
_{May}
(1) 
_{Jun}
(3) 
_{Jul}
(10) 
_{Aug}
(38) 
_{Sep}
(21) 
_{Oct}
(38) 
_{Nov}
(23) 
_{Dec}
(3) 
2008 
_{Jan}
(72) 
_{Feb}
(45) 
_{Mar}
(46) 
_{Apr}
(5) 
_{May}
(2) 
_{Jun}
(33) 
_{Jul}

_{Aug}
(9) 
_{Sep}
(6) 
_{Oct}
(1) 
_{Nov}
(17) 
_{Dec}
(73) 
2009 
_{Jan}
(20) 
_{Feb}
(28) 
_{Mar}
(7) 
_{Apr}
(24) 
_{May}
(8) 
_{Jun}
(59) 
_{Jul}
(38) 
_{Aug}
(25) 
_{Sep}
(19) 
_{Oct}
(40) 
_{Nov}
(43) 
_{Dec}
(53) 
2010 
_{Jan}
(22) 
_{Feb}
(12) 
_{Mar}
(14) 
_{Apr}
(4) 
_{May}
(29) 
_{Jun}
(26) 
_{Jul}
(7) 
_{Aug}
(14) 
_{Sep}
(16) 
_{Oct}
(34) 
_{Nov}
(13) 
_{Dec}
(8) 
2011 
_{Jan}

_{Feb}

_{Mar}
(1) 
_{Apr}
(1) 
_{May}

_{Jun}
(5) 
_{Jul}
(10) 
_{Aug}
(2) 
_{Sep}
(3) 
_{Oct}

_{Nov}
(1) 
_{Dec}
(1) 
2012 
_{Jan}

_{Feb}
(1) 
_{Mar}

_{Apr}

_{May}

_{Jun}

_{Jul}
(4) 
_{Aug}

_{Sep}
(21) 
_{Oct}

_{Nov}

_{Dec}

2013 
_{Jan}

_{Feb}

_{Mar}
(1) 
_{Apr}

_{May}

_{Jun}

_{Jul}

_{Aug}

_{Sep}

_{Oct}
(6) 
_{Nov}

_{Dec}

2014 
_{Jan}

_{Feb}
(2) 
_{Mar}

_{Apr}

_{May}
(1) 
_{Jun}

_{Jul}
(3) 
_{Aug}

_{Sep}
(1) 
_{Oct}

_{Nov}

_{Dec}

2015 
_{Jan}
(2) 
_{Feb}

_{Mar}

_{Apr}

_{May}

_{Jun}

_{Jul}

_{Aug}

_{Sep}

_{Oct}

_{Nov}

_{Dec}

S  M  T  W  T  F  S 





1

2

3
(2) 
4

5

6

7

8

9

10

11

12

13

14

15

16

17

18

19

20

21

22

23

24

25

26

27

28
(2) 
29
(2) 
30

31
(1) 
From: paul beach <sniffyraven@fa...>  20100731 22:28:08

Bezier curves for graphics, theory, and, sound wave applications are rather different. Perhaps this will be usefull in deciding which is which. ********** I don't see any reason to use a Bezier curve for smoothing. Global effects are generally unwanted for interpolation. But for wave synthesis, Bernstien polynomials may be just thing. Expert comment has to be in context. There seem to be a few flaws in the aurgument, even if it is only used for smoothing "1. Undesirable properties of Bézier curves are their numerical instability for large numbers of control points, and the fact that moving a single control point changes the global shape of the curve. 2. The former is sometimes avoided by smoothly patching together loworder Bézier curves." 1. The constants are determined by binomial coefficients, for large values, Sterling's aproximation might be used. 2. What the text says is true for a graphics package. It is called a bicubic patch. Each region may have a different color or reflection coefficient; and there may be thousands of squares stitched together like a quilt. Indeed! there may be numerical instability. There can be a three dimensional object in fourspace if you want to do research on the frontiers of mathematics, otherwise the version for wave files is the simplest case. A SURFACE in 3d: This is for graphics, as mentioned above. This might be of some use in modeling waves in a ripple tank, though the theory of interference patterns done by other means. A CURVE in 2d: This has two parameters, two control points in Windows paint. There can be many control points, sometimes called a spline. DO not use two parameters for sound files since there may be two or more values, for one value of time. If you want two parameters, use separate sound tracks. One parameter in 2d: There can be many control points. Over 130 may be awkward for Nyquist. Note that musical instrument waveforms are sometimes called beat frequencies, multiple tracks might be appropriate. Is it HARD? A plugin formula can seems to be the usual thing. For many control points you have to inspect the formula and do the monkey see, monkey do thing. http://mathworld.wolfram.com/BernsteinPolynomial.html For Audacity the pairs, (t, bt) would be pushed into list, and used in a pwl function. bt is just one line of calculations but; would be rather long, if there are many control pointsand you are using a plugin method. A flexible program where the user specifies the number of control points is not without some effort, though it is hardly intractable. Sub b1() bt = 0# t = 0 p1 = 1#: p2 = 3#: p3 = 0#: p4 = 1# For i = 1 To 11 bt = (1  t) ^ 3 * p1 + 3 * (1  t) ^ 2 * t * p2 + 3 * (1  t) * t ^ 2 * p3 + t ^ 3 * p4 Cells(i, 1) = t Cells(i, 2) = bt t = t + 0.1 Next i End Sub On Wed, 28 Jul 2010 14:38:31 0400, "Roger Dannenberg" <rbd@...> said: > Sorry I didn't respond to this while it was fresh. I filed this request > for smooth envelopes away to possibly implement or at least think more > about. From mathworld.wolfram.com, " Undesirable properties of Bézier > curves are their numerical instability for large numbers of control > points, and the fact that moving a single control point changes the > global shape of the curve. The former is sometimes avoided by smoothly > patching together loworder Bézier curves." But patching together > loworder curves also creates discontinuities at least in higher > derivatives, and I'm not too clear on the bandlimit properties of > Bézier curves. Furthermore, it's relatively expensive to implement > highorder polynomials as functions of time without a primitive to do > it. I think a better idea is to use piecewise linear functions as > provided in Nyquist. This has been a standard approach in computer music > and audio signal processing for decades. If the discontinuities worry > you, then you can run the pwl function through a lowpass filter using > any of the Nyquist primitives, which are fast, efficient, and give you > simple control over how much smoothing is done. One particular case > where pwl functions are a problem is for quick onsets. If you want to > smoothly turn on a signal without a click or pop, the usual technique is > a "raised cosine", or (1  cos(t))/2, which generates a sort of > "S"curve from 0 to 1. In my experience, this is noticeably better than > a simple linear ramp. You can find an implementation for RAISEDCOSINE > and examples of its use in nyquist/demos/fft_tutorial.htm. > > Roger >  paul beach sniffyraven@... 
From: Johnny Rosenberg <gurus.knugum@gm...>  20100729 15:36:04

2010/7/28 giu santana <giusantana@...>: > Gosto muito de usar o Audacity para fazer montagens e vinhetas, > mas também para conversão para MP3. Mas nesta versão beta senti muita > dificuldade em escolher a forma de conversão, > só podendo utilizar a taxa de bit para 128kbps. > Já na versão estável consigo escolher varias taxas, > tenho mais sugestões e vou mandar com o decorrer do tempo. > Grato pela atenção! Ursäkta mig, men jag förstod inte ett jävla jota av det där. Är det inte engelska som gäller på denna lista? Isn't this list supposed to be in English only? Maybe not, but that's what I thought. Regards Johnny Rosenberg > >  > The Palm PDK Hot Apps Program offers developers who use the > PlugIn Development Kit to bring their C/C++ apps to Palm for a share > of $1 Million in cash or HP Products. Visit us here for more details: > http://p.sf.net/sfu/dev2devpalm > _______________________________________________ > Audacitynyquist mailing list > Audacitynyquist@... > https://lists.sourceforge.net/lists/listinfo/audacitynyquist > > 
From: Gale Andrews <gale@au...>  20100729 01:06:11

 From giu santana <giusantana@...>  Wed, 28 Jul 2010 21:49:07 +0000  Subject: [Audacitynyquist] help > Gosto muito de usar o Audacity para fazer montagens e vinhetas, > mas também para conversão para MP3. Mas nesta versão beta senti muita > dificuldade em escolher a forma de conversão, > só podendo utilizar a taxa de bit para 128kbps. > Já na versão estável consigo escolher varias taxas, > tenho mais sugestões e vou mandar com o decorrer do tempo. De notar, que esta lista é discutir *Nyquist*, não para comentários gerais ou relatórios de bugs. Se você tiver comentários ou relatos de bugs, envie (apenas em *Inglês*) para feedback@... . Pode escolher a MP3 exportação taxa de bits em Audacity Beta, em "Exportar ficheiro" quando exportar  clique em "Opções". Existe um fórum nãooficial para o Audacity aqui: http://www.orkut.com/Main#Community.aspx?cmm=15851877 onde você pode fazer perguntas em Português Brasileiro. Gale 
From: giu santana <giusantana@ho...>  20100728 22:05:39

Gosto muito de usar o Audacity para fazer montagens e vinhetas, mas também para conversão para MP3. Mas nesta versão beta senti muita dificuldade em escolher a forma de conversão, só podendo utilizar a taxa de bit para 128kbps. Já na versão estável consigo escolher varias taxas, tenho mais sugestões e vou mandar com o decorrer do tempo. Grato pela atenção! 
From: Roger Dannenberg <rbd@cs...>  20100728 18:38:40

Sorry I didn't respond to this while it was fresh. I filed this request for smooth envelopes away to possibly implement or at least think more about. From mathworld.wolfram.com, " Undesirable properties of Bézier curves are their numerical instability for large numbers of control points, and the fact that moving a single control point changes the global shape of the curve. The former is sometimes avoided by smoothly patching together loworder Bézier curves." But patching together loworder curves also creates discontinuities at least in higher derivatives, and I'm not too clear on the bandlimit properties of Bézier curves. Furthermore, it's relatively expensive to implement highorder polynomials as functions of time without a primitive to do it. I think a better idea is to use piecewise linear functions as provided in Nyquist. This has been a standard approach in computer music and audio signal processing for decades. If the discontinuities worry you, then you can run the pwl function through a lowpass filter using any of the Nyquist primitives, which are fast, efficient, and give you simple control over how much smoothing is done. One particular case where pwl functions are a problem is for quick onsets. If you want to smoothly turn on a signal without a click or pop, the usual technique is a "raised cosine", or (1  cos(t))/2, which generates a sort of "S"curve from 0 to 1. In my experience, this is noticeably better than a simple linear ramp. You can find an implementation for RAISEDCOSINE and examples of its use in nyquist/demos/fft_tutorial.htm. Roger On 5/20/10 5:48 PM, paul beach wrote: > Help wanted: > > There should be a subroutine for > > (bernsteinlist p0 .... pn, dp) ; dp means number of data points. > http://mathworld.wolfram.com/BernsteinPolynomial.html > > which would be used for > > (pwlvlist bernstein) > > This is trivial for 4 points, which was mentioned by Steve. There is a > little problem with that version. The Bezier curve is a parametric > equation. > > x = B(t,x) > y = B(t,y) > > Just use Berntstein(t,x): Otherwise, the piecewise function could have > 3 or 4 values for one value of time. > > WHY > Roger explains: > "If the first derivative is continuous, the > signal falls off at 18dB per octave, and each additional continuous > derivative gives another 6dB of rolloff. Since we are sensitive to > higher frequencies, it's better not to introduce discontinuities." > > This is contrary to the envelope tools in Nyquist, which introduce > triangular notches. > > Sub bernstein() > bt = 0# > t = 0 > p1 = 1#: p2 = 3#: p3 = 0#: p4 = 1# > > For i = 1 To 11 > > bt = (1  t) ^ 3 * p1 + 3 * (1  t) ^ 2 * t * p2 + 3 * (1  t) * t ^ 2 * > p3 + t ^ 3 * p4 > > Cells(i, 1) = t > Cells(i, 2) = bt > t = t + 0.1 > > Next i > End Sub > 
From: Roger Dannenberg <rbd@cs...>  20100703 21:12:52

There's been much discussion in the past here about the ability of Nyquist to do things like normalizing big files because a simple approach such as (PEAK S NY:ALL) loads all samples of S into Nyquist memory. I've been promising to take a look at this for a long time. I found at least three bugs in the process, but did succeed in writing a pair of plugins that do normalization without using lots of memory. The details are here: http://www.cs.cmu.edu/~music/nyquist/debugplugin.html <http://www.cs.cmu.edu/%7Emusic/nyquist/debugplugin.html>; The most significant bug I found is that if you set a property on *scratch*, it may become invisible to future executions of plugins. Most variables are restored to their original values after running a plugin, preventing plugins from messing up the Nyquist runtime system. While *scratch* is carefully preserved to provide communication channel from one plugin to the next, and while we've said that the way to use it is to put perplugin properties on *scratch*, we didn't anticipate some rather bizarre behavior: If you make up a property symbol, e.g. 'NORMALIZEPART1 and put a property on *scratch*, the property is retained, but the symbol, being new, is removed from the symbol table (the obarray). This doesn't actually delete the property or the symbol, but when another plugin tries to look up the symbol, the code has to be parsed and the symbol looked up. The lookup will fail, so XLisp creates *another* symbol with the same name and adds it to the symbol table. Then the plugin goes to get the property, the GET function scans the property list looking for a pointer match (there's no need for string compares on symbols since it is assumed that symbols are unique). The lookup fails. The rather bizarre part is that if you choose a common symbol like 'TEST as we did when we tested the new facility, chances are the symbol already existed in Nyquist, so it was not removed from the symbol table. In those cases, the *scratch* property list works as expected. Did we already discover this? I seem to remember someone claiming this was broken (correct) and maybe I posted a quick demonstration that it worked fine (if so, I owe an apology  I must have used something like 'TEST as the property symbol). In any case, now we know the problem. I implemented a fix, but I'm not in a good state to commit changes. If someone (Leland?) wants the patch to nyx.c, I can send it. Roger 
From: paul beach <sniffyraven@fa...>  20100703 21:01:29

There is no formula that only generates primes and excludes composite numbers. Here, the prime numbers are generated by Euclid's, greatest common divisor (gcd ), and a modified sieve of Eratosthenes'. The prime numbers can be labeled as pitches, in which case there are 4 different notes, since the prime numbers are to the modulus twelve. The notes happen to be Dflat, F, G, and B, which would be an augmented French 6th in the key of Fminor. I was trying to get (plunk) into the loop, any suggestions would be appreciated. paul ;nyquist plugin ;version 1 ;type generate ;name "A prime series..." ;action "Prime numbers 1197 ..." (setf pf (* 2 3 5 7 )) ; product of prime factors less than 10 (setf offs 10) (setf n 90) ; loop from 10 to 100 (dotimes (i n) (setf pr (gcd pf (+ i offs ))) (when (equal pr 1) (print (+ i offs )) ; (plunk ??) ) )  paul beach sniffyraven@... 