There is this piece from Alvin Lucier "In Memoriam Jon Higgings" for A-Clarinet and sine wave oscillator. The wave oscillator is doing a very slow even glissando starting from a low C (130.81279 Hz)and is arriving after 19'30'' at an (3 Octaves and a third) higher Eb (1244.507935 Hz). To get an equal dispensation of the semitones (every 30 seconds another semitone (as it is written in the score))I need a formula which take the expotential(?)ascending of the frequencies in account (like A=440Hz, A'=880, A''=1760Hz).

Do I need to build an expotential function or the opposite (logarithm(?))?

There is this piece from Alvin Lucier "In Memoriam Jon Higgings" for A-Clarinet and sine wave oscillator. The wave oscillator is doing a very slow even glissando starting from a low C (130.81279 Hz)and is arriving after 19'30'' at an (3 Octaves and a third) higher Eb (1244.507935 Hz). To get an equal dispensation of the semitones (every 30 seconds another semitone (as it is written in the score))I need a formula which take the expotential(?)ascending of the frequencies in account (like A=440Hz, A'=880, A''=1760Hz).
Do I need to build an expotential function or the opposite (logarithm(?))?
and would I do that?

lucier-sine-wave-glissando-math

On Oct 21, 2007, at 12:46 AM, Ole Schmidt wrote:

> There is this piece from Alvin Lucier "In Memoriam Jon Higgings" 

> for A-Clarinet and sine wave oscillator. The wave oscillator is 

> doing a very slow even glissando starting from a low C (130.81279 

> Hz)and is arriving after 19'30'' at an (3 Octaves and a third) 

> higher Eb (1244.507935 Hz). To get an equal dispensation of the 

> semitones (every 30 seconds another semitone (as it is written in 

> the score))I need a formula which take the expotential(?)ascending 

