Hi Tim, Blue has a TempoMapper class that does beatsToSeconds and secondsToBeats with a given Csound style timewarp string (t-statement). This is used by blue's TimeWarp noteProcessor, allowable on a per-soundObject basis, as well as used by blue when following a render if a t-statement is used globally so that accelerando's and such are followed correctly. The math and code for all of this was worked out on this list April 2006 and the Java code I have not is based on python code that Istvan Varga posted. The Java class I use can be seen here: http://bluemusic.cvs.sourceforge.net/bluemusic/blue/src/main/java/blue/noteProcessor/TempoMapper.java?revision=1.7&view=markup The thread for that is availble here: http://www.nabble.com/Calculating-Seconds-to-Beats-in-TimeWarp-tf1435368.html#a3904918 I'll reiterate at this point that I'm indebted to Istvan for his help on this. The thread is also an interesting read I think about how this all works. Hope that helps! steven On 9/7/07, Tim Mortimer wrote: > > http://www.nabble.com/file/p12552632/integratethis.jpg integratethis.jpg > > greets, > > The attached jpeg attempts to illustrate how i intend to use integration to > calculate how much "absolute" time passes in a score when a tempo ramp of a > certain duration becomes active for that period of the score. > > in the case of this example, the tempo decreases from 120BPM to 30BPM over a > period of "4 beats"/ 4 "score seconds". > > My maths is pretty rusty (i did a year 12 bridging course a couple of years > ago - at the time because i had just started using Max, & was desparately > trying to find out what a Markov chain was, but anyway.. the Calculus & Trig > have proven pretty useful along the way......) > > But I'm having trouble trying to integrate the formula in the attached jpeg. > > Can anyone assist? Once I have seen it done once, I should be able to apply > the integrated function universally (more or less) to all my tempo ramping > requirements. > > i do know the basics of integration (eg integrate x^2 = x^3/3 for example..) > > but im stumped by the additional scalars & denominators in my formula, & > hence by what my desired "ramp time" formula looks like (but i'm pretty sure > it's along the lines of what i'm proposing - see the diagram) > > I suppose what makes my approach "a bit fancy" (beyond the method, which > some may feel excessive) is that i like to think that the perception of > tempo - like that of pitch, is an exponential / power of 2 type > relationship: i.e the perception of "speeding up" & "slowing down" is more > meaningful in terms of "twice as fast" / "half as fast", & hence i want to > use a power of 2 curve to impose this "perception" onto my tempo ramping - > rather than simply a linear increase / decrease in BPM value... > > Ok, so i realise this may not be the "normal" way to go about > "accumulating" time vis a vis changes in score tempo, however doing it by > the way I am attempting has some benefits (for me at least, in this > instance) that i see... > > 1) it's ultimately more accurate > > 2) it will fit into my "python score paradigm" tempo system with a minimum > of fuss (trust me - it has no accumulated score time - just a timeline > "function" to which it makes reference to determine current absolute time > for the scored event..) > > 3) u then only need to apply any tempo based calculations to significant > score events, which is someways is surely computationally more efficient > than accumulating ammassed time on each & every control rate clock - when on > 99% of these "clock ticks" no event is actually taking place anyway > > so, err, any help from the maths brains out there on this one appreciated... > > kind regards > > Tim > -- > View this message in context: http://www.nabble.com/tempo-ramp-by-integration---help-needed-tf4400537.html#a12552632 > Sent from the Csound - General mailing list archive at Nabble.com. > > -- > Send bugs reports to this list. > To unsubscribe, send email to csound-unsubscribe@lists.bath.ac.uk >