Subject: MAX Digest - 6 May 1999 to 7 May 1999 (#1999-139) Date: Sat, 8 May 1999 00:00:03 -0400 From: Automatic digest processorReply-To: MAX - Interactive Music/Multimedia Standard Environments To: Recipients of MAX digests There are 5 messages totalling 326 lines in this issue. Topics of the day: 1. looking for a reeeeeally fast metro 2. Oops: Re: USB serial interface that claims to work with MIDI 3. Call for works 4. (LONG) floats vs ints 5. off topic.. pb2400 ---------------------------------------------------------------------- Date: Fri, 7 May 1999 01:02:58 -0400 From: Alex Burton Subject: Re: looking for a reeeeeally fast metro >Date: Thu, 6 May 1999 01:55:47 -0400 >From: Marcel Wierckx >Subject: looking for a reeeeeally fast metro > >Hi people, > >Anyone know where I could find a metro object that goes down to 1 or 2 ms. >intervals? Or if I could even get that kind of resolution in Max? Hello Marcel, I sort of recall a metro1 object, but could no find it. A feedback delay 1 will work. Alternatively you could drive a line with 1ms grain (you can vary the grain size during a segment) to get a sort of "superclocker." (i can't say how precise these methods are; they do generate 1000 pulses in 1000 milliseconds (whatever the scheduler setting) but i don't know if these are real, smooth milliseconds...) Out of curiosity, what's your application for that pulse? Alex. ------------------------------ Date: Fri, 7 May 1999 01:25:53 -0400 From: Eloy Anzola Subject: Re: Oops: Re: USB serial interface that claims to work with MIDI Mr. Stahl said: > My previous message regarding the Stealth Serial Port was ripe with > misinformation. I sincerely apologize. Seems that it is in fact shipping > to US locations, and does require a special extension. I'll be trying one > with Max and a Studio 4 Real Soon. > > -Alex Stahl please let us know the results. Waiting with anticipation... thanks, Eloy ------ leaddaet@earthlink.net http://home.earthlink.net/~leaddaet ------------------------------ Date: Fri, 7 May 1999 14:33:41 +0200 From: Gary Berger Subject: Call for works Call for works for the concert season of 1999/2000 The Swiss Center for Computer Music (SCCM) requests submission of musical works for tape, solo instrument and tape and solo instrument combined with live electronics. Please send DATs or CDs of your electroacoustic music together with some biographical informations and a programe note to the address below. Pieces with a maximum duration of 10 minutes are prefered. If you would like to send a selection of your work, please feel free to do so. Works for video may also be considered. All works not selected for the concerts will be saved in the SCCM-archive and possibly considered for future events. Deadline: Please submit your compositions until July 1st, 1999. Thank you for your participation. With kind regards The Swiss Center for Computer Music Send your compositions and requests for additional information to: Gary Berger Swiss Center for Computer Music Elisabethenstrasse 3 8004 Zurich Switzerland E-mail: gberger@computermusic.ch http://www.computermusic.ch ------------------------------ Date: Fri, 7 May 1999 16:32:14 -0400 From: Tom Ritchford Subject: (LONG) floats vs ints Trond Lossius wrote: >Subject: Re: Getting rid of floats? > >Quoting Tom Ritchford: > >> The best solution is to get rid of floats from your program. >> >I tend to use math functions as compositional material. For this kind of >material there is little or no use in converting to ints as many of ther >functions can only be calculated as floats in the first place. right, this is quite true... if you take an exponential or a log or a trig function then you are in the realm of floating point. >The field of Fuzzy Logics is another example. Now, here's where I'd disagree... basically, fuzzy logic is just a form of statistics, a mechanism for combining probabilities to get other probabilities. Since the vast majority of the operations are simple arithmetic like multiplication and addition, it makes sense to use scaled integers (see later) rather than >> Knuth (Art of Computer Programming, vol I) speaks very movingly >> of this, pointing out that almost no property that you'd expect >> is valid of floats in the general case (associativity, distributivity, >> etc.) And I'm going to shamelessly crib from him in the next sections. > >It is true that ints are evenly distributed, something floats are not. not only that... you aren't guaranteed eg that (a+b)+c =3D a+(b+c) >the pass object from Karheinz Essls >RTC-lib passes a certain percentage of bangs received, using random 100 >and a < (int) object. >If you start of >letting through 50% of the bangs, the least change you can make is 49 or >51, a change of =B12 % relative to 50. If you start off letting through >only 10%, the least change you can get is =B110%. \If pass is used to >contol some kind of density this means that it is more difficult to do >subtle changes of density (relatively speaking) for low values then >higher ones. I quoted all of this because it's a REALLY important point and one that constantly bites me when using MIDI. I play a MIDI wind controller, one which reports the breath pressure using a CC from 0 to 127. (In fact, it doesn't even report the full 7 bits of pressure but that's for another day and thread). And I experience exactly the same phenomenon... I have more dynamic control at the top of my dynamic range. I'm coining a phrase right now and calling it the log-lin problem -- not enough digits for the low numbers, too many for the high ones. This is a hobby horse of mine so I'll be brief and merely note that the problem is that of linearity vs logarithmic control. You hear and see things logarithmically, you experience ratios rather than absolute jumps. So, your controllers should look more like the scale on a slide rule (remember those, somewhat after the abacus?) where there is a lot of space given to the numbers between 1 and 2 and very little space given to the numbers between 9 and 10.) This is a universal law in some ways which Mandelbrot amongst others has written about, and it's related to the reason that the first digits of "random" numbers from the real world are NOT uniformly distributed... if you look at eg lengths of rivers in an almanac then some 20% of these lengths will start with the number 1 and only about 5% with the number 9. > >One more illustration. Some weeks ago there was a request at the max-l >for a line object for floats. One reply suggested to multiply by 10, >using line, and then divide by 10 again. using "scaled integers" (see below). >I posted a more complex solution ensuring equal step size. and using floats, which is a much better solution, since you are STARTING with floats. The *10/10 solution is just saying, in essence, let's use floats with one decimal of precision only. >In general I believe that the addition of MSP will enforce floats to be >used more than at present. Agreed. A shame really... even if your DACs are exponential which I still in heart believe gives a better response, it's much better to translate your incoming samples (which are in log form) to a linearized value (with possible some extra, spurious precision) and then to do all your calculations with that integer value. So, Knuth describes for our purposes two methods that are of use, "scaled integer" and "fractions". The scaled integer is the simplest and often the best. Basically, you have a convention that all the integers "of a certain type" are scaled by some factor, often a power of 2 or of 10. Here's an example -- an old style desk calculator that displays two digits after the decimal point, always. Really, you are just doing integer calculations and there's a decimal point painted two digits to the left of the right side. Here the scale factor is 0.01. In the Essl "pass" object, you are passing probabilities to filter: these are in principle real numbers from 0.0 to 1.0. Essl is using the same representation, with a scale of 0.01. This brings us to a simpler way to solve the log-lin problem... you can just make the scale larger until it serves properly even at the "lowest" levels. For example, if Dr. Essl used a scale of 0.0001 or 1/10000 then we'd be able to get a variation of 0.1% of the value even at filter=3D10%. Of course, no matter what sort of scale you use you're still going to have problems around 0, something which a floating point system won't have. =46or almost all my projects I've used some variation on scaled integers. There are several things to be careful of. The first is mixing scaled and unscaled integers. You need to be aware of which variable contain integers that, in your mind, you have decided are scaled and which ones contain "just integers". With that in mind, you need to be careful when performing arithmetic. It's OK to add or subtract two scaled integers but not to add a scaled to an unscaled integer ("of course"). Multiplication and division are more tricky. It's often not well defined to multiply two scaled integers (ie, what's $3.50*$1.25?) but multiplying or dividing a scaled integer by an unscaled integer is usually fine (5*$1.25). In some cases, you can divide and multiply -- filter probabilities are a good example here. In these cases you get, respectively, one too few and one too many factors of the divisor. Here's the probability examples: 30% * 20% =3D> (30 * 20) / 100 =3D> 6% 30% / 20% =3D> (30 * 100) / 20 =3D> 150% (OK, this makes no sense for probabilities but does in other cases.= ) Note that you rescale AFTER the multiplication but BEFORE the division (to preserve the maximum precision). =46ractions are much cooler but less useful. You just keep every number as two integers, a numerator and a denominator, and then multiply, add, subtract and divide, just like in grade school. This is nice because you have EXACT precision. And IF you can represent arbitrarily long integers, you can represent any rational number! The trouble is that if you add a bunch of fractions together randomly, the numerators and denominators tend to grow pretty fast, even if you go to the extra effort of reducing the fractions after every operation. So you run out of integers very fast and then have to do some sort of fandangle rounding operation. Not pretty. Still, this can be really useful in some restricted problem domains where you can prove that the numerators and denominators won't get too large (which is often easier than it sounds). And fractions automatically solve the log-lin problem "because" they have a few numbers that go waaaay up and then a lot of very little numbers. When I have used this method, I've usually (always?) just assigned the input values to be a fraction a/b and then worked out the result algebraically. So you can get a closed form for the numerator and denominator of the result in terms of the input. You can then often show that the calculations will be bounded and proceed from the beginning to the end in one step. No doubt Knuth has plenty of subtle examples that I've missed here. Don't get hung up -- if floats will let you do what you need to do in the most effective way for your problem then you should use them! /t ------------------------------ Date: Sat, 8 May 1999 11:06:47 +1000 From: Jeremy Yuille Subject: off topic.. pb2400 apologies for this off topic q, but is anyone on this list using a pb2400/180? I'm having some dificulties with mine and would like to talk with other 2400 owners about it off list if possible.. maybe slightly more on topic.. has nayone fitted a vimage 320MHz/1Mb G3 daughterboard to their 2400? best Jeremy Yuille ________________________ mailto:overt@overlobe.com http://www.overlobe.com 0 /|\ / \ ~~~~~ ________________________ ------------------------------ End of MAX Digest - 6 May 1999 to 7 May 1999 (#1999-139) ********************************************************