> of the frequencies in account (like A=440Hz, A'=880, A''=1760Hz).

> Do I need to build an expotential function or the opposite 

>
> There is this piece from Alvin Lucier "In Memoriam Jon Higgings"  
> for A-Clarinet and sine wave oscillator. The wave oscillator is  
> doing a very slow even glissando starting from a low C (130.81279  
> Hz)and is arriving after 19'30'' at an (3 Octaves and a third)  
> higher Eb (1244.507935 Hz). To get an equal dispensation of the  
> semitones (every 30 seconds another semitone (as it is written in  
> the score))I need a formula which take the expotential(?)ascending  
> of the frequencies in account (like A=440Hz, A'=880, A''=1760Hz).
> Do I need to build an expotential function or the opposite  
> (logarithm(?))?
> and would I do that?
>
> Any coaching is much apprechiated
>
> ole


Quote: klaus wrote on Sun, 21 October 2007 01:29

----------------------------------------------------

> #P message 113 138 80 196617 48 , 87 990000;

> #P flonum 113 194 42 9 0 0 0 3 0 0 0 221 221 221 222 222 222 0 0 0;

> #P flonum 174 253 60 9 0 0 0 3 0 0 0 221 221 221 222 222 222 0 0 0;

that was my first idea too. but when you observe (whith a cromatic tuner) how the semitones are distributed you will see that in the lower frequencies the glissando move quicker than 30 seconds from semitone to semitone and the higher it comes it goes the other way around. What I am after is an even distributed change of the semitones every 30 seconds (as it is written in the score).

Quote: LoneMonad aka don malone wrote on Sun, 21 October 2007 01:54

which arguments do I need in curve~ to get the even distribution of the semitones which I described above (in respect to the non-linear ascension of the frequencies)

Quote: klaus wrote on Sun, 21 October 2007 01:29
----------------------------------------------------
> #P window setfont "Sans Serif" 9.;
> #P window linecount 1;
> #P newex 113 284 31 196617 dac~;
> #P newex 113 254 40 196617 cycle~;
> #P message 113 138 80 196617 48 , 87 990000;
> #P newex 113 165 40 196617 line 0.;
> #P flonum 113 194 42 9 0 0 0 3 0 0 0 221 221 221 222 222 222 0 0 0;
> #P flonum 174 253 60 9 0 0 0 3 0 0 0 221 221 221 222 222 222 0 0 0;
> #P newex 113 217 29 196617 mtof;
> #P connect 0 0 5 0;
> #P connect 0 0 1 0;
> #P connect 5 0 6 0;
> #P connect 4 0 3 0;
> #P connect 3 0 2 0;
> #P connect 2 0 0 0;
> #P window clipboard copycount 7;
>
> nice tune!
> klaus

that was my first idea too. but when you observe (whith a cromatic tuner) how the semitones are distributed you will see that  in the lower frequencies the glissando move quicker than 30 seconds from semitone to semitone and the higher it comes it goes the other way around. What I am after is an even distributed change of the semitones every 30 seconds (as it is written in the score). 

Quote: LoneMonad aka don malone wrote on Sun, 21 October 2007 01:54
----------------------------------------------------
> would [curve~]->[cycle~] be smoother?
----------------------------------------------------

It's an incomplete patch: you have to find a way to stop and restart 

your glissando if the instrumentalist stops during the rehearsals.

....but this can give you a good starting point.

Il giorno 21/ott/07, alle ore 00:46, Ole Schmidt ha scritto:

It's an incomplete patch: you have to find a way to stop and restart  
your glissando if the instrumentalist stops during the rehearsals.
....but this can give you a good starting point.

>
> There is this piece from Alvin Lucier "In Memoriam Jon Higgings"  
> for A-Clarinet and sine wave oscillator. The wave oscillator is  
> doing a very slow even glissando starting from a low C (130.81279  
> Hz)and is arriving after 19'30'' at an (3 Octaves and a third)  
> higher Eb (1244.507935 Hz). To get an equal dispensation of the  
> semitones (every 30 seconds another semitone (as it is written in  
> the score))I need a formula which take the expotential(?)ascending  
> of the frequencies in account (like A=440Hz, A'=880, A''=1760Hz).
> Do I need to build an expotential function or the opposite  
> (logarithm(?))?
> and would I do that?
>
> Any coaching is much apprechiated
>
> ole

btw, yesterday i got a link to a recording of the piece (and others 

by alvin) at tate in 2005, complete with recordings of rehearsals and 

http://www.tate.org.uk/onlineevents/archive/open_sound_systems/#lpa

Am 21.10.2007 um 10:28 schrieb Lorenzo Pagliei:

btw, yesterday i got a link to a recording of the piece (and others  
by alvin) at tate in 2005, complete with recordings of rehearsals and  
score.
(its an officially free download)

hans w. koch
im krahnenhof 11
d-50668 koeln
+49-221-554902
www.hans-w-koch.net

In my posted patch final value doesn't reach midi note 87......and I 

In my posted patch final value doesn't reach midi note 87......and I  
imagine you need tuning precision

Quote: lorenzo.pagliei wrote on Sun, 21 October 2007 10:28

> It's an incomplete patch: you have to find a way to stop and restart 

> your glissando if the instrumentalist stops during the rehearsals.

> ....but this can give you a good starting point.

thank you Lorenzo, a elegant patch moving with line (=linear)from semitone to semitone. This solution can be used for performing the piece. I'am still looking for a very simple- straight-ahead more math-oriented solution.

Quote: lorenzo.pagliei wrote on Sun, 21 October 2007 10:28
----------------------------------------------------
> You can try this.
>
> It's an incomplete patch: you have to find a way to stop and restart  
> your glissando if the instrumentalist stops during the rehearsals.
> ....but this can give you a good starting point.
>
> Best
>
> Lorenzo
>

mtof is already exponential because it treats pitches and not 

BTW I suggest you not to use a "global-two-objets" solution because 

of the long glissando duration (19'-30").....i think that after 5 

minutes you could have problems with exact durations using line. You 

can also try a signal driven solution......but I don't konw....it 

depends from how much precision and fine tunig you need...

As an alternative use curve~ with the third argument set to 0.5, it's 

exponential (see help file). You can use my patch approach using 

curve~ instead of line (use >~ and mtof~ after.......it's the same).

Il giorno 21/ott/07, alle ore 11:17, Ole Schmidt ha scritto:

> thank you Lorenzo, a elegant patch moving with line (=linear)from 

> semitone to semitone. This solution can be used for performing the 

> piece. I'am still looking for a very simple- straight-ahead more 

mtof is already exponential because it treats pitches and not  
frequencies.

BTW I suggest you not to use a "global-two-objets" solution because  
of the long glissando duration (19'-30").....i think that after 5  
minutes you could have problems with exact durations using line. You  
can also try a signal driven solution......but I don't konw....it  
depends from how much precision and fine tunig you need...

As an alternative use curve~ with the third argument set to 0.5, it's  
exponential (see help file). You can use my patch approach using  
curve~ instead of line (use >~ and mtof~ after.......it's the same).

Il giorno 21/ott/07, alle ore 11:17, Ole Schmidt ha scritto:
>
> thank you Lorenzo, a elegant patch moving with line (=linear)from  
> semitone to semitone. This solution can be used for performing the  
> piece. I'am still looking for a very simple- straight-ahead more  
> math-oriented solution.
>
> ole

not to forget, that mtof~ also comes at signal rate. (which makes for 

Am 21.10.2007 um 11:45 schrieb Lorenzo Pagliei:

> mtof is already exponential because it treats pitches and not 

> BTW I suggest you not to use a "global-two-objets" solution because 

> of the long glissando duration (19'-30").....i think that after 5 

> minutes you could have problems with exact durations using line. 

> You can also try a signal driven solution......but I don't 

> konw....it depends from how much precision and fine tunig you need...

> As an alternative use curve~ with the third argument set to 0.5, 

> it's exponential (see help file). You can use my patch approach 

> using curve~ instead of line (use >~ and mtof~ after.......it's the 

> Il giorno 21/ott/07, alle ore 11:17, Ole Schmidt ha scritto:

>> thank you Lorenzo, a elegant patch moving with line (=linear)from 

>> semitone to semitone. This solution can be used for performing the 

>> piece. I'am still looking for a very simple- straight-ahead more 

not to forget, that mtof~ also comes at signal rate. (which makes for  
a more stable timing):

> mtof is already exponential because it treats pitches and not  
> frequencies.
>
> BTW I suggest you not to use a "global-two-objets" solution because  
> of the long glissando duration (19'-30").....i think that after 5  
> minutes you could have problems with exact durations using line.  
> You can also try a signal driven solution......but I don't  
> konw....it depends from how much precision and fine tunig you need...
>
> As an alternative use curve~ with the third argument set to 0.5,  
> it's exponential (see help file). You can use my patch approach  
> using curve~ instead of line (use >~ and mtof~ after.......it's the  
> same).
>
> CIAO
>
> L
>
> Il giorno 21/ott/07, alle ore 11:17, Ole Schmidt ha scritto:
>>
>> thank you Lorenzo, a elegant patch moving with line (=linear)from  
>> semitone to semitone. This solution can be used for performing the  
>> piece. I'am still looking for a very simple- straight-ahead more  
>> math-oriented solution.
>>
>> ole
>
>


> I'am still looking for a very simple- straight-ahead more math-oriented solution.

the version posted by Klaus is also correct (and easier to understand). 

He just got the calculations wrong: 19'30'' is 1170000 milliseconds and 

I made a patch that takes initial and desired midi pitch as input and 

also the time per semitone (30000 ms). Comparing this to Lorenzo's patch 

However, there is a small differenc that is growing over time. To me 

this seems to be inaccuracy in the line object. Lorenzo's version runs 

just slightly faster (which is probably due to the fact that he uses the 

end-of-line- bang to start line again which seems to skip one time 

grain). You can see that the difference gets bigger every 30 seconds.

If you still want to detune it to 442Hz as you wrote me then just 

multiply the resulting frequency by (442/440).

Ole Schmidt wrote:
> I'am still looking for a very simple- straight-ahead more math-oriented solution.

the version posted by Klaus is also correct (and easier to understand). 
He just got the calculations wrong: 19'30'' is 1170000 milliseconds and 
not 990000.

I made a patch that takes initial and desired midi pitch as input and 
also the time per semitone (30000 ms). Comparing this to Lorenzo's patch 
gives almost identical results.
However, there is a small differenc that is growing over time. To me 
this seems to be inaccuracy in the line object. Lorenzo's version runs 
just slightly faster (which is probably due to the fact that he uses the 
end-of-line- bang to start line again which seems to skip one time 
grain). You can see that the difference gets bigger every 30 seconds.

If you still want to detune it to 442Hz as you wrote me then just 
multiply the resulting frequency by (442/440).

Listen to de difference between line~ and curve~ if you use pitch.

in the posted patch if you use curve, you listen to accents avery 

333 msec (doubleclick loadbang to feed value 333)

otherwise you can find the mtof formula in the mtof help file

in the posted patch if you use curve,  you listen to accents avery  
333 msec (doubleclick loadbang to feed value 333)

Quote: lorenzo.pagliei wrote on Sun, 21 October 2007 11:45

that is what I was asking for, I overlooked it and was thinking to complicated.

Quote: lorenzo.pagliei wrote on Sun, 21 October 2007 11:45
----------------------------------------------------
> mtof is already exponential because it treats pitches and not  
> frequencies.
>

Il giorno 21/ott/07, alle ore 12:30, Olaf Matthes ha scritto:

> Lorenzo's version runs just slightly faster (which is probably due 

> to the fact that he uses the end-of-line- bang to start line again 

> which seems to skip one time grain). You can see that the 

> difference gets bigger every 30 seconds.

For this reason I prefer to divide 19'-30" into 30"packets to avoid 

> If you still want to detune it to 442Hz as you wrote me then just 

> multiply the resulting frequency by (442/440).

If you need to tune your mtof you find an ej.mtof in the ejies where 

you can give your diapason as an argument

Il giorno 21/ott/07, alle ore 12:30, Olaf Matthes ha scritto:
>
> Lorenzo's version runs just slightly faster (which is probably due  
> to the fact that he uses the end-of-line- bang to start line again  
> which seems to skip one time grain). You can see that the  
> difference gets bigger every 30 seconds.

For this reason I prefer to divide 19'-30" into 30"packets  to avoid  
excessive amount of time imprecision.

> If you still want to detune it to 442Hz as you wrote me then just  
> multiply the resulting frequency by (442/440).

If you need to tune your mtof you find an ej.mtof in the ejies where  
you can give your diapason as an argument

Quote: lorenzo.pagliei wrote on Sun, 21 October 2007 12:44

> If you need to tune your mtof you find an ej.mtof in the ejies where 

> you can give your diapason as an argument

Quote: lorenzo.pagliei wrote on Sun, 21 October 2007 12:44
----------------------------------------------------

> If you need to tune your mtof you find an ej.mtof in the ejies where  
> you can give your diapason as an argument

Any of the mtof solutions will work well if you can guarantee precision over

such a long period. Midi key numbers are logarithms of frequency - a linear

series describing an exponential series. Have a look at the help file for

mtof and ftom to see the expressions used for the converstion. Remember to

use a float argument for ftom if you don't want your output to round to the

Curve~ could be a problem unless you get exactly the right value for the

curve shape parameter (3rd inlet). I'm not sure what that value must be to

get the correct shape for this application.

Amplitude is also exponential. DB is a logarithm for amplitude. See dbtoa

Likewise tempo. Twice as fast as 60 bpm is easy but what is 1.5 times as

fast. Nope, not 90. If your answer is 84.852814, you win. With the

following conversion function, input 0 produces 60, 1 = 120, -1 = 30.

Can't remember who told me the story of a snake breeder who was concerned

about low production until he found that putting his snakes on a picnic

table increased their output. He read that adders could be made to multiply

Sometimes key velocity is best used exponentially. I wrote the abstractions

below to convert between dynamics and velocity. I mapped pppp...ffff

(although these are subjective) to a range 1..10. Input and output are both

float so I can deal with intermediate dynamics like mp.5.

On 10/21/07 7:43 AM, "Ole Schmidt" wrote:

> Quote: lorenzo.pagliei wrote on Sun, 21 October 2007 12:44

> ----------------------------------------------------

>> If you need to tune your mtof you find an ej.mtof in the ejies where

>> you can give your diapason as an argument

Any of the mtof solutions will work well if you can guarantee precision over
such a long period.  Midi key numbers are logarithms of frequency - a linear
series describing an exponential series.  Have a look at the help file for
mtof and ftom to see the expressions used for the converstion.  Remember to
use a float argument for ftom if you don't want your output to round to the
nearest midi key number.

Curve~ could be a problem unless you get exactly the right value for the
curve shape parameter (3rd inlet).  I'm not sure what that value must be to
get the correct shape for this application.

Amplitude is also exponential.  DB is a logarithm for amplitude. See dbtoa
and atodb.

Likewise tempo.  Twice as fast as 60 bpm is easy but what is 1.5 times as
fast. Nope, not 90.  If your answer is 84.852814, you win.  With the
following conversion function, input 0 produces 60, 1 = 120, -1 = 30.

Can't remember who told me the story of a snake breeder who was concerned
about low production until he found that putting his snakes on a picnic
table increased their output. He read that adders could be made to multiply
if he used a log table.

Sometimes key velocity is best used exponentially. I wrote the abstractions
below to convert between dynamics and velocity.  I mapped pppp...ffff
(although these are subjective) to a range 1..10.  Input and output are both
float so I can deal with intermediate dynamics like mp.5.

Cheers
Gary Lee Nelson
Oberlin College
www.timara.oberlin.edu/GaryLeeNelson

On 10/21/07 7:43 AM, "Ole Schmidt"  wrote:

>
> Quote: lorenzo.pagliei wrote on Sun, 21 October 2007 12:44
> ----------------------------------------------------
>
>
>> If you need to tune your mtof you find an ej.mtof in the ejies where
>> you can give your diapason as an argument
>
> ----------------------------------------------------
>
> thank you for that too!!
>
> ole


of a D17-B intercontinental ballistic missile

a profs from the sciece dept, cleve scott and i

the first patch was a 24hr full sweep of an oscillator

an aside:
in 1972
when i was in grad school at BSU
we received a computer
which had been the guidance system
of a D17-B intercontinental ballistic missile
declassified by the gov
a profs from the sciece dept, cleve scott and i
hooked it up to the arp 2500
the first patch was a 24hr full sweep of an oscillator
no clarinets though


I saw that thing. Don didn't mention that it housed in a nosecone-shaped

> of a D17-B intercontinental ballistic missile

> a profs from the sciece dept, cleve scott and i

> the first patch was a 24hr full sweep of an oscillator

http://faculty.roosevelt.edu/malone/default.htm

I saw that thing.  Don didn't mention that it housed in a nosecone-shaped
box - very spooky.

On 10/21/07 9:54 AM, "don malone"  wrote:

>
> an aside:
> in 1972
> when i was in grad school at BSU
> we received a computer
> which had been the guidance system
> of a D17-B intercontinental ballistic missile
> declassified by the gov
> a profs from the sciece dept, cleve scott and i
> hooked it up to the arp 2500
> the first patch was a 24hr full sweep of an oscillator
> no clarinets though
> --
> it takes all of us
> LoneMonad
> http://faculty.roosevelt.edu/malone/default.htm

{SinOsc.ar(Line.ar(48, 87, 1170).midicps, mul: 0.4)!2}.play

in SC3 should work, I guess. It sounds smooth for me.

> Any of the mtof solutions will work well if you can guarantee precision

> such a long period. Midi key numbers are logarithms of frequency - a

> series describing an exponential series. Have a look at the help file for

> mtof and ftom to see the expressions used for the converstion. Remember

> use a float argument for ftom if you don't want your output to round to

> Curve~ could be a problem unless you get exactly the right value for the

> curve shape parameter (3rd inlet). I'm not sure what that value must be

> get the correct shape for this application.

> Amplitude is also exponential. DB is a logarithm for amplitude. See dbtoa

> Likewise tempo. Twice as fast as 60 bpm is easy but what is 1.5 times as

> fast. Nope, not 90. If your answer is 84.852814, you win. With the

> following conversion function, input 0 produces 60, 1 = 120, -1 = 30.

> Can't remember who told me the story of a snake breeder who was concerned

> about low production until he found that putting his snakes on a picnic

> table increased their output. He read that adders could be made to

> Sometimes key velocity is best used exponentially. I wrote the

> below to convert between dynamics and velocity. I mapped pppp...ffff

> (although these are subjective) to a range 1..10. Input and output are

> float so I can deal with intermediate dynamics like mp.5.

> #P newex 19 109 183 196617 expr 10*pow((($i1-1)/126.0)\,0.5);

2007/10/21, Gary Lee Nelson :
>
> Any of the mtof solutions will work well if you can guarantee precision
> over
> such a long period.  Midi key numbers are logarithms of frequency - a
> linear
> series describing an exponential series.  Have a look at the help file for
> mtof and ftom to see the expressions used for the converstion.  Remember
> to
> use a float argument for ftom if you don't want your output to round to
> the
> nearest midi key number.
>
> Curve~ could be a problem unless you get exactly the right value for the
> curve shape parameter (3rd inlet).  I'm not sure what that value must be
> to
> get the correct shape for this application.
>
> Amplitude is also exponential.  DB is a logarithm for amplitude. See dbtoa
> and atodb.
>
> Likewise tempo.  Twice as fast as 60 bpm is easy but what is 1.5 times as
> fast. Nope, not 90.  If your answer is 84.852814, you win.  With the
> following conversion function, input 0 produces 60, 1 = 120, -1 = 30.
>
> expr pow(2,$f1)*60.
>
> Can't remember who told me the story of a snake breeder who was concerned
> about low production until he found that putting his snakes on a picnic
> table increased their output. He read that adders could be made to
> multiply
> if he used a log table.
>
> Sometimes key velocity is best used exponentially. I wrote the
> abstractions
> below to convert between dynamics and velocity.  I mapped pppp...ffff
> (although these are subjective) to a range 1..10.  Input and output are
> both
> float so I can deal with intermediate dynamics like mp.5.
>
> DynVel
>
> #N comlet Dynamics (0.0-10.0);
> #P outlet 19 134 15 0;
> #N comlet Velocity (0-127);
> #P inlet 19 35 15 0;
> #P window setfont "Sans Serif" 9.;
> #P window linecount 1;
> #P newex 19 109 183 196617 expr 10*pow((($i1-1)/126.0)\,0.5);
> #P window linecount 3;
> #P comment 61 66 100 196617 Converts velocity to "dynamics" using old
> family
> recipe.;
> #P window setfont Helvetica 24.;
> #P window linecount 1;
> #P comment 61 21 97 1376280 DynVel;
> #P window setfont "Sans Serif" 9.;
> #P comment 60 50 121 196617 Author: Gary Lee Nelson;
> #P connect 3 0 5 0;
> #P connect 4 0 3 0;
> #P window clipboard copycount 6;
>
> VelDyn
>
> #P inlet 19 35 15 0;
> #P window setfont "Sans Serif" 9.;
> #P window linecount 4;
> #P comment 61 66 100 196617 Converts "dynamics" to velocity" using old
> family recipe.;
> #P window setfont Helvetica 24.;
> #P window linecount 1;
> #P comment 61 21 97 1376280 VelDyn;
> #P window setfont "Sans Serif" 9.;
> #P comment 60 50 121 196617 Author: Gary Lee Nelson;
> #P newex 19 101 38 196617 / 10.;
> #P outlet 19 150 15 0;
> #P newex 19 125 140 196617 expr ($f1*$f1)*126.0+1.0;
> #P connect 6 0 2 0;
> #P connect 0 0 1 0;
> #P connect 2 0 0 0;
> #P window clipboard copycount 7;
>
>
> Cheers
> Gary Lee Nelson
> Oberlin College
> www.timara.oberlin.edu/GaryLeeNelson
>
> On 10/21/07 7:43 AM, "Ole Schmidt"  wrote:
>
> >
> > Quote: lorenzo.pagliei wrote on Sun, 21 October 2007 12:44
> > ----------------------------------------------------
> >
> >
> >> If you need to tune your mtof you find an ej.mtof in the ejies where
> >> you can give your diapason as an argument
> >
> > ----------------------------------------------------
> >
> > thank you for that too!!
> >
> > ole
>
>
>
>

> {SinOsc.ar(Line.ar(48, 87, 1170).midicps, mul: 0.4)!2}.play

> in SC3 should work, I guess. It sounds smooth for me.

When doing some patch (or code) for a piece with instrumentists, you 

should never forget that the performer will probably want to start from 

different parts of the piece during rehearsals.

It's easy for Lucier's piece, but can sometimes be a real nightmare...

> {SinOsc.ar(Line.ar(48, 87, 1170).midicps, mul: 0.4)!2}.play
>
> in SC3 should work, I guess. It sounds smooth for me.

When doing some patch (or code) for a piece with instrumentists, you 
should never forget that the performer will probably want to start from 
different parts of the piece during rehearsals.

Perhaps recording it with the SC3 solution then playback can be time

On 10/21/07 11:25 AM, "Patrick Delges" wrote:

Lucier-sine wave glissando-math