cps2pch vs cpspch

Having remarked on the lookup table inaccuracy of the Csound cpspch function, I thought I should note that Csound also has a cps2pch function, which dispenses with the lookup table and is more accurate. So that, presumably, settles that. Aaron might want to consider using it in place of Python.

--- In MakeMicroMusic@yahoogroups.com, "genewardsmith" <genewardsmith@...> wrote:

> So that, presumably, settles that. Aaron might want to consider using it in place of Python.

Or maybe not. While cpspch is a function call, cps2pch is a command line, so you can't just do a global swap and replace. Were these people drunk when they came up with that one?

cps2pch can run from any csound front end and can be 'substituted' for cpspch, so long as the arguments and p-fields are modified. cps2pch can also read a table.  Not sure about the accuracy debate: f-tables (wavetables) can be very accurate if yo give them enough resolution. The author (John ffitch) could shed some light on the accuracy of the conversion within the opcode itself. If it does turn out to be lo-res - then another viable tuning method in Csound is to use macros - it's tedious but resolution is not a problem

Rich Duckworth

Lecturer in Music Technology

Department of Music

House 5

Trinity College

Dublin 2

Ireland

Tel 353 1 896 1500

It's the most devastating moment in a young mans life, when he quite reasonably says to himself, "I shall never play The Dane!"

--- On Mon, 4/4/11, genewardsmith <genewardsmith@...> wrote:

From: genewardsmith <genewardsmith@...>
Subject: [MMM] Re: cps2pch vs cpspch
To: MakeMicroMusic@yahoogroups.com
Date: Monday, 4 April, 2011, 2:44

--- In MakeMicroMusic@yahoogroups.com, "genewardsmith" <genewardsmith@...> wrote:

> So that, presumably, settles that. Aaron might want to consider using it in place of Python.

Or maybe not. While cpspch is a function call, cps2pch is a command line, so you can't just do a global swap and replace. Were these people drunk when they came up with that one?

[Non-text portions of this message have been removed]

I happily avoid altogether such debates, and use HZ. Of course my front-end
knows about JI and EDOs, which makes it easy for the user of the front
end--who carees what happens under the hood, as long as it works and is
efficient.

I have zero interest in trying to prove a point about whether Csound's
pitch-conversion opcodes are accurate enough---we all know HZ to an
arbitrary decimal are pretty accurate! :)

AKJ

On Mon, Apr 4, 2011 at 3:15 AM, richard duckworth
<richduckworth@...>wrote:

> cps2pch can run from any csound front end and can be 'substituted' for
> cpspch, so long as the arguments and p-fields are modified. cps2pch can also
> read a table. Not sure about the accuracy debate: f-tables (wavetables) can
> be very accurate if yo give them enough resolution. The author (John ffitch)
> could shed some light on the accuracy of the conversion within the opcode
> itself. If it does turn out to be lo-res - then another viable tuning method
> in Csound is to use macros - it's tedious but resolution is not a problem
>
> Rich Duckworth
>
> Lecturer in Music Technology
>
> Department of Music
>
> House 5
>
> Trinity College
>
> Dublin 2
>
> Ireland
>
>
>
> Tel 353 1 896 1500
>
>
>
> It's the most devastating moment in a young mans life, when he quite
> reasonably says to himself, "I shall never play The Dane!"
>
> --- On Mon, 4/4/11, genewardsmith <genewardsmith@...> wrote:
>
> From: genewardsmith <genewardsmith@...>
> Subject: [MMM] Re: cps2pch vs cpspch
> To: MakeMicroMusic@yahoogroups.com
> Date: Monday, 4 April, 2011, 2:44
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
> --- In MakeMicroMusic@yahoogroups.com, "genewardsmith" <genewardsmith@...>
> wrote:
>
>
>
> > So that, presumably, settles that. Aaron might want to consider using it
> in place of Python.
>
>
>
> Or maybe not. While cpspch is a function call, cps2pch is a command line,
> so you can't just do a global swap and replace. Were these people drunk when
> they came up with that one?
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
> [Non-text portions of this message have been removed]
>
>
>
> ------------------------------------
>
> Yahoo! Groups Links
>
>
>
>

--
Aaron Krister Johnson
http://www.akjmusic.com
http://www.untwelve.org

[Non-text portions of this message have been removed]

--- In MakeMicroMusic@yahoogroups.com, richard duckworth <richduckworth@...> wrote:
>
> cps2pch can run from any csound front end and can be 'substituted' for cpspch, so long as the arguments and p-fields are modified.

Which is another way of saying it's useless as a quick fix. I tested 440*semitone(x-69) as a replacement for cpspch, and it also had accuracy problems. I suppose I could try 440*2^((x-69)/12) but at this point I'm beginning to suspect that Csound functions are consistently screwed up.

cps2pch can also read a table.  Not sure about the accuracy debate: f-tables (wavetables) can be very accurate if yo give them enough resolution. The author (John ffitch) could shed some light on the accuracy of the conversion within the opcode itself. If it does turn out to be lo-res - then another viable tuning method in Csound is to use macros - it's tedious but resolution is not a problem

Can you explain how that would work? And which Csound functions do I use for an f-table--I would need something which is *not* screwed up, and if I knew which functions those were, I could use them directly.

--- In MakeMicroMusic@yahoogroups.com, Aaron Krister Johnson <aaron@...> wrote:

> I have zero interest in trying to prove a point about whether Csound's
> pitch-conversion opcodes are accurate enough---we all know HZ to an
> arbitrary decimal are pretty accurate! :)

What do you mean by "arbitrary"? 32 bit floats? 64 bit floats? How do you know?

>
>
>
Gene, it appears your email client strips all quoting away, which makes it
very confusing sometimes to see who wrote what!

On Mon, Apr 4, 2011 at 3:27 PM, genewardsmith
<genewardsmith@...>wrote:

>
>
> --- In MakeMicroMusic@yahoogroups.com, richard duckworth <richduckworth@...>
> wrote:
> >
> > cps2pch can run from any csound front end and can be 'substituted' for
> cpspch, so long as the arguments and p-fields are modified.
>
> Which is another way of saying it's useless as a quick fix. I tested
> 440*semitone(x-69) as a replacement for cpspch, and it also had accuracy
> problems. I suppose I could try 440*2^((x-69)/12) but at this point I'm
> beginning to suspect that Csound functions are consistently screwed up.
>
>
> cps2pch can also read a table. Not sure about the accuracy debate:
f-tables
> (wavetables) can be very accurate if yo give them enough resolution. The
author \
>(John ffitch) could shed some light on the accuracy of the conversion
within the opcode > itself. If it does turn out to be lo-res - then
another viable tuning method in Csound is to
> use macros - it's tedious but resolution is not a problem

> Can you explain how that would work? And which Csound functions do I use
> for an f-table--I would need something which is *not* screwed up, and if I
> knew which functions those were, I could use them directly.
>
>
>
You need to read the manual under "Table Access" to find out what to do.
Sounds like 'table' opcode but without normalization. There's also a
specialized opcode for reading tables for the purpose of defining a
pitch--'cpstuni'

http://www.csounds.com/manual/html/cpstuni.html

In general, Gene, it would be a good idea to thoroughly read the manual or
Google for answers first before inquiring here...if you notice, most of the
answers that go deeper into these issues that I give are links to Csound
manual pages. You ought thoroughly peruse the table of contents of the
manual, it's well divided into logical concepts, including concepts relating
to the use of pitch and tuning opcodes. :)

AKJ
Aaron Krister Johnson
http://www.akjmusic.com
http://www.untwelve.org

[Non-text portions of this message have been removed]

Either way, 32-bit or 64-bit floats are good enough for me, provided they
are in HZ.

I'd have to check again the frequency resolution in HZ; I'm not sure it has
limits in fact.

AKJ

On Mon, Apr 4, 2011 at 3:32 PM, genewardsmith
<genewardsmith@...>wrote:

>
>
> --- In MakeMicroMusic@yahoogroups.com, Aaron Krister Johnson <aaron@...>
> wrote:
>
> > I have zero interest in trying to prove a point about whether Csound's
> > pitch-conversion opcodes are accurate enough---we all know HZ to an
> > arbitrary decimal are pretty accurate! :)
>
> What do you mean by "arbitrary"? 32 bit floats? 64 bit floats? How do you
> know?
>
>
>
>
>
> ------------------------------------
>
> Yahoo! Groups Links
>
>
>
>

--
Aaron Krister Johnson
http://www.akjmusic.com
http://www.untwelve.org

[Non-text portions of this message have been removed]

--- In MakeMicroMusic@yahoogroups.com, Aaron Krister Johnson <aaron@...> wrote:
bles) can be very accurate if yo give them enough resolution. The
> author \
> >(John ffitch) could shed some light on the accuracy of the conversion
> within the opcode > itself. If it does turn out to be lo-res - then
> another viable tuning method in Csound is to
> > use macros - it's tedious but resolution is not a problem
>
>
> > Can you explain how that would work? And which Csound functions do I use
> > for an f-table--I would need something which is *not* screwed up, and if I
> > knew which functions those were, I could use them directly.
> >

> Sounds like 'table' opcode but without normalization. There's also a
> specialized opcode for reading tables for the purpose of defining a
> pitch--'cpstuni'

That still leaves me with the same question--which mathematical functions are not screwed up to start with which I can use in a table?

> In general, Gene, it would be a good idea to thoroughly read the manual or
> Google for answers first before inquiring here...

I can't trust the manual. It mislead me on the -W flag, and it mislead me on the definition of the semitone function.

There's no way around it - the manual must be read.

"That still leaves me with the same question--which mathematical
functions are not screwed up to start with which I can use in a table?"

what does this mean?  F-tables are reserved locations in memory that can be used to store functions created by subroutines called Gens. The syntax of the f-table is as follows:
f  p1 p2 p3 p4 (p5)  (p6)  (p7).................. where pn represents a parameter field

the first three are reserved: p1 is a unique number for the f-table, p2 is the start time (always 0, pretty much), and p3 is the size of the table in power-of-2 or power-of-two +1  

p4 is the Gen number and the fields after this one vary depending on which of the 50-odd Gens you use. You can't subsitute one Gen for another and expect it to work. Similarly one opcode can't be substituted for another w/o checking to see if the arguments are compatible (in the manual!) 

the size of the table will affect the resolution - so I make 'em big if I'm doing audio work, or working with an application which demands precision. 

If your question means 'Which of the Gens draw inaccurate functions?' then I'd have to say 'I don't know' or 'None of them' .  I mean, if your table size is 256 or 512, you're not going to get much resolution. The opcode using the f-table can have limitations too, hence my advice to contact the author (the author of an opcode is usually found at the bottom of the opcode manual entry)

BTW I use Pure Data to create my microtonal scales - though I did my masters in Csound microtuning.   

Rich Duckworth

Lecturer in Music Technology

Department of Music

House 5

Trinity College

Dublin 2

Ireland

Tel 353 1 896 1500

It's the most devastating moment in a young mans life, when he quite reasonably says to himself, "I shall never play The Dane!"

--- On Mon, 4/4/11, genewardsmith <genewardsmith@sbcglobal.net> wrote:

From: genewardsmith <genewardsmith@...>
Subject: [MMM] Re: cps2pch vs cpspch
To: MakeMicroMusic@yahoogroups.com
Date: Monday, 4 April, 2011, 22:09

--- In MakeMicroMusic@yahoogroups.com, Aaron Krister Johnson <aaron@...> wrote:

bles) can be very accurate if yo give them enough resolution. The

> author \

> >(John ffitch) could shed some light on the accuracy of the conversion

> within the opcode > itself. If it does turn out to be lo-res - then

> another viable tuning method in Csound is to

> > use macros - it's tedious but resolution is not a problem

>

>

> > Can you explain how that would work? And which Csound functions do I use

> > for an f-table--I would need something which is *not* screwed up, and if I

> > knew which functions those were, I could use them directly.

> >

> Sounds like 'table' opcode but without normalization. There's also a

> specialized opcode for reading tables for the purpose of defining a

> pitch--'cpstuni'

That still leaves me with the same question--which mathematical functions are not screwed up to start with which I can use in a table?

> In general, Gene, it would be a good idea to thoroughly read the manual or

> Google for answers first before inquiring here...

I can't trust the manual. It mislead me on the -W flag, and it mislead me on the definition of the semitone function.

[Non-text portions of this message have been removed]

--- In MakeMicroMusic@yahoogroups.com, richard duckworth <richduckworth@...> wrote:
>
> There's no way around it - the manual must be read.

No doubt, but that opens the door to the sorry fact of how much Csound sucks. I used the Csound print function, which sucks, to test whether this worked as a replacement for cpspch:

440 * semitone(12 * floor(ix) + 100 * frac(ix) - 105)

I used the Csound print function, which sucks, to test it, but I wanted more accuracy. Apparently, according to the manual, I need to use the printks function to print in C format. Of course, it's not actually in C format and it really, really, really sucks. Plus, Csound or Qute or some damned thing attacked the csd file I was using to test with, tossing in all kinds of crazy stuff about Macs and killing newline characters. I could not get it to work.

I don't buy the idea that my problems with Csound are all my fault, popular though it may be.

printks works fine on my machine with the %f and %f\\n print codes.

also, I doubt this will work:

 440 * semitone(12 * floor(ix) + 100 * frac(ix) - 105)

as you're nesting your opcodes, using opcodes as the arguments for [semitone]. Usually each opcode has it's own line, and user-defined variables are utilised to move values around from line-to-line. Even if it does work, it's not best practice as it means that the code will be harder to debug.
the [expr] expression function in pure data would give you real-time implementation of your formula with full 64-bit fp precision. Of course, you'll have to read the manual for that too.

Rich Duckworth

Lecturer in Music Technology

Department of Music

House 5

Trinity College

Dublin 2

Ireland

Tel 353 1 896 1500

It's the most devastating moment in a young mans life, when he quite reasonably says to himself, "I shall never play The Dane!"

--- On Tue, 5/4/11, genewardsmith <genewardsmith@sbcglobal.net> wrote:

From: genewardsmith <genewardsmith@...>
Subject: [MMM] Re: cps2pch vs cpspch
To: MakeMicroMusic@yahoogroups.com
Date: Tuesday, 5 April, 2011, 1:14

--- In MakeMicroMusic@yahoogroups.com, richard duckworth <richduckworth@...> wrote:

>

> There's no way around it - the manual must be read.

No doubt, but that opens the door to the sorry fact of how much Csound sucks. I used the Csound print function, which sucks, to test whether this worked as a replacement for cpspch:

440 * semitone(12 * floor(ix) + 100 * frac(ix) - 105)

I used the Csound print function, which sucks, to test it, but I wanted more accuracy. Apparently, according to the manual, I need to use the printks function to print in C format. Of course, it's not actually in C format and it really, really, really sucks. Plus, Csound or Qute or some damned thing attacked the csd file I was using to test with, tossing in all kinds of crazy stuff about Macs and killing newline characters. I could not get it to work.

I don't buy the idea that my problems with Csound are all my fault, popular though it may be.

[Non-text portions of this message have been removed]

On 4 April 2011 05:44, genewardsmith <genewardsmith@...> wrote:
>
>
> --- In MakeMicroMusic@yahoogroups.com, "genewardsmith" <genewardsmith@...> wrote:
>
>> So that, presumably, settles that. Aaron might want to consider using it in place of Python.
>
> Or maybe not. While cpspch is a function call, cps2pch is a command line, so you can't just do a global swap and replace. Were these people drunk when they came up with that one?

Upon investigating, it seems that cps2pch takes two arguments but
cpspch takes one. That would explain the difference.

Two mysteries remain: why an opcode that converts from pitch to cps
read as "cps to pitch" and why a Csound newbie is giving Aaron
lectures about a problem he doesn't have.

Graham

Two mysteries remain: why an opcode that converts from pitch to cps

read as "cps to pitch" and why a Csound newbie is giving Aaron

lectures about a problem he doesn't have.

I can explain the first mystery: csound orchestra  code reads from right to left*: the pfield value is input to the opcode via the argument and the conversion appears on the output and is placed in the user-defined variable 'icps' (this can be 'i' anything, iherz, inote - the i prefix tags it as an instrument rate variable, or one that occurs each time a note is played). It makes sense and is consistent. 

p, li { white-space: pre-wrap; }

icps = cpspch(ipch)
Note: the score reads from left to right

As far as the second mystery goes........ I just don't know

Rich Duckworth

Lecturer in Music Technology

Department of Music

House 5

Trinity College

Dublin 2

Ireland

Tel 353 1 896 1500

It's the most devastating moment in a young mans life, when he quite reasonably says to himself, "I shall never play The Dane!"

--- On Tue, 5/4/11, Graham Breed <gbreed@...> wrote:

From: Graham Breed <gbreed@...>
Subject: Re: [MMM] Re: cps2pch vs cpspch
To: MakeMicroMusic@yahoogroups.com
Date: Tuesday, 5 April, 2011, 10:30

On 4 April 2011 05:44, genewardsmith <genewardsmith@sbcglobal.net> wrote:

>

>

> --- In MakeMicroMusic@yahoogroups.com, "genewardsmith" <genewardsmith@...> wrote:

>

>> So that, presumably, settles that. Aaron might want to consider using it in place of Python.

>

> Or maybe not. While cpspch is a function call, cps2pch is a command line, so you can't just do a global swap and replace. Were these people drunk when they came up with that one?

Upon investigating, it seems that cps2pch takes two arguments but

cpspch takes one. That would explain the difference.

Two mysteries remain: why an opcode that converts from pitch to cps

read as "cps to pitch" and why a Csound newbie is giving Aaron

lectures about a problem he doesn't have.

Graham

[Non-text portions of this message have been removed]

On 5 April 2011 00:32, genewardsmith <genewardsmith@...> wrote:
>
> --- In MakeMicroMusic@yahoogroups.com, Aaron Krister Johnson <aaron@...> wrote:
>
>> I have zero interest in trying to prove a point about whether Csound's
>> pitch-conversion opcodes are accurate enough---we all know HZ to an
>> arbitrary decimal are pretty accurate! :)
>
> What do you mean by "arbitrary"? 32 bit floats? 64 bit floats? How do you know?

You know because you'll have installed a float or double version of
Csound. The double version is preferred, and the resolution depends
on how it was compiled. I believe that's 64-bit. If you want a
higher level of certainty than that you'll either have to post on the
Csound list or read the source code.

I did a quick Google search, and found this thread, which mentions
your problem with cps2pch but doesn't suggest a reason for it:

http://csound.1045644.n5.nabble.com/roundoff-errors-in-cpspch-td1120073.html

It also has example code for printing the examples. That could have
saved you a bit of heartache. And those examples show an 18 millicent
error between the first pair of values. Is that what you're worrying
about?

If you want functions you can trust, the best bet is to choose those
that are obviously wrappers around C library functions. Occam's razor
tells you they'll probably have the same precision as in C.

If you're starting from the Silence Orchestra (CsoundAC.csd) there are
only two places you need to change the pitch conversion -- in the
NoteOn opcode. You don't need to worry about macros or global search
and replace.

While I'm posting I'll make another observation: that NoteOn opcode
can also be changed to pass Hz through directly. The reason that the
Silence Orchestra uses MIDI pitch is to get MIDI compatibility.
That's certainly worth doing for a standard orchestra because some
people are going to want to use it with MIDI. (If you don't want
pitch bend tuning, NoteOn is also a good place to implement a tuning
table.) Instruments that expect Hz can easily be converted to Silence
format by adding NoteOn. And if you want to use the Silence Format
with Hz input, you can make the above change. (Instruments that work
with MIDI pitch directly won't work, but aren't likely to work
microtonally anyway.)

Graham

Incidentally, I found the old Csound discussion about this inaccuracy.
Here's a thread where everyone (including me) suggested fixing it:

http://csound.1045644.n5.nabble.com/csoundapi-relative-paths-td1107912.html#a1107913

And here's another branch that starts with an argument in favor of
documenting the status quo:

http://csound.1045644.n5.nabble.com/csoundapi-relative-paths-td1107912i20.html

The last message there seems very intelligent and well reasoned to me.
I don't know why the decision was made to change the documentation
instead of the implementation. I don't remember, and haven't found,
anybody claiming to have measured an increase in efficiency. But the
decision was made and we have to live with it.

Graham

There was also a lengthy discussion about this on the Csound developers list
a while back:
http://csound.1045644.n5.nabble.com/Inaccuracies-in-cpspch-and-cpsoct-td1130909.html

Scanning the thread quickly, looks like the majority wanted to simply change
cpspch (and cpsoct) to be more accurate. Even issues of backward
compatibility were questionable, as the 'table lookup' method seemed to be
introduced later.

Interestingly, there was a post from Gabriel Maldonaldo which mentions:
The same issue is to be applied to powoftwo, octave, semitone and cent
opcodes... All of them are based on table lookup instead of direct power
calculation.

But... I can't see any Csound release notes which mention anything being
fixed.

Say.... anyone want to raise this on the Csound list? They seem to be taking
suggestions.

T

On Tue, Apr 5, 2011 at 9:32 PM, Graham Breed <gbreed@...> wrote:

>
>
> Incidentally, I found the old Csound discussion about this inaccuracy.
> Here's a thread where everyone (including me) suggested fixing it:
>
>
> http://csound.1045644.n5.nabble.com/csoundapi-relative-paths-td1107912.html#a1107913
>
> And here's another branch that starts with an argument in favor of
> documenting the status quo:
>
>
> http://csound.1045644.n5.nabble.com/csoundapi-relative-paths-td1107912i20.html
>
> The last message there seems very intelligent and well reasoned to me.
> I don't know why the decision was made to change the documentation
> instead of the implementation. I don't remember, and haven't found,
> anybody claiming to have measured an increase in efficiency. But the
> decision was made and we have to live with it.
>
> Graham
>
>

[Non-text portions of this message have been removed]

--- In MakeMicroMusic@yahoogroups.com, richard duckworth <richduckworth@...> wrote:

> also, I doubt this will work:
>
>  440 * semitone(12 * floor(ix) + 100 * frac(ix) - 105)

Thanks. It seems clear AKJ has the right idea--modifying an orchestra either to work on my ideal terms or trying to get it to work right on its own terms if it uses cpspch are both bad ideas, and the function should simply be removed wherever it appears.

--- In MakeMicroMusic@yahoogroups.com, Graham Breed <gbreed@...> wrote:

> Two mysteries remain: why an opcode that converts from pitch to cps
> read as "cps to pitch" and why a Csound newbie is giving Aaron
> lectures about a problem he doesn't have.

There is, of course, no mystery why you are falsely claiming I'm giving Aaron lectures on anything. Graham Breed, stirring up shit.

--- In MakeMicroMusic@yahoogroups.com, thorin kerr <thorin.kerr@...> wrote:

> Interestingly, there was a post from Gabriel Maldonaldo which mentions:
> The same issue is to be applied to powoftwo, octave, semitone and cent
> opcodes... All of them are based on table lookup instead of direct power
> calculation.

That's what I had begun to suspect after printing some values. It's not documented, so the refrain of RTFM as if that will solve all problems is misplaced. Functions which are going to simply call a C function are the only ones you can trust, apparently; anything adapted to a musical purpose is likely to be a bit off.

Hey Graham,

On Tue, Apr 5, 2011 at 4:30 AM, Graham Breed <gbreed@...> wrote:

> On 4 April 2011 05:44, genewardsmith <genewardsmith@...> wrote:
> >
> >
> > --- In MakeMicroMusic@yahoogroups.com, "genewardsmith" <genewardsmith@...>
> wrote:
> >
> >> So that, presumably, settles that. Aaron might want to consider using it
> in place of Python.
> >
> > Or maybe not. While cpspch is a function call, cps2pch is a command line,
> so you can't just do a global swap and replace. Were these people drunk when
> they came up with that one?
>
> Upon investigating, it seems that cps2pch takes two arguments but
> cpspch takes one. That would explain the difference.
>
> Two mysteries remain: why an opcode that converts from pitch to cps
> read as "cps to pitch"

That's always bugged me too, but then I thought maybe the reason was that
outputs in Csound code are to the *left* of the opcode that produces them.
Probably a way to be consistent, but it is admittedly quite confusing.

Reminds me of a t-shirt I saw yesterday: "Eschew Obfuscation" LOL

> and why a Csound newbie is giving Aaron
> lectures about a problem he doesn't have.
>
>
Again, I haven't figured that one out yet. I'm going to write him offlist.

AKJ
---
Aaron Krister Johnson
http://www.akjmusic.com
http://www.untwelve.org

[Non-text portions of this message have been removed]

I think Graham was pointing out that spending time worrying about cps2pch
and the like where it is irrelevant in software like microcsound, which
works, and uses HZ, is a waste of precious emotional energy.

I agree that the Csound pitch opcodes are wanting---for those who demand
near atomic accuracy. Using HZ is better. Done.

Of course, there's an aesthetic pain to know that there is an ugly useless
layer to the Csound language, but we acknowledge and move on...I'm not
mocking--I understand and share this sentiment--I sometimes think it would
be nice to have a simpler miniature subset of Csound, one where we could
even avoid the score layer altogether, or define a new custom score syntax,
but I digress...

AKJ

On Tue, Apr 5, 2011 at 8:35 AM, genewardsmith
<genewardsmith@...>wrote:

>
>
> --- In MakeMicroMusic@yahoogroups.com, Graham Breed <gbreed@...> wrote:
>
> > Two mysteries remain: why an opcode that converts from pitch to cps
> > read as "cps to pitch" and why a Csound newbie is giving Aaron
> > lectures about a problem he doesn't have.
>
> There is, of course, no mystery why you are falsely claiming I'm giving
> Aaron lectures on anything. Graham Breed, stirring up shit.
>
>
>
> ------------------------------------
>
> Yahoo! Groups Links
>
>
>
>

--
Aaron Krister Johnson
http://www.akjmusic.com
http://www.untwelve.org

[Non-text portions of this message have been removed]

Hey Gene,

On Tue, Apr 5, 2011 at 8:33 AM, genewardsmith
<genewardsmith@sbcglobal.net>wrote:

>
>
> --- In MakeMicroMusic@yahoogroups.com, richard duckworth <richduckworth@...>
> wrote:
>
> > also, I doubt this will work:
> >
> > Â 440 * semitone(12 * floor(ix) + 100 * frac(ix) - 105)
>
> Thanks. It seems clear AKJ has the right idea--modifying an orchestra
> either to work on my ideal terms or trying to get it to work right on its
> own terms if it uses cpspch are both bad ideas, and the function should
> simply be removed wherever it appears.
>
>
>
I think you're starting to see my point---in the end, you'll just be
frustrated with the built-in opcodes for pitch translation. I agree that
it's not ideal. The best path to flexible accurate pitch in my experience
was and always will be, barring code improvements in those opcodes,
specifying cps in HZ to your instruments.

The good news is that you can do this now, and stop worrying about it! :D

--
Aaron Krister Johnson
http://www.akjmusic.com
http://www.untwelve.org

[Non-text portions of this message have been removed]

"genewardsmith" <genewardsmith@...> wrote:
>
> --- In MakeMicroMusic@yahoogroups.com, richard duckworth
> <richduckworth@...> wrote:
> >
> > cps2pch can run from any csound front end and can be
> > 'substituted' for cpspch, so long as the arguments and
> > p-fields are modified.
>
> Which is another way of saying it's useless as a quick
> fix. I tested 440*semitone(x-69) as a replacement for
> cpspch, and it also had accuracy problems. I suppose I
> could try 440*2^((x-69)/12) but at this point I'm
> beginning to suspect that Csound functions are
> consistently screwed up.

This discussion has died down, but still, I've been
researching it. I have Csound version 5.10 (double
samples) and the source code to 5.11.1. In neither case do
I see any problem with cps2pch. Here's a simple instrument
to test it:

instr PrintPitch
icps cps2pch p4, 12
isemis = log(icps/440)/log(2)*12
icents = (isemis - round(isemis))*100
imcents = icents*1000
print p4
print icps
print isemis
print icents
print imcents
endin

And some score examples:

i "PrintPitch" 0.1 0.1 8.00
i "PrintPitch" 0.2 0.1 8.01
i "PrintPitch" 0.3 0.1 8.02
i "PrintPitch" 0.4 0.1 8.03
i "PrintPitch" 0.5 0.1 8.04

It's doing accurate conversions, but not to A=440Hz.
That's because there's a literal in aops.c (line 727 my
copy) where it should be referencing ONEPT in csoundCore.h.

This is of limited use if what you wanted was MIDI key to
Hz because the input is Csound's "pitch class" format.
There doesn't seem to be an accurate MIDI key to Hz
function or opcode.

The bizarre thing, at least back in 5.11.1, is that as well
as the 8192 entry lookup table for pitch conversions
(csoundCore.h, lines 84-5) there's a 4096 entry lookup
table in aops.c for the pow2 function. This is used by
powoftwo (long documented to be inaccurate) but also
semitone, cent, and db. So, yes, the opcode specifically
designed for working with cents only has a resolution of a
third of a cent. Annoying but all work-aroundable once
you've ferreted out the problems.

I'm guessing the --midi-key-cps argument to the application
is also inaccurate. Probably we don't care because we
won't be starting from an equally tempered MIDI
performance. MIDI keys seem to be the way to go for MIDI
compatibility. Then we can substitute tuning tables if we
desire them.

Graham

So, in summary, HZ are still the way to go for best accuracy overall
when *not* using MIDI, right?

AKJ

On Fri, Apr 8, 2011 at 3:19 AM, Graham Breed <gbreed@...> wrote:
> "genewardsmith" <genewardsmith@...> wrote:
>>
>> --- In MakeMicroMusic@yahoogroups.com, richard duckworth
>> <richduckworth@...> wrote:
>> >
>> > cps2pch can run from any csound front end and can be
>> > 'substituted' for cpspch, so long as the arguments and
>> > p-fields are modified.
>>
>> Which is another way of saying it's useless as a quick
>> fix. I tested 440*semitone(x-69) as a replacement for
>> cpspch, and it also had accuracy problems. I suppose I
>> could try 440*2^((x-69)/12) but at this point I'm
>> beginning to suspect that Csound functions are
>> consistently screwed up.
>
> This discussion has died down, but still, I've been
> researching it.  I have Csound version 5.10 (double
> samples) and the source code to 5.11.1.  In neither case do
> I see any problem with cps2pch.  Here's a simple instrument
> to test it:
>
>        instr PrintPitch
> icps    cps2pch p4, 12
> isemis  =       log(icps/440)/log(2)*12
> icents  =       (isemis - round(isemis))*100
> imcents =       icents*1000
>        print   p4
>        print   icps
>        print   isemis
>        print   icents
>        print   imcents
>        endin
>
> And some score examples:
>
> i "PrintPitch" 0.1 0.1 8.00
> i "PrintPitch" 0.2 0.1 8.01
> i "PrintPitch" 0.3 0.1 8.02
> i "PrintPitch" 0.4 0.1 8.03
> i "PrintPitch" 0.5 0.1 8.04
>
> It's doing accurate conversions, but not to A=440Hz.
> That's because there's a literal in aops.c (line 727 my
> copy) where it should be referencing ONEPT in csoundCore.h.
>
> This is of limited use if what you wanted was MIDI key to
> Hz because the input is Csound's "pitch class" format.
> There doesn't seem to be an accurate MIDI key to Hz
> function or opcode.
>
> The bizarre thing, at least back in 5.11.1, is that as well
> as the 8192 entry lookup table for pitch conversions
> (csoundCore.h, lines 84-5) there's a 4096 entry lookup
> table in aops.c for the pow2 function.  This is used by
> powoftwo (long documented to be inaccurate) but also
> semitone, cent, and db.  So, yes, the opcode specifically
> designed for working with cents only has a resolution of a
> third of a cent.  Annoying but all work-aroundable once
> you've ferreted out the problems.
>
> I'm guessing the --midi-key-cps argument to the application
> is also inaccurate.  Probably we don't care because we
> won't be starting from an equally tempered MIDI
> performance.  MIDI keys seem to be the way to go for MIDI
> compatibility.  Then we can substitute tuning tables if we
> desire them.
>
>
>                         Graham
>
>
> ------------------------------------
>
> Yahoo! Groups Links
>
>
>
>

--
Aaron Krister Johnson
http://www.akjmusic.com
http://www.untwelve.org

Aaron Krister Johnson <aaron@...> wrote:
> So, in summary, HZ are still the way to go for best
> accuracy overall when *not* using MIDI, right?

Hz are the way to go if you want Hz. If you want pitch
envelopes or vibrato with envelopes defined in cents, you
have to run the lookup table gauntlet. But, even then,
multiplying your target pitch by a modulation variable is
going to be correct when that modulation's converted
from zero. (It doesn't matter much otherwise, right?)

The alternative is to convert from Hz to pitch units, add
the modulation variable, and then convert back to Hz. Then
you have to check your functions are accurate.

As a final, desperate attempt to turn an obvious answer
into an intelligent one, I'll mention that a small amount
of vibrato or pitch-noise might actually help to correct
the perceived pitch. It should be about the same size as
the resolution of the tables you're using. Here's a
helpful link:

http://en.wikipedia.org/wiki/Stochastic_resonance

Graham

See also:

http://apc.psych.umn.edu/Pdfs/Publications/Bernstein_Oxenham_Grouping_Pitch_JASA_2008.pdf

-Mike

On Fri, Apr 8, 2011 at 12:45 PM, Graham Breed <gbreed@...> wrote:
>
> Aaron Krister Johnson <aaron@...> wrote:
> > So, in summary, HZ are still the way to go for best
> > accuracy overall when *not* using MIDI, right?
>
> Hz are the way to go if you want Hz. If you want pitch
> envelopes or vibrato with envelopes defined in cents, you
> have to run the lookup table gauntlet. But, even then,
> multiplying your target pitch by a modulation variable is
> going to be correct when that modulation's converted
> from zero. (It doesn't matter much otherwise, right?)
>
> The alternative is to convert from Hz to pitch units, add
> the modulation variable, and then convert back to Hz. Then
> you have to check your functions are accurate.
>
> As a final, desperate attempt to turn an obvious answer
> into an intelligent one, I'll mention that a small amount
> of vibrato or pitch-noise might actually help to correct
> the perceived pitch. It should be about the same size as
> the resolution of the tables you're using. Here's a
> helpful link:
>
> http://en.wikipedia.org/wiki/Stochastic_resonance
>
> Graham

--- In MakeMicroMusic@yahoogroups.com, Graham Breed <gbreed@...> wrote:

> So, yes, the opcode specifically
> designed for working with cents only has a resolution of a
> third of a cent. Annoying but all work-aroundable once
> you've ferreted out the problems.

Thanks. Removing all such code from an instrument still seems he way to go.

I've not had time to read all the posts on Csound, but I've been using it successfully for about 15 years. I've not run into the problem with pitch accuracy, but these are areas of Csound that I haven't touched for at least ten years. I use a table lookup function to convert the relative note number (nowadays it's 0 to 72 tone per octave) into a fractional value, which is converted into a pitch using cpspch(octave + pitch).

I create a k value for the pitch, which can change during the note play time. I multiply that k value by another glissando value, so that the pitch can change (or not) during the note play time. This set of values then is the input to the waveform generation opcode. The glissando value can also be used for vibrato, trills, or frequency manipulation as needed.

I also work hard on the envelope for each note. You would be surprised how important something as simple as an envelope can be, and how subtle changes in while playing make instruments more human. And each channel doesn't need to have the same envelope. It's not as if musicians stand still while they play, after all.

Finally, the control over the overlap of one note to the next is critical as well. Don't assume that you should start one note when the other one ends. Millisecond changes in overlaps make another humanization factor. There is a whole world between Legato vs stacatto.

I use orchestral samples for all my instruments, but I've gotten some interesting results using plain Sine waves as well. It's amazing how much variety you can get by manipulating pitch, envelope, glissando, trills, and legato without actual orchestral samples.

Here's the Csound input I use for my realization of the first few measures of Ben Johnston's String Quartet #7 movement 3: "Variations". It requires some carefully tuned string instrument samples to realize. It took me several months to tune the three sample libraries. I made sure that the highest vibrato point for each note is the right pitch. The sample libraries are never very accurate.

By looking at this Csound source, you might be able to see how the table lookups work to simplify the pitch selections. In the first five measures, Johnston has already used 61 distinct pitches. You can hear it here: http://dailynoise.tumblr.com/

; name: johns1 3/08/11 1:51pm
;
; Album Title: String Quartet Number 7
; Composer: Ben Johnston
;
; Orchestra:
; String Quartet
<CsoundSynthesizer>

<CsOptions>
-W -G -m2 -+y -o sflib\johns1.wav
</CsOptions>

<CsInstruments>
sr = 44100
ksmps = 10; any higher than 10 and I hear clicks - use 1 for final take
; typically save 5x processing time by increasing ksmps by 10x
nchnls = 2
instr 1

; p1 is always 1
; p2 start time
; p3 duration
; p4 velocity, 60-80 works best
; p5 tone - which tone is this note
; p6 Octave
; p7 voice
; p8 stereo - pan from left = 0 to right = 16
; p9 envelope - one of several function tables for envelopes 1 - 16
; p10 glissando - one of several function tables to modify pitch
; p11 upsample - use a sample higher (>0) or lower (<256) than normal
; p12 envelope for right channel - if blank, use the left channel envelope for both channels
;
ifunc table p7,1 ; find the location of the sample wave tables
ioct = p6+1
iwavchan table p7,2 ; is it mono (iwavchan = 1) or stereo sample file (iwavchan = 2)
; or are sustain points in separate table iwavchan=3
inum = 12*(ioct) + int(p5/6) ; convert from octave/pitch to a MIDI note number to pick ftable (root is 72, 72/12 = 6)
ifno2 table inum, ifunc ; map midi note number to the correct ftable for that note
ifno = ifno2 + (p11 < 128 ? p11 : p11-256) ; up or down sample by parameter 11 modulo 256
iamp = ampdb(p4) ; velocity input is 60-80 - convert to amplitude
i9 = 298-p9 ; valid envelope table number are 298, 297, 296, 295 etc. - left channel
i12 = 298-p12 ; valid envelope table number are 298, 297, 296, 295 etc. - right channel
i10 = 301+p10 ; valid glissando table number are 301, 302, etc
; kamp_l poscil iamp, 1/p3, i9 ; create a precise long envelope from a function table for left channel
; kamp_r poscil iamp, 1/p3, i12 ; create a precise long envelope from a function table for right channel
kamp_l oscil iamp, 1/p3, i9 ; create an envelope from a function table for left channel
kamp_r oscil iamp, 1/p3, i12 ; create an envelope from a function table for right channel
kpan_l tablei p8/16, 4, 1,0,1 ; pan with a sine wave using f table #4 - 2st value is reduced to max 1, normalized
kpan_r tablei 1.0 - p8/16, 4, 1,0,1 ; inverse of kpan_l
ibasno table ifno-(3+ifunc), 1 + ifunc ; get midi note number the sample was recorded at
icent table ifno-(3+ifunc), 2 + ifunc ; get cents to flatten each note
iloop table ifno-(3+ifunc), 3 + ifunc ; get loop or not
ibasoct = ibasno/12 ; find the base octave
ibascps = cpsoct(ibasoct+(icent/1200))
ipitch table p5, 3 ; convert note number 0-71 to oct.fract format - hand made table 3 of fractions
inote = cpspch(ioct + ipitch) ; note plus the decimal fraction of a note from table - how precise is this?
print p5, p6, p7, p11, ifno, icent
kcps = cpspch(ioct + ipitch) ; convert oct.fract to Hz
kcpsm oscili 1, 1/p3, i10 ; create an set of shift multiplicands from table - glissandi
kcps2 = kcps * kcpsm ; shift the frequency by values in glissando table
; Four choices: Mono looping, stereo looping, mono no-loop, stereo no-loop
if iwavchan = 4 goto akaimono
if iloop = 0 goto noloops
; Stereo with loop
a3,a4 loscil 1, kcps2, ifno, ibascps; stereo sample with looping
goto skipstereo
noloops:
; Stereo without looping
a3,a4 loscil 1, kcps2, ifno, ibascps,0,1,2 ; stereo sample without looping - note that 1,2 is bogus workaround
goto skipstereo
akaimono:
if iloop = 0 goto noloopm
; Mono with looping
a3 loscil 1, kcps2, ifno, ibascps ; mono sampling with loop
a4 = a3
goto skipstereo
noloopm:
; Mono without looping
a3 loscil 1, kcps2, ifno, ibascps,0,1,2 ; mono AIFF sample without loop
a4 = a3

skipstereo:
; start comparison sine wave oscillator for fine tuning adjustment testing
; ihertz = cpspch(ioct+ipitch) ; what frequency are you trying to make
; a1 oscili 1, kcps*8, 500 ; sine wave to compare the sample frequency to
; a5 = a1 ; + a3 ; add the sample to the sine wave right
; a6 = a4 + a3 ; and left
; a3 = a5
; a4 = a6
; end comparison sine wave oscilator
; start of resonant filter for tuning purposes
;a1 reson a3,kcps*4,20,2
;a2 reson a4,kcps*4,20,2
a1 = a3 * kamp_l
a2 = a4 * kamp_r
;
outs a1 * kpan_l ,a2 * kpan_r
endin

; instr 99
; kamp poscil 1, 1/p3, 1 ; create an envelope from a function table
; a6, a7 soundin "sflib/johns1.wav"
; outs a6 * kamp, a7 * kamp
; endin
</CsInstruments>

<CsScore>
; cents for each step in the scale
; just equivalent to 72 EDO
f3 0 128 -2
0 0.0016667 0.0033333 0.0050000 0.0066667 0.0083333 0.0100000 0.0116667 0.0133333 0.0150000 0.0166667
0.0183333 0.0200000 0.0216667 0.0233333 0.0250000 0.0266667 0.0283333 0.0300000 0.0316667 0.0333333
0.0350000 0.0366667 0.0383333 0.0400000 0.0416667 0.0433333 0.0450000 0.0466667 0.0483333 0.0500000
0.0516667 0.0533333 0.0550000 0.0566667 0.0583333 0.0600000 0.0616667 0.0633333 0.0650000 0.0666667
0.0683333 0.0700000 0.0716667 0.0733333 0.0750000 0.0766667 0.0783333 0.0800000 0.0816667 0.0833333
0.0850000 0.0866667 0.0883333 0.0900000 0.0916667 0.0933333 0.0950000 0.0966667 0.0983333 0.1000000
0.1016667 0.1033333 0.1050000 0.1066667 0.1083333 0.1100000 0.1116667 0.1133333 0.1150000 0.1166667
0.1183333 0.12
f4 0 1025 9 .25 1 0 ;The first quadrant of a sine for panning
f500 0 256 10 1
;lf9 0 256 10 1 ; sine wave
; c4 = 72 = middle C = 60 is MIDI standard number
; g3 = 67
; something is wrong with function table 300
; 1st take 2nd take 3rd take 4th take 5th take 6th take sum of takes = size of table
; these are useful for taking a note up or down an octave without moving the sample up or down - built in munchkinization
f301 0 256 -7 1 256 1 ; g0 = no change;
f302 0 256 -7 1.125 256 1.125 ; g1 up 9/8
f303 0 256 -7 1.25 256 1.25 ; g2 up 5/4
f304 0 256 -7 1.3333 256 1.3333 ; g3 up 4/3
f305 0 256 -7 1.5 256 1.5 ; g4 up 3/2
f306 0 256 -7 .875 256 .875 ; g5 down 7/8
f307 0 256 -7 .5 256 .5 ; g6 down 1 octave
f308 0 256 -7 .25 256 .25 ; g7 down 2 octaves
f309 0 256 -7 .125 256 .125 ; g8 down 3 octaves
f310 0 1024 -7 1 512 1 0 1.125 256 1.125 0 .9000000 256 .9000000 0 ; g9 4 5 3 = A# C Ab
f311 0 1024 -7 1 512 1 0 1.14285714 256 1.14285714 0 .8888889 256 .8888888 0 ; g10 5 6 4 = 11:8 -> 11:7 -> 11:9
f312 0 256 -7 1 256 1.0625; g11 glide up 17/16
f313 0 256 -7 1 256 .9375; g12 glide down 15/16
; Glissando up tables min points mid pts max pts mid pts max pts mid pts min mid max mid min mid max ; glide number Ratio
f314 0 256 -7 1 48 1 128 1 80 1 ; 1:1 g13 up 0
f315 0 256 -7 1 16 1 128 1.02930223664349 112 1.02930223664349 ; 14 up 3 a
f316 0 256 -7 1 16 1 128 1.03925922603184 112 1.03925922603184 ; 15 up 4 a
f317 0 256 -7 1 16 1 128 1.0493125346879 112 1.0493125346879 ; 16 up 5 a
f318 0 256 -7 1 16 1 128 1.0594630943593 112 1.0594630943593 ; 17 up 6 a
f319 0 256 -7 1 16 1 128 1.06971184580696 112 1.06971184580696 ; 18 up 7 a
f320 0 256 -7 1 16 1 128 1.08005973889231 112 1.08005973889231 ; 19 up 8 a
f321 0 256 -7 1 16 1 128 1.09050773266526 112 1.09050773266526 ; 20 up 9 a
f322 0 256 -7 1 16 1 128 1.10105679545314 112 1.10105679545314 ; 21 up 10 a
f323 0 256 -7 1 16 1 128 1.11170790495044 112 1.11170790495044 ; 22 up 11 a
f324 0 256 -7 1 16 1 128 1.12246204830937 112 1.12246204830937 ; 23 up 12 a
f325 0 256 -7 1 16 1 128 1.13332022223144 112 1.13332022223144 ; 24 up 13 a
f326 0 256 -7 1 16 1 128 0.971531941153606 112 0.971531941153606 ; 25 down 3 a
f327 0 256 -7 1 16 1 128 0.962223836894145 112 0.962223836894145 ; 26 down 4 a
f328 0 256 -7 1 16 1 128 0.953004912208957 112 0.953004912208957 ; 27 down 5 a
f329 0 256 -7 1 16 1 128 0.943874312681693 112 0.943874312681693 ; 28 down 6 a
f330 0 256 -7 1 16 1 128 0.934831192082039 112 0.934831192082039 ; 29 down 7 a
f331 0 256 -7 1 16 1 128 0.934831192082039 112 0.934831192082039 ; 30 down 7 a
f332 0 256 -7 1 16 1 128 0.92587471228729 112 0.92587471228729 ; 31 down 8 a
f333 0 256 -7 1 16 1 128 0.91700404320467 112 0.91700404320467 ; 32 down 9 a
f334 0 256 -7 1 16 1 128 0.908218362694402 112 0.908218362694402 ; 33 down 10 a
f335 0 256 -7 1 16 1 128 0.899516856493507 112 0.899516856493507 ; 34 down 11 a
f336 0 256 -7 1 16 1 128 0.890898718140338 112 0.890898718140338 ; 35 down 12 a
f337 0 256 -7 1 16 1 128 0.882363148899842 112 0.882363148899842 ; 36 down 13 a
f338 0 256 -7 1 16 1 128 0.873909357689526 112 0.873909357689526 ; 37 down 14 a
f339 0 256 -7 1 8 1 120 1.02930223664349 128 1.02930223664349 ; 38 up 3 b
f340 0 256 -7 1 8 1 120 1.03925922603184 128 1.03925922603184 ; 39 up 4 b
f341 0 256 -7 1 8 1 120 1.0493125346879 128 1.0493125346879 ; 40 up 5 b
f342 0 256 -7 1 8 1 120 1.0594630943593 128 1.0594630943593 ; 41 up 6 b
f343 0 256 -7 1 8 1 120 1.06971184580696 128 1.06971184580696 ; 42 up 7 b
f344 0 256 -7 1 8 1 120 1.08005973889231 128 1.08005973889231 ; 43 up 8 b
f345 0 256 -7 1 8 1 120 1.09050773266526 128 1.09050773266526 ; 44 up 9 b
f346 0 256 -7 1 8 1 120 1.10105679545314 128 1.10105679545314 ; 45 up 10 b
f347 0 256 -7 1 8 1 120 1.11170790495044 128 1.11170790495044 ; 46 up 11 b
f348 0 256 -7 1 8 1 120 1.12246204830937 128 1.12246204830937 ; 47 up 12 b
f349 0 256 -7 1 8 1 120 1.13332022223144 128 1.13332022223144 ; 48 up 13 b
f350 0 256 -7 1 8 1 120 1.14428343305974 128 1.14428343305974 ; 49 up 14 b
f351 0 256 -7 1 8 1 120 0.971531941153606 128 0.971531941153606 ; 50 down 3 b
f352 0 256 -7 1 8 1 120 0.962223836894145 128 0.962223836894145 ; 51 down 4 b
f353 0 256 -7 1 8 1 120 0.953004912208957 128 0.953004912208957 ; 52 down 5 b
f354 0 256 -7 1 8 1 120 0.943874312681693 128 0.943874312681693 ; 53 down 6 b
f355 0 256 -7 1 8 1 120 0.934831192082039 128 0.934831192082039 ; 54 down 7 b
f356 0 256 -7 1 8 1 120 0.92587471228729 128 0.92587471228729 ; 55 down 8 b
f357 0 256 -7 1 8 1 120 0.91700404320467 128 0.91700404320467 ; 56 down 9 b
f358 0 256 -7 1 8 1 120 0.908218362694402 128 0.908218362694402 ; 57 down 10 b
f359 0 256 -7 1 8 1 120 0.899516856493507 128 0.899516856493507 ; 58 down 11 b
f360 0 256 -7 1 8 1 120 0.890898718140338 128 0.890898718140338 ; 59 down 12 b
f361 0 256 -7 1 8 1 120 0.882363148899842 128 0.882363148899842 ; 60 down 13 b
f362 0 256 -7 1 8 1 120 0.873909357689526 128 0.873909357689526 ; 61 down 14 b
f363 0 256 -7 1 2 1 30 1.02930223664349 224 1.02930223664349 ; 62 up 3 c
f364 0 256 -7 1 2 1 30 1.03925922603184 224 1.03925922603184 ; 63 up 4 c
f365 0 256 -7 1 2 1 30 1.0493125346879 224 1.0493125346879 ; 64 up 5 c
f366 0 256 -7 1 2 1 30 1.0594630943593 224 1.0594630943593 ; 65 up 6 c
f367 0 256 -7 1 2 1 30 1.06971184580696 224 1.06971184580696 ; 66 up 7 c
f368 0 256 -7 1 2 1 30 1.08005973889231 224 1.08005973889231 ; 67 up 8 c
f369 0 256 -7 1 2 1 30 1.09050773266526 224 1.09050773266526 ; 68 up 9 c
f370 0 256 -7 1 2 1 30 1.10105679545314 224 1.10105679545314 ; 69 up 10 c
f371 0 256 -7 1 2 1 30 1.11170790495044 224 1.11170790495044 ; 70 up 11 c
f372 0 256 -7 1 2 1 30 1.12246204830937 224 1.12246204830937 ; 71 up 12 c
f373 0 256 -7 1 2 1 30 1.13332022223144 224 1.13332022223144 ; 72 up 13 c
f374 0 256 -7 1 2 1 30 1.14428343305974 224 1.14428343305974 ; 73 up 14 c
f375 0 256 -7 1 2 1 30 0.971531941153606 224 0.971531941153606 ; 74 down 3 c
f376 0 256 -7 1 2 1 30 0.962223836894145 224 0.962223836894145 ; 75 down 4 c
f377 0 256 -7 1 2 1 30 0.953004912208957 224 0.953004912208957 ; 76 down 5 c
f378 0 256 -7 1 2 1 30 0.943874312681693 224 0.943874312681693 ; 77 down 6 c
f379 0 256 -7 1 2 1 30 0.934831192082039 224 0.934831192082039 ; 78 down 7 c
f380 0 256 -7 1 2 1 30 0.92587471228729 224 0.92587471228729 ; 79 down 8 c
f381 0 256 -7 1 2 1 30 0.91700404320467 224 0.91700404320467 ; 80 down 9 c
f382 0 256 -7 1 2 1 30 0.908218362694402 224 0.908218362694402 ; 81 down 10 c
f383 0 256 -7 1 2 1 30 0.899516856493507 224 0.899516856493507 ; 82 down 11 c
f384 0 256 -7 1 2 1 30 0.890898718140338 224 0.890898718140338 ; 83 down 12 c
f385 0 256 -7 1 2 1 30 0.882363148899842 224 0.882363148899842 ; 84 down 13 c
f386 0 256 -7 1 2 1 30 0.873909357689526 224 0.873909357689526 ; 85 down 14 c
;Trills in 72 EDO
f 411 0 256 -7 1 16 1 0 1.02930224 16 1.02930224 0 1 16 1 0 1.02930224 208 1.02930224
; 3 110 up & down .trl3 g110
f 412 0 256 -7 1 16 1 0 1.03925923 16 1.03925923 0 1 16 1 0 1.03925923 208 1.03925923
; 4 111 up & down .trl4 g111
f 413 0 256 -7 1 16 1 0 1.04931253 16 1.04931253 0 1 16 1 0 1.04931253 208 1.04931253
; 5 112 up & down .trl5 g112
f 414 0 256 -7 1 16 1 0 1.05946309 16 1.05946309 0 1 16 1 0 1.05946309 208 1.05946309
; 6 113 up & down .trl6 g113
f 415 0 256 -7 1 16 1 0 1.06971185 16 1.06971185 0 1 16 1 0 1.06971185 208 1.06971185
; 7 114 up & down .trl7 g114
f 416 0 256 -7 1 16 1 0 1.08005974 16 1.08005974 0 1 16 1 0 1.08005974 208 1.08005974
; 8 115 up & down .trl8 g115
f 417 0 256 -7 1 16 1 0 1.09050773 16 1.09050773 0 1 16 1 0 1.09050773 208 1.09050773
; 9 116 up & down .trl9 g116
f 418 0 256 -7 1 16 1 0 1.10105680 16 1.10105680 0 1 16 1 0 1.10105680 208 1.10105680
; 10 117 up & down .trl10 g117
f 419 0 256 -7 1 16 1 0 1.11170790 16 1.11170790 0 1 16 1 0 1.11170790 208 1.11170790
; 11 118 up & down .trl11 g118
f 420 0 256 -7 1 16 1 0 1.12246205 16 1.12246205 0 1 16 1 0 1.12246205 208 1.12246205
; 12 119 up & down .trl12 g119
f 421 0 256 -7 1 16 1 0 1.13332022 16 1.13332022 0 1 16 1 0 1.13332022 208 1.13332022
; 13 120 up & down .trl13 g120
f 422 0 256 -7 1 16 1 0 1.14428343 16 1.14428343 0 1 16 1 0 1.14428343 208 1.14428343
; 14 121 up & down .trl14 g121
;Trills in 72 EDO
; Envelopes
; autoscale all following tables to 1
;#7 0 siz
;#6 0 siz exp min values mid val max vals mid vals min val mid val max
f298 0 1025 6 0 1 .5 1 1 496 1 496 1 15 .5 15 0.0 ; e0 - Attack and sustain with a relatively sharp ending
f297 0 1025 6 0 1 .9 1 1 486 1 486 1 25 .5 25 0.0 ; e1 - Attack and sustain with a relatively sharp ending
;#5 0 siz exp start take reach take reach
f296 0 513 5 1024 512 1 ; e2 - exponential - dead piano
;#6 0 siz exp min values mid val max val mid val min val mid val max val mid val min
f295 0 1025 6 0 64 .5 64 1 128 .6 128 .3 128 .5 128 .6 192 .3 192 0 ; e3 big hump, small hump
f294 0 1025 6 0 64 .15 64 .3 128 .25 128 .2 128 .6 128 1 192 .5 192 0 ; e4 small hump, big hump
f293 0 1025 6 0 1 .5 1 1 447 .99 447 .98 64 0.5 64 0 ;e5 default woodwind envelope
f292 0 1025 6 0 1 0.50 1 1.00 447 0.60 447 0.20 32 0.21 32 0.22 32 0.11 32 0.00 ; e6 moving away slowly
f291 0 1025 6 0 1 0.50 1 1.00 128 0.60 128 0.20 256 0.15 254 0.10 128 0.05 128 0.00 ; e7 moving away faster
f290 0 1025 6 0 2 .5 2 1 501 .6 483 .3 18 .15 18 0 ; e8 hit and drop most
f289 0 1025 6 0 1 .3 1 .6 479 .8 479 1 32 .5 32 0 ; e34 Start moderately and build, abrupt end
f288 0 1025 6 0 64 .40 448 1 448 .6 64 0 ; e10 One long hump in the middle
f287 0 1025 6 0 1 .5 1 1 368 .99 368 .98 16 .5 16 0 127 0 127 0 ; e11 hit and sustain 3/4 the normal length
f286 0 1025 6 0 1 .5 1 1 303 .99 303 .98 16 .5 16 0 192 0 192 0 ; e12 hit and sustain 2/3 the normal length
f285 0 1025 6 0 1 .5 1 1 255 .99 255 .98 16 .5 16 0 240 0 240 0 ; e13 hit and sustain 1/2 the normal length
f284 0 1025 6 0 64 .4 64 1 127 .99 255 .98 16 .5 16 0 240 0 240 0 ; e14 gradual in with 1/2 sustain
f283 0 1025 6 0 384 .5 384 1 128 .5 128 0 ; e15 one hump towards the end
f282 0 1025 6 0 2 .2 2 .4 477 .7 479 1 32 .5 32 0 ; e16 sustain piano sound
f281 0 1025 6 0 1 .1 1 .2 479 .6 479 1 32 .5 32 0 ; e17 sustain guitar sound
f280 0 1025 6 1 64 .7 64 .4 64 .4 64 .4 384 .7 352 1 16 .5 16 0 ; e18 Sharp attack, then less quiet, build to end
f279 0 1025 6 0 1 .5 1 1.0 128 .7 228 .4 128 .4 28 .4 128 .5 128 .6 128 .3 126 0 ; e19 Moderate attack, then slightly quiet, build to end
f278 0 1025 6 0 85 0.40 85 0.80 85 0.65 85 0.50 85 0.75 85 1.00 85 0.75 85 0.50 85 0.65 85 0.8 85 0.4 89 0.0 ; e20 3 humps - biggest in middle
f277 0 1025 6 0 85 0.50 85 1.00 85 0.75 85 0.50 85 0.65 85 0.80 85 0.65 85 0.50 85 0.65 85 0.8 85 0.4 89 0.0 ; e21 3 humps - biggest early
f276 0 1025 6 0 85 0.40 85 0.80 85 0.65 85 0.50 85 0.65 85 0.80 85 0.65 85 0.50 85 0.75 85 1.0 85 0.5 89 0.0 ; e22 3 humps - biggest late
f275 0 1025 6 0 1 0.01 84 0.80 84 0.65 84 0.50 84 0.75 84 1.00 84 0.75 84 0.50 84 0.65 84 0.8 84 0.4 183 0.0 ; e23 3 humps - early biggest in middle
f274 0 1025 6 0 1 0.01 84 1.00 84 0.75 84 0.50 84 0.65 84 0.80 84 0.65 84 0.50 84 0.65 84 0.8 84 0.4 183 0.0 ; e24 3 humps - early biggest early
f273 0 1025 6 0 1 0.01 84 0.80 84 0.65 84 0.50 84 0.65 84 0.80 84 0.65 84 0.50 84 0.75 84 1.0 84 0.5 183 0.0 ; e25 3 humps - early biggest late
f272 0 1025 6 0 64 .5 64 1 256 1 512 1 64 .5 64 0 ; e26 slow rise, sustain, slow drop
; min pts mid pts max pts mid pts min pts mid pts max pts mid pts min
;p1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 ;
f265 0 1025 6 0 32 0.20 32 0.40 32 0.30 32 0.20 432 0.60 432 1.00 16 0.50 16 0.00 ; e33 channel one moving in gradually
f264 0 1025 6 0 206 0.03 206 0.06 205 0.06 205 0.05 85 0.53 85 1.00 16 0.50 16 0.00 ; e34 channel 2 moving in at the end
;#6 0 siz exp min values mid val max val mid val min val mid val max val mid val min
f263 0 1025 6 0 2 .2 2 .6 4 .4 4 .3 500 .6 500 1 6 .5 7 0 ; e35 low bass piano inverse of h48 and above
f262 0 1025 6 0 2 .2 2 .6 4 .4 4 .3 500 .32 500 .33 6 .2 7 0 ; e36 low bass piano inverse of h48
f5 0 128 -17 0 9 73 10 75 11 78 12 80 13 82 14 84 15 86 16 88 17 90 18 92 19 94 20 96 21 98 22 127
f6 0 64 -2 0 72 74 77 79 81 83 85 87 89 91 93 95 97 99
f7 0 64 -2 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
f8 0 64 -2 0 1 1 1 1 1 1 1 1 1 1 1 1 1 1
f23 0 128 -17 0 27 57 28 59 29 61 30 63 31 65 32 67 33 69 34 71 35 74 36 76 37 78 38 80 39 82 40 84 41 86 42 88 43 90 44 92 45 127
f24 0 64 -2 0 56 58 60 62 64 66 68 70 73 75 77 79 81 83 85 87 89 91 93
f25 0 64 -2 0 +18 +15 +15 +19 +18 +13 +12 +10 +27 +18 +12 +16 +29 +14 +3 +36 +25 +15 +21
f26 0 64 -2 0 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1
f46 0 128 -17 0 50 50 51 51 52 53 53 55 54 57 55 59 56 61 57 63 58 65 59 67 60 69 61 71 62 73 63 77 64 79 65 82 66 84 67 127
f47 0 64 -2 0 49 50 52 54 56 58 60 62 64 66 68 70 72 76 78 81 83 85
f48 0 64 -2 0 +3 -14 -7 +1 -18 +5 -9 +16 +4 +5 +9 +13 +7 +11 +8 +3 +5 -7
f49 0 64 -2 0 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1
f68 0 128 -17 0 72 50 73 52 74 54 75 56 76 58 77 60 78 62 79 64 80 66 81 68 82 70 83 72 84 74 85 76 86 78 87 80 88 82 89 84 90 86 91 127
f69 0 64 -2 0 49 51 53 55 57 59 61 63 65 67 69 71 73 75 77 79 81 83 85 87
f70 0 64 -2 0 +10 +20 +39 +6 +6 -2 +8 +13 +29 +2 +19 +11 0 +3 +12 +12 +9 +11 +17 +7
f71 0 64 -2 0 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1
f27 0 0 1 "McGill/Partition F/VIOLIN W-VIB/VIOLING#3.aif" 0 4 0
f28 0 0 1 "McGill/Partition F/VIOLIN W-VIB/VIOLINA#3.aif" 0 4 0
f29 0 0 1 "McGill/Partition F/VIOLIN W-VIB/VIOLINC4.aif" 0 4 0
f30 0 0 1 "McGill/Partition F/VIOLIN W-VIB/VIOLIND4.aif" 0 4 0
f31 0 0 1 "McGill/Partition F/VIOLIN W-VIB/VIOLINE4.aif" 0 4 0
f32 0 0 1 "McGill/Partition F/VIOLIN W-VIB/VIOLINF#4.aif" 0 4 0
f33 0 0 1 "McGill/Partition F/VIOLIN W-VIB/VIOLING#4.aif" 0 4 0
f34 0 0 1 "McGill/Partition F/VIOLIN W-VIB/VIOLINA#4.aif" 0 4 0
f35 0 0 1 "McGill/Partition F/VIOLIN W-VIB/VIOLINC#5.aif" 0 4 0
f36 0 0 1 "McGill/Partition F/VIOLIN W-VIB/VIOLIND#5.aif" 0 4 0
f37 0 0 1 "McGill/Partition F/VIOLIN W-VIB/VIOLINF5.aif" 0 4 0
f55 0 0 1 "McGill/Partition F/VIOLA W-VIB/VIOLAV A#3.aif" 0 4 0
f56 0 0 1 "McGill/Partition F/VIOLA W-VIB/VIOLAV C4.aif" 0 4 0
f57 0 0 1 "McGill/Partition F/VIOLA W-VIB/VIOLAV D4.aif" 0 4 0
f58 0 0 1 "McGill/Partition F/VIOLA W-VIB/VIOLAV E4.aif" 0 4 0
f59 0 0 1 "McGill/Partition F/VIOLA W-VIB/VIOLAV F#4.aif" 0 4 0
f76 0 0 1 "McGill/Partition A/CELLO W-VIB/CELLOV A2.aif" 0 4 0
f77 0 0 1 "McGill/Partition A/CELLO W-VIB/CELLOV B2.aif" 0 4 0
f78 0 0 1 "McGill/Partition A/CELLO W-VIB/CELLOV C#3.aif" 0 4 0
f79 0 0 1 "McGill/Partition A/CELLO W-VIB/CELLOV D#3.aif" 0 4 0
f80 0 0 1 "McGill/Partition A/CELLO W-VIB/CELLOV F3.aif" 0 4 0
f81 0 0 1 "McGill/Partition A/CELLO W-VIB/CELLOV G3.aif" 0 4 0
f82 0 0 1 "McGill/Partition A/CELLO W-VIB/CELLOV A3.aif" 0 4 0
f83 0 0 1 "McGill/Partition A/CELLO W-VIB/CELLOV B3.aif" 0 4 0
f84 0 0 1 "McGill/Partition A/CELLO W-VIB/CELLOV C#4.aif" 0 4 0
f85 0 0 1 "McGill/Partition A/CELLO W-VIB/CELLOV D#4.aif" 0 4 0
f86 0 0 1 "McGill/Partition A/CELLO W-VIB/CELLOV F4.aif" 0 4 0
f1 0 64 -2 0 5 23 46 68
f2 0 64 -2 0 5 5 5 5
;Inst Start Dur Vel Ton Oct Voice Stere Envlp Gliss Upsamp R-Env;Channel
;p1 p2 p3 p4 p5 p6 p7 p8 p9 p10 p11 R-Env;Channel
i1 0.0000000000 8 1 0 1 1 8 0 0 0 0 ; 1
i1 8.0000000000 160 1 0 1 1 8 0 0 0 0 ; 1
i1 168.0000000000 160 1 0 1 1 8 0 0 0 0 ; 1
i1 328.0000000000 96 1 0 1 1 8 0 0 0 0 ; 1
i1 424.0000000000 160 1 0 1 1 8 0 0 0 0 ; 1
i1 584.0000000000 8 1 0 1 1 8 0 0 0 0 ; 1
i1 8.0000000000 49 80 0 4 2 8 1 0 0 1 ; 2
i1 56.0000000000 17 80 30 4 2 8 1 0 0 1 ; 2
i1 72.0000000000 65 80 60 4 2 8 1 0 0 1 ; 2
i1 136.0000000000 81 80 65 4 2 8 1 0 0 1 ; 2
i1 168.0000000000 49 80 23 4 2 8 1 0 0 1 ; 2
i1 216.0000000000 32 80 18 4 2 8 1 0 0 1 ; 2
i1 216.0000000000 32 80 60 4 2 8 1 0 0 1 ; 2
i1 248.0000000000 17 80 37 4 2 8 1 0 0 1 ; 2
i1 248.0000000000 17 80 7 5 2 8 1 0 0 1 ; 2
i1 264.0000000000 17 80 48 4 2 8 1 0 0 1 ; 2
i1 264.0000000000 17 80 18 5 2 8 1 0 0 1 ; 2
i1 280.0000000000 33 80 24 4 2 8 1 0 0 1 ; 2
i1 312.0000000000 33 80 24 4 2 8 1 0 0 1 ; 2
i1 328.0000000000 33 80 66 4 2 8 1 0 0 1 ; 2
i1 344.0000000000 17 80 7 4 2 8 1 0 0 1 ; 2
i1 360.0000000000 17 80 43 3 2 8 1 0 0 1 ; 2
i1 376.0000000000 33 80 54 3 2 8 1 0 0 1 ; 2
i1 408.0000000000 65 80 27 4 2 8 1 0 0 1 ; 2
i1 472.0000000000 17 80 31 4 2 8 1 0 0 1 ; 2
i1 488.0000000000 65 80 55 4 2 8 1 0 0 1 ; 2
i1 552.0000000000 41 80 69 4 2 8 1 0 0 1 ; 2
i1 8.0000000000 49 80 0 4 2 8 1 0 1 1 ; 3
i1 56.0000000000 49 80 30 4 2 8 1 0 1 1 ; 3
i1 104.0000000000 145 80 35 4 2 8 1 0 1 1 ; 3
i1 104.0000000000 65 80 4 5 2 8 1 0 1 1 ; 3
i1 168.0000000000 49 80 13 5 2 8 1 0 0 1 ; 3
i1 216.0000000000 33 80 4 5 2 8 1 0 0 1 ; 3
i1 248.0000000000 89 80 66 3 2 8 1 0 0 1 ; 3
i1 336.0000000000 9 80 43 4 2 8 1 0 0 1 ; 3
i1 336.0000000000 9 80 13 4 2 8 1 0 0 1 ; 3
i1 344.0000000000 17 80 49 3 2 8 1 0 0 1 ; 3
i1 344.0000000000 17 80 37 4 2 8 1 0 0 1 ; 3
i1 360.0000000000 33 80 31 4 2 8 1 0 0 1 ; 3
i1 392.0000000000 81 80 40 4 2 8 1 0 0 1 ; 3
i1 392.0000000000 81 80 11 4 2 8 1 0 0 1 ; 3
i1 472.0000000000 49 80 31 4 2 8 1 0 0 1 ; 3
i1 520.0000000000 65 80 35 4 2 8 1 0 0 1 ; 3
i1 520.0000000000 65 80 5 5 2 8 1 0 0 1 ; 3
i1 8.0000000000 118 80 0 4 3 8 1 0 0 1 ; 4
i1 125.0000000000 22 80 64 3 3 8 1 0 0 1 ; 4
i1 146.0000000000 23 80 13 4 3 8 1 0 0 1 ; 4
i1 168.0000000000 65 80 4 4 3 8 1 0 0 1 ; 4
i1 232.0000000000 17 80 71 3 3 8 1 0 0 1 ; 4
i1 248.0000000000 17 80 66 3 3 8 1 0 0 1 ; 4
i1 264.0000000000 17 80 24 4 3 8 1 0 0 1 ; 4
i1 280.0000000000 17 80 18 4 3 8 1 0 0 1 ; 4
i1 296.0000000000 17 80 13 4 3 8 1 0 0 1 ; 4
i1 312.0000000000 17 80 66 3 3 8 1 0 0 1 ; 4
i1 328.0000000000 17 80 2 4 3 8 1 0 0 1 ; 4
i1 344.0000000000 17 80 7 4 3 8 1 0 0 1 ; 4
i1 360.0000000000 33 80 1 4 3 8 1 0 0 1 ; 4
i1 392.0000000000 33 80 67 3 3 8 1 0 0 1 ; 4
i1 424.0000000000 118 80 2 4 3 8 1 0 0 1 ; 4
i1 541.0000000000 22 80 65 3 3 8 1 0 0 1 ; 4
i1 562.0000000000 23 80 15 4 3 8 1 0 0 1 ; 4
i1 24.0000000000 65 80 42 4 4 8 1 0 0 1 ; 5
i1 88.0000000000 50 80 48 4 4 8 1 0 0 1 ; 5
i1 88.0000000000 50 80 18 5 4 8 1 0 0 1 ; 5
i1 200.0000000000 97 80 48 4 4 8 1 0 0 1 ; 5
i1 264.0000000000 33 80 7 4 4 8 1 0 0 1 ; 5
i1 296.0000000000 49 80 2 4 4 8 1 0 0 1 ; 5
i1 296.0000000000 49 80 43 4 4 8 1 0 0 1 ; 5
i1 344.0000000000 49 80 61 3 4 8 1 0 0 1 ; 5
i1 344.0000000000 17 80 19 4 4 8 1 0 0 1 ; 5
i1 392.0000000000 33 80 54 3 4 8 1 0 0 1 ; 5
i1 392.0000000000 33 80 24 4 4 8 1 0 0 1 ; 5
i1 440.0000000000 65 80 41 4 4 8 1 0 0 1 ; 5
i1 504.0000000000 50 80 49 4 4 8 1 0 0 1 ; 5
i1 504.0000000000 50 80 19 5 4 8 1 0 0 1 ; 5
t0 1000 8 1000 168 1000 328 1000 424 1000 584 1000

</CsScore>
</CsoundSynthesizer>

--- In MakeMicroMusic@yahoogroups.com, Mike Battaglia <battaglia01@...> wrote:
>
> See also:
>
> >
> > Hz are the way to go if you want Hz. If you want pitch
> > envelopes or vibrato with envelopes defined in cents, you
> > have to run the lookup table gauntlet. But, even then,
> > multiplying your target pitch by a modulation variable is
> > going to be correct when that modulation's converted
> > from zero. (It doesn't matter much otherwise, right?)
> >
> > The alternative is to convert from Hz to pitch units, add
> > the modulation variable, and then convert back to Hz. Then
> > you have to check your functions are accurate.
> >
> > As a final, desperate attempt to turn an obvious answer
> > into an intelligent one, I'll mention that a small amount
> > of vibrato or pitch-noise might actually help to correct
> > the perceived pitch. It should be about the same size as
> > the resolution of the tables you're using. Here's a
> > helpful link:
> >
> > http://en.wikipedia.org/wiki/Stochastic_resonance
> >
> > Graham
>

Great reference post, that, Prent...thanks! I'm sure Gene will have a
lot to dig into there.

You are so right about humanization tricks....in microcsound, I
implement a gaussian distribution randomization function for such
things as onset time and articulation endpoints, as you say. Not to
mention the obvious trick of humanizing attack velocity, etc.

Gaussian distribution random curves work well because they sort of
model the whole "I mostly got it nailed into this narrow channel of
values, but there are a few standout outliers" phenomenon that
musicians naturally tend to do, as do so many natural phenomenon (e.g.
the way stone steps might wear out based on how many people tend to
walk in the center of the step as opposed to the side)

AKJ

On Fri, Apr 8, 2011 at 2:05 PM, prentrodgers <prentrodgers@...> wrote:
> I've not had time to read all the posts on Csound, but I've been using it successfully for about 15 years. I've not run into the problem with pitch accuracy, but these are areas of Csound that I haven't touched for at least ten years. I use a table lookup function to convert the relative note number (nowadays it's 0 to 72 tone per octave) into a fractional value, which is converted into a pitch using cpspch(octave + pitch).
>
> I create a k value for the pitch, which can change during the note play time. I multiply that k value by another glissando value, so that the pitch can change (or not) during the note play time. This set of values then is the input to the waveform generation opcode. The glissando value can also be used for vibrato, trills, or frequency manipulation as needed.
>
> I also work hard on the envelope for each note. You would be surprised how important something as simple as an envelope can be, and how subtle changes in while playing make instruments more human. And each channel doesn't need to have the same envelope. It's not as if musicians stand still while they play, after all.
>
> Finally, the control over the overlap of one note to the next is critical as well. Don't assume that you should start one note when the other one ends. Millisecond changes in overlaps make another humanization factor. There is a whole world between Legato vs stacatto.
>
> I use orchestral samples for all my instruments, but I've gotten some interesting results using plain Sine waves as well. It's amazing how much variety you can get by manipulating pitch, envelope, glissando, trills, and legato without actual orchestral samples.
>
> Here's the Csound input I use for my realization of the first few measures of Ben Johnston's String Quartet #7 movement 3: "Variations". It requires some carefully tuned string instrument samples to realize. It took me several months to tune the three sample libraries. I made sure that the highest vibrato point for each note is the right pitch.  The sample libraries are never very accurate.
>
> By looking at this Csound source, you might be able to see how the table lookups work to simplify the pitch selections. In the first five measures, Johnston has already used 61 distinct pitches. You can hear it here: http://dailynoise.tumblr.com/
>
>
> ; name: johns1 3/08/11 1:51pm
> ;
> ; Album Title: String Quartet Number 7
> ; Composer: Ben Johnston
> ;
> ; Orchestra:
> ;      String Quartet
> <CsoundSynthesizer>
>
> <CsOptions>
> -W -G -m2 -+y -o sflib\johns1.wav
> </CsOptions>
>
> <CsInstruments>
>  sr = 44100
>  ksmps = 10; any higher than 10 and I hear clicks - use 1 for final take
> ; typically save 5x processing time by increasing ksmps by 10x
>  nchnls = 2
>  instr 1
>
> ; p1 is always 1
> ; p2 start time
> ; p3 duration
> ; p4 velocity, 60-80 works best
> ; p5 tone - which tone is this note
> ; p6 Octave
> ; p7 voice
> ; p8 stereo - pan from left = 0 to right = 16
> ; p9 envelope - one of several function tables for envelopes 1 - 16
> ; p10 glissando - one of several function tables to modify pitch
> ; p11 upsample - use a sample higher (>0) or lower (<256) than normal
> ; p12 envelope for right channel - if blank, use the left channel envelope for both channels
> ;
>  ifunc table p7,1 ; find the location of the sample wave tables
>  ioct = p6+1
>  iwavchan table p7,2 ; is it mono (iwavchan = 1) or stereo sample file (iwavchan = 2)
>  ; or are sustain points in separate table iwavchan=3
>  inum = 12*(ioct) + int(p5/6) ; convert from octave/pitch to a MIDI note number to pick ftable (root is 72, 72/12 = 6)
>  ifno2 table inum, ifunc ; map midi note number to the correct ftable for that note
>  ifno = ifno2 + (p11 < 128 ? p11 : p11-256) ; up or down sample by parameter 11 modulo 256
>  iamp = ampdb(p4) ; velocity input is 60-80 - convert to amplitude
>  i9 = 298-p9 ; valid envelope table number are 298, 297, 296, 295 etc. - left channel
>  i12 = 298-p12 ; valid envelope table number are 298, 297, 296, 295 etc. - right channel
>  i10 = 301+p10 ; valid glissando table number are 301, 302, etc
> ; kamp_l poscil iamp, 1/p3, i9 ; create a precise long envelope from a function table for left channel
> ; kamp_r poscil iamp, 1/p3, i12 ; create a precise long envelope from a function table for right channel
>  kamp_l oscil iamp, 1/p3, i9 ; create an envelope from a function table for left channel
>  kamp_r oscil iamp, 1/p3, i12 ; create an envelope from a function table for right channel
>  kpan_l tablei p8/16, 4, 1,0,1 ; pan with a sine wave using f table #4 - 2st value is reduced to max 1, normalized
>  kpan_r tablei 1.0 - p8/16, 4, 1,0,1 ; inverse of kpan_l
>  ibasno table ifno-(3+ifunc), 1 + ifunc ; get midi note number the sample was recorded at
>  icent table ifno-(3+ifunc), 2 + ifunc ; get cents to flatten each note
>  iloop table ifno-(3+ifunc), 3 + ifunc ; get loop or not
>  ibasoct = ibasno/12 ; find the base octave
>  ibascps = cpsoct(ibasoct+(icent/1200))
>  ipitch table p5, 3 ; convert note number 0-71 to oct.fract format - hand made table 3 of fractions
>  inote = cpspch(ioct + ipitch) ; note plus the decimal fraction of a note from table - how precise is this?
>  print p5, p6, p7, p11, ifno, icent
>  kcps = cpspch(ioct + ipitch) ; convert oct.fract to Hz
>  kcpsm oscili 1, 1/p3, i10 ; create an set of shift multiplicands from table - glissandi
>  kcps2 = kcps * kcpsm ; shift the frequency by values in glissando table
>  ; Four choices: Mono looping, stereo looping, mono no-loop, stereo no-loop
>  if iwavchan = 4 goto akaimono
>  if iloop = 0 goto noloops
>  ; Stereo with loop
>  a3,a4 loscil 1, kcps2, ifno, ibascps; stereo sample with looping
>  goto skipstereo
>  noloops:
>  ; Stereo without looping
>  a3,a4 loscil 1, kcps2, ifno, ibascps,0,1,2 ; stereo sample without looping - note that 1,2 is bogus workaround
>  goto skipstereo
>  akaimono:
>  if iloop = 0 goto noloopm
>  ; Mono with looping
>  a3 loscil 1, kcps2, ifno, ibascps ; mono sampling with loop
>  a4 = a3
>  goto skipstereo
>  noloopm:
>  ; Mono without looping
>  a3 loscil 1, kcps2, ifno, ibascps,0,1,2 ; mono AIFF sample without loop
>  a4 = a3
>
>  skipstereo:
>  ; start comparison sine wave oscillator for fine tuning adjustment testing
>  ; ihertz = cpspch(ioct+ipitch) ; what frequency are you trying to make
>  ; a1 oscili 1, kcps*8, 500 ; sine wave to compare the sample frequency to
>  ; a5 = a1 ; + a3 ; add the sample to the sine wave right
>  ; a6 = a4 + a3 ; and left
>  ; a3 = a5
>  ; a4 = a6
>  ; end comparison sine wave oscilator
>  ; start of resonant filter for tuning purposes
>  ;a1 reson a3,kcps*4,20,2
>  ;a2 reson a4,kcps*4,20,2
>  a1 = a3 * kamp_l
>  a2 = a4 * kamp_r
> ;
>  outs a1 * kpan_l ,a2 * kpan_r
>  endin
>
> ; instr 99
> ; kamp poscil 1, 1/p3, 1 ; create an envelope from a function table
> ; a6, a7 soundin "sflib/johns1.wav"
> ; outs a6 * kamp, a7 * kamp
> ; endin
> </CsInstruments>
>
> <CsScore>
> ; cents for each step in the scale
> ; just equivalent to 72 EDO
> f3 0 128 -2
>  0 0.0016667 0.0033333 0.0050000 0.0066667 0.0083333 0.0100000 0.0116667 0.0133333 0.0150000 0.0166667
>  0.0183333 0.0200000 0.0216667 0.0233333 0.0250000 0.0266667 0.0283333 0.0300000 0.0316667 0.0333333
>  0.0350000 0.0366667 0.0383333 0.0400000 0.0416667 0.0433333 0.0450000 0.0466667 0.0483333 0.0500000
>  0.0516667 0.0533333 0.0550000 0.0566667 0.0583333 0.0600000 0.0616667 0.0633333 0.0650000 0.0666667
>  0.0683333 0.0700000 0.0716667 0.0733333 0.0750000 0.0766667 0.0783333 0.0800000 0.0816667 0.0833333
>  0.0850000 0.0866667 0.0883333 0.0900000 0.0916667 0.0933333 0.0950000 0.0966667 0.0983333 0.1000000
>  0.1016667 0.1033333 0.1050000 0.1066667 0.1083333 0.1100000 0.1116667 0.1133333 0.1150000 0.1166667
>  0.1183333 0.12
> f4 0 1025 9 .25 1 0 ;The first quadrant of a sine for panning
> f500 0 256 10 1
> ;lf9 0 256 10 1 ; sine wave
> ; c4 = 72 = middle C = 60 is MIDI standard number
> ; g3 = 67
> ; something is wrong with function table 300
> ; 1st take 2nd take 3rd take 4th take 5th take 6th take sum of takes = size of table
> ; these are useful for taking a note up or down an octave without moving the sample up or down - built in munchkinization
> f301 0 256 -7 1 256 1 ; g0 = no change;
> f302 0 256 -7 1.125 256 1.125 ; g1 up 9/8
> f303 0 256 -7 1.25 256 1.25 ; g2 up 5/4
> f304 0 256 -7 1.3333 256 1.3333 ; g3 up 4/3
> f305 0 256 -7 1.5 256 1.5 ; g4 up 3/2
> f306 0 256 -7 .875 256 .875 ; g5 down 7/8
> f307 0 256 -7 .5 256 .5 ; g6 down 1 octave
> f308 0 256 -7 .25 256 .25 ; g7 down 2 octaves
> f309 0 256 -7 .125 256 .125 ; g8 down 3 octaves
> f310 0 1024 -7 1 512 1 0 1.125 256 1.125 0 .9000000 256 .9000000 0 ; g9 4 5 3 = A# C Ab
> f311 0 1024 -7 1 512 1 0 1.14285714 256 1.14285714 0 .8888889 256 .8888888 0 ; g10 5 6 4 = 11:8 -> 11:7 -> 11:9
> f312 0 256 -7 1 256 1.0625; g11 glide up 17/16
> f313 0 256 -7 1 256 .9375; g12 glide down 15/16
> ; Glissando up tables min points mid pts max pts mid pts max pts mid pts min mid max mid min mid max ; glide number Ratio
> f314 0 256 -7 1 48 1 128 1 80 1 ; 1:1 g13 up 0
> f315 0 256 -7 1 16 1 128 1.02930223664349 112 1.02930223664349 ; 14 up 3 a
> f316 0 256 -7 1 16 1 128 1.03925922603184 112 1.03925922603184 ; 15 up 4 a
> f317 0 256 -7 1 16 1 128 1.0493125346879 112 1.0493125346879 ; 16 up 5 a
> f318 0 256 -7 1 16 1 128 1.0594630943593 112 1.0594630943593 ; 17 up 6 a
> f319 0 256 -7 1 16 1 128 1.06971184580696 112 1.06971184580696 ; 18 up 7 a
> f320 0 256 -7 1 16 1 128 1.08005973889231 112 1.08005973889231 ; 19 up 8 a
> f321 0 256 -7 1 16 1 128 1.09050773266526 112 1.09050773266526 ; 20 up 9 a
> f322 0 256 -7 1 16 1 128 1.10105679545314 112 1.10105679545314 ; 21 up 10 a
> f323 0 256 -7 1 16 1 128 1.11170790495044 112 1.11170790495044 ; 22 up 11 a
> f324 0 256 -7 1 16 1 128 1.12246204830937 112 1.12246204830937 ; 23 up 12 a
> f325 0 256 -7 1 16 1 128 1.13332022223144 112 1.13332022223144 ; 24 up 13 a
> f326 0 256 -7 1 16 1 128 0.971531941153606 112 0.971531941153606 ; 25 down 3 a
> f327 0 256 -7 1 16 1 128 0.962223836894145 112 0.962223836894145 ; 26 down 4 a
> f328 0 256 -7 1 16 1 128 0.953004912208957 112 0.953004912208957 ; 27 down 5 a
> f329 0 256 -7 1 16 1 128 0.943874312681693 112 0.943874312681693 ; 28 down 6 a
> f330 0 256 -7 1 16 1 128 0.934831192082039 112 0.934831192082039 ; 29 down 7 a
> f331 0 256 -7 1 16 1 128 0.934831192082039 112 0.934831192082039 ; 30 down 7 a
> f332 0 256 -7 1 16 1 128 0.92587471228729 112 0.92587471228729 ; 31 down 8 a
> f333 0 256 -7 1 16 1 128 0.91700404320467 112 0.91700404320467 ; 32 down 9 a
> f334 0 256 -7 1 16 1 128 0.908218362694402 112 0.908218362694402 ; 33 down 10 a
> f335 0 256 -7 1 16 1 128 0.899516856493507 112 0.899516856493507 ; 34 down 11 a
> f336 0 256 -7 1 16 1 128 0.890898718140338 112 0.890898718140338 ; 35 down 12 a
> f337 0 256 -7 1 16 1 128 0.882363148899842 112 0.882363148899842 ; 36 down 13 a
> f338 0 256 -7 1 16 1 128 0.873909357689526 112 0.873909357689526 ; 37 down 14 a
> f339 0 256 -7 1 8 1 120 1.02930223664349 128 1.02930223664349 ; 38 up 3 b
> f340 0 256 -7 1 8 1 120 1.03925922603184 128 1.03925922603184 ; 39 up 4 b
> f341 0 256 -7 1 8 1 120 1.0493125346879 128 1.0493125346879 ; 40 up 5 b
> f342 0 256 -7 1 8 1 120 1.0594630943593 128 1.0594630943593 ; 41 up 6 b
> f343 0 256 -7 1 8 1 120 1.06971184580696 128 1.06971184580696 ; 42 up 7 b
> f344 0 256 -7 1 8 1 120 1.08005973889231 128 1.08005973889231 ; 43 up 8 b
> f345 0 256 -7 1 8 1 120 1.09050773266526 128 1.09050773266526 ; 44 up 9 b
> f346 0 256 -7 1 8 1 120 1.10105679545314 128 1.10105679545314 ; 45 up 10 b
> f347 0 256 -7 1 8 1 120 1.11170790495044 128 1.11170790495044 ; 46 up 11 b
> f348 0 256 -7 1 8 1 120 1.12246204830937 128 1.12246204830937 ; 47 up 12 b
> f349 0 256 -7 1 8 1 120 1.13332022223144 128 1.13332022223144 ; 48 up 13 b
> f350 0 256 -7 1 8 1 120 1.14428343305974 128 1.14428343305974 ; 49 up 14 b
> f351 0 256 -7 1 8 1 120 0.971531941153606 128 0.971531941153606 ; 50 down 3 b
> f352 0 256 -7 1 8 1 120 0.962223836894145 128 0.962223836894145 ; 51 down 4 b
> f353 0 256 -7 1 8 1 120 0.953004912208957 128 0.953004912208957 ; 52 down 5 b
> f354 0 256 -7 1 8 1 120 0.943874312681693 128 0.943874312681693 ; 53 down 6 b
> f355 0 256 -7 1 8 1 120 0.934831192082039 128 0.934831192082039 ; 54 down 7 b
> f356 0 256 -7 1 8 1 120 0.92587471228729 128 0.92587471228729 ; 55 down 8 b
> f357 0 256 -7 1 8 1 120 0.91700404320467 128 0.91700404320467 ; 56 down 9 b
> f358 0 256 -7 1 8 1 120 0.908218362694402 128 0.908218362694402 ; 57 down 10 b
> f359 0 256 -7 1 8 1 120 0.899516856493507 128 0.899516856493507 ; 58 down 11 b
> f360 0 256 -7 1 8 1 120 0.890898718140338 128 0.890898718140338 ; 59 down 12 b
> f361 0 256 -7 1 8 1 120 0.882363148899842 128 0.882363148899842 ; 60 down 13 b
> f362 0 256 -7 1 8 1 120 0.873909357689526 128 0.873909357689526 ; 61 down 14 b
> f363 0 256 -7 1 2 1 30 1.02930223664349 224 1.02930223664349 ; 62 up 3 c
> f364 0 256 -7 1 2 1 30 1.03925922603184 224 1.03925922603184 ; 63 up 4 c
> f365 0 256 -7 1 2 1 30 1.0493125346879 224 1.0493125346879 ; 64 up 5 c
> f366 0 256 -7 1 2 1 30 1.0594630943593 224 1.0594630943593 ; 65 up 6 c
> f367 0 256 -7 1 2 1 30 1.06971184580696 224 1.06971184580696 ; 66 up 7 c
> f368 0 256 -7 1 2 1 30 1.08005973889231 224 1.08005973889231 ; 67 up 8 c
> f369 0 256 -7 1 2 1 30 1.09050773266526 224 1.09050773266526 ; 68 up 9 c
> f370 0 256 -7 1 2 1 30 1.10105679545314 224 1.10105679545314 ; 69 up 10 c
> f371 0 256 -7 1 2 1 30 1.11170790495044 224 1.11170790495044 ; 70 up 11 c
> f372 0 256 -7 1 2 1 30 1.12246204830937 224 1.12246204830937 ; 71 up 12 c
> f373 0 256 -7 1 2 1 30 1.13332022223144 224 1.13332022223144 ; 72 up 13 c
> f374 0 256 -7 1 2 1 30 1.14428343305974 224 1.14428343305974 ; 73 up 14 c
> f375 0 256 -7 1 2 1 30 0.971531941153606 224 0.971531941153606 ; 74 down 3 c
> f376 0 256 -7 1 2 1 30 0.962223836894145 224 0.962223836894145 ; 75 down 4 c
> f377 0 256 -7 1 2 1 30 0.953004912208957 224 0.953004912208957 ; 76 down 5 c
> f378 0 256 -7 1 2 1 30 0.943874312681693 224 0.943874312681693 ; 77 down 6 c
> f379 0 256 -7 1 2 1 30 0.934831192082039 224 0.934831192082039 ; 78 down 7 c
> f380 0 256 -7 1 2 1 30 0.92587471228729 224 0.92587471228729 ; 79 down 8 c
> f381 0 256 -7 1 2 1 30 0.91700404320467 224 0.91700404320467 ; 80 down 9 c
> f382 0 256 -7 1 2 1 30 0.908218362694402 224 0.908218362694402 ; 81 down 10 c
> f383 0 256 -7 1 2 1 30 0.899516856493507 224 0.899516856493507 ; 82 down 11 c
> f384 0 256 -7 1 2 1 30 0.890898718140338 224 0.890898718140338 ; 83 down 12 c
> f385 0 256 -7 1 2 1 30 0.882363148899842 224 0.882363148899842 ; 84 down 13 c
> f386 0 256 -7 1 2 1 30 0.873909357689526 224 0.873909357689526 ; 85 down 14 c
> ;Trills in 72 EDO
> f 411 0 256 -7 1 16 1 0 1.02930224 16 1.02930224 0 1 16 1 0 1.02930224 208 1.02930224
>  ; 3 110 up & down .trl3 g110
> f 412 0 256 -7 1 16 1 0 1.03925923 16 1.03925923 0 1 16 1 0 1.03925923 208 1.03925923
>  ; 4 111 up & down .trl4 g111
> f 413 0 256 -7 1 16 1 0 1.04931253 16 1.04931253 0 1 16 1 0 1.04931253 208 1.04931253
>  ; 5 112 up & down .trl5 g112
> f 414 0 256 -7 1 16 1 0 1.05946309 16 1.05946309 0 1 16 1 0 1.05946309 208 1.05946309
>  ; 6 113 up & down .trl6 g113
> f 415 0 256 -7 1 16 1 0 1.06971185 16 1.06971185 0 1 16 1 0 1.06971185 208 1.06971185
>  ; 7 114 up & down .trl7 g114
> f 416 0 256 -7 1 16 1 0 1.08005974 16 1.08005974 0 1 16 1 0 1.08005974 208 1.08005974
>  ; 8 115 up & down .trl8 g115
> f 417 0 256 -7 1 16 1 0 1.09050773 16 1.09050773 0 1 16 1 0 1.09050773 208 1.09050773
>  ; 9 116 up & down .trl9 g116
> f 418 0 256 -7 1 16 1 0 1.10105680 16 1.10105680 0 1 16 1 0 1.10105680 208 1.10105680
>  ; 10 117 up & down .trl10 g117
> f 419 0 256 -7 1 16 1 0 1.11170790 16 1.11170790 0 1 16 1 0 1.11170790 208 1.11170790
>  ; 11 118 up & down .trl11 g118
> f 420 0 256 -7 1 16 1 0 1.12246205 16 1.12246205 0 1 16 1 0 1.12246205 208 1.12246205
>  ; 12 119 up & down .trl12 g119
> f 421 0 256 -7 1 16 1 0 1.13332022 16 1.13332022 0 1 16 1 0 1.13332022 208 1.13332022
>  ; 13 120 up & down .trl13 g120
> f 422 0 256 -7 1 16 1 0 1.14428343 16 1.14428343 0 1 16 1 0 1.14428343 208 1.14428343
>  ; 14 121 up & down .trl14 g121
> ;Trills in 72 EDO
> ; Envelopes
> ; autoscale all following tables to 1
> ;#7 0 siz
> ;#6 0 siz exp min values mid val max vals mid vals min val mid val max
> f298 0 1025 6 0 1 .5 1 1 496 1 496 1 15 .5 15 0.0 ; e0 - Attack and sustain with a relatively sharp ending
> f297 0 1025 6 0 1 .9 1 1 486 1 486 1 25 .5 25 0.0 ; e1 - Attack and sustain with a relatively sharp ending
> ;#5 0 siz exp start take reach take reach
> f296 0 513 5 1024 512 1 ; e2 - exponential - dead piano
> ;#6 0 siz exp min values mid val max val mid val min val mid val max val mid val min
> f295 0 1025 6 0 64 .5 64 1 128 .6 128 .3 128 .5 128 .6 192 .3 192 0 ; e3 big hump, small hump
> f294 0 1025 6 0 64 .15 64 .3 128 .25 128 .2 128 .6 128 1 192 .5 192 0 ; e4 small hump, big hump
> f293 0 1025 6 0 1 .5 1 1 447 .99 447 .98 64 0.5 64 0 ;e5 default woodwind envelope
> f292 0 1025 6 0 1 0.50 1 1.00 447 0.60 447 0.20 32 0.21 32 0.22 32 0.11 32 0.00 ; e6 moving away slowly
> f291 0 1025 6 0 1 0.50 1 1.00 128 0.60 128 0.20 256 0.15 254 0.10 128 0.05 128 0.00 ; e7 moving away faster
> f290 0 1025 6 0 2 .5 2 1 501 .6 483 .3 18 .15 18 0 ; e8 hit and drop most
> f289 0 1025 6 0 1 .3 1 .6 479 .8 479 1 32 .5 32 0 ; e34 Start moderately and build, abrupt end
> f288 0 1025 6 0 64 .40 448 1 448 .6 64 0 ; e10 One long hump in the middle
> f287 0 1025 6 0 1 .5 1 1 368 .99 368 .98 16 .5 16 0 127 0 127 0 ; e11 hit and sustain 3/4 the normal length
> f286 0 1025 6 0 1 .5 1 1 303 .99 303 .98 16 .5 16 0 192 0 192 0 ; e12 hit and sustain 2/3 the normal length
> f285 0 1025 6 0 1 .5 1 1 255 .99 255 .98 16 .5 16 0 240 0 240 0 ; e13 hit and sustain 1/2 the normal length
> f284 0 1025 6 0 64 .4 64 1 127 .99 255 .98 16 .5 16 0 240 0 240 0 ; e14 gradual in with 1/2 sustain
> f283 0 1025 6 0 384 .5 384 1 128 .5 128 0 ; e15 one hump towards the end
> f282 0 1025 6 0 2 .2 2 .4 477 .7 479 1 32 .5 32 0 ; e16 sustain piano sound
> f281 0 1025 6 0 1 .1 1 .2 479 .6 479 1 32 .5 32 0 ; e17 sustain guitar sound
> f280 0 1025 6 1 64 .7 64 .4 64 .4 64 .4 384 .7 352 1 16 .5 16 0 ; e18 Sharp attack, then less quiet, build to end
> f279 0 1025 6 0 1 .5 1 1.0 128 .7 228 .4 128 .4 28 .4 128 .5 128 .6 128 .3 126 0 ; e19 Moderate attack, then slightly quiet, build to end
> f278 0 1025 6 0 85 0.40 85 0.80 85 0.65 85 0.50 85 0.75 85 1.00 85 0.75 85 0.50 85 0.65 85 0.8 85 0.4 89 0.0 ; e20 3 humps - biggest in middle
> f277 0 1025 6 0 85 0.50 85 1.00 85 0.75 85 0.50 85 0.65 85 0.80 85 0.65 85 0.50 85 0.65 85 0.8 85 0.4 89 0.0 ; e21 3 humps - biggest early
> f276 0 1025 6 0 85 0.40 85 0.80 85 0.65 85 0.50 85 0.65 85 0.80 85 0.65 85 0.50 85 0.75 85 1.0 85 0.5 89 0.0 ; e22 3 humps - biggest late
> f275 0 1025 6 0 1 0.01 84 0.80 84 0.65 84 0.50 84 0.75 84 1.00 84 0.75 84 0.50 84 0.65 84 0.8 84 0.4 183 0.0 ; e23 3 humps - early biggest in middle
> f274 0 1025 6 0 1 0.01 84 1.00 84 0.75 84 0.50 84 0.65 84 0.80 84 0.65 84 0.50 84 0.65 84 0.8 84 0.4 183 0.0 ; e24 3 humps - early biggest early
> f273 0 1025 6 0 1 0.01 84 0.80 84 0.65 84 0.50 84 0.65 84 0.80 84 0.65 84 0.50 84 0.75 84 1.0 84 0.5 183 0.0 ; e25 3 humps - early biggest late
> f272 0 1025 6 0 64 .5 64 1 256 1 512 1 64 .5 64 0 ; e26 slow rise, sustain, slow drop
> ; min pts mid pts max pts mid pts min pts mid pts max pts mid pts min
> ;p1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 ;
> f265 0 1025 6 0 32 0.20 32 0.40 32 0.30 32 0.20 432 0.60 432 1.00 16 0.50 16 0.00 ; e33 channel one moving in gradually
> f264 0 1025 6 0 206 0.03 206 0.06 205 0.06 205 0.05 85 0.53 85 1.00 16 0.50 16 0.00 ; e34 channel 2 moving in at the end
> ;#6 0 siz exp min values mid val max val mid val min val mid val max val mid val min
> f263 0 1025 6 0 2 .2 2 .6 4 .4 4 .3 500 .6 500 1 6 .5 7 0 ; e35 low bass piano inverse of h48 and above
> f262 0 1025 6 0 2 .2 2 .6 4 .4 4 .3 500 .32 500 .33 6 .2 7 0 ; e36 low bass piano inverse of h48
> f5 0 128 -17 0 9 73 10 75 11 78 12 80 13 82 14 84 15 86 16 88 17 90 18 92 19 94 20 96 21 98 22 127
> f6 0 64 -2 0  72  74  77  79  81  83  85  87  89  91  93  95  97  99
> f7 0 64 -2 0 0   0   0   0   0   0   0   0   0   0   0   0   0   0
> f8 0 64 -2 0 1 1 1 1 1 1 1 1 1 1 1 1 1 1
> f23 0 128 -17 0 27 57 28 59 29 61 30 63 31 65 32 67 33 69 34 71 35 74 36 76 37 78 38 80 39 82 40 84 41 86 42 88 43 90 44 92 45 127
> f24 0 64 -2 0  56  58  60  62  64  66  68  70  73  75  77  79  81  83  85  87  89  91  93
> f25 0 64 -2 0 +18 +15 +15 +19 +18 +13 +12 +10 +27 +18 +12 +16 +29 +14 +3  +36 +25 +15 +21
> f26 0 64 -2 0 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1
> f46 0 128 -17 0 50 50 51 51 52 53 53 55 54 57 55 59 56 61 57 63 58 65 59 67 60 69 61 71 62 73 63 77 64 79 65 82 66 84 67 127
> f47 0 64 -2 0  49  50  52  54  56  58  60  62  64  66  68  70  72  76  78  81  83  85
> f48 0 64 -2 0 +3  -14 -7  +1  -18 +5  -9  +16 +4  +5  +9  +13 +7  +11 +8  +3  +5  -7
> f49 0 64 -2 0 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1
> f68 0 128 -17 0 72 50 73 52 74 54 75 56 76 58 77 60 78 62 79 64 80 66 81 68 82 70 83 72 84 74 85 76 86 78 87 80 88 82 89 84 90 86 91 127
> f69 0 64 -2 0  49  51  53  55  57  59  61  63  65  67  69  71  73  75  77  79  81  83  85  87
> f70 0 64 -2 0 +10 +20 +39 +6  +6  -2  +8  +13 +29 +2  +19 +11 0   +3  +12 +12 +9  +11 +17 +7
> f71 0 64 -2 0 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1
> f27 0 0 1 "McGill/Partition F/VIOLIN W-VIB/VIOLING#3.aif" 0 4 0
> f28 0 0 1 "McGill/Partition F/VIOLIN W-VIB/VIOLINA#3.aif" 0 4 0
> f29 0 0 1 "McGill/Partition F/VIOLIN W-VIB/VIOLINC4.aif" 0 4 0
> f30 0 0 1 "McGill/Partition F/VIOLIN W-VIB/VIOLIND4.aif" 0 4 0
> f31 0 0 1 "McGill/Partition F/VIOLIN W-VIB/VIOLINE4.aif" 0 4 0
> f32 0 0 1 "McGill/Partition F/VIOLIN W-VIB/VIOLINF#4.aif" 0 4 0
> f33 0 0 1 "McGill/Partition F/VIOLIN W-VIB/VIOLING#4.aif" 0 4 0
> f34 0 0 1 "McGill/Partition F/VIOLIN W-VIB/VIOLINA#4.aif" 0 4 0
> f35 0 0 1 "McGill/Partition F/VIOLIN W-VIB/VIOLINC#5.aif" 0 4 0
> f36 0 0 1 "McGill/Partition F/VIOLIN W-VIB/VIOLIND#5.aif" 0 4 0
> f37 0 0 1 "McGill/Partition F/VIOLIN W-VIB/VIOLINF5.aif" 0 4 0
> f55 0 0 1 "McGill/Partition F/VIOLA W-VIB/VIOLAV A#3.aif" 0 4 0
> f56 0 0 1 "McGill/Partition F/VIOLA W-VIB/VIOLAV C4.aif" 0 4 0
> f57 0 0 1 "McGill/Partition F/VIOLA W-VIB/VIOLAV D4.aif" 0 4 0
> f58 0 0 1 "McGill/Partition F/VIOLA W-VIB/VIOLAV E4.aif" 0 4 0
> f59 0 0 1 "McGill/Partition F/VIOLA W-VIB/VIOLAV F#4.aif" 0 4 0
> f76 0 0 1 "McGill/Partition A/CELLO W-VIB/CELLOV A2.aif" 0 4 0
> f77 0 0 1 "McGill/Partition A/CELLO W-VIB/CELLOV B2.aif" 0 4 0
> f78 0 0 1 "McGill/Partition A/CELLO W-VIB/CELLOV C#3.aif" 0 4 0
> f79 0 0 1 "McGill/Partition A/CELLO W-VIB/CELLOV D#3.aif" 0 4 0
> f80 0 0 1 "McGill/Partition A/CELLO W-VIB/CELLOV F3.aif" 0 4 0
> f81 0 0 1 "McGill/Partition A/CELLO W-VIB/CELLOV G3.aif" 0 4 0
> f82 0 0 1 "McGill/Partition A/CELLO W-VIB/CELLOV A3.aif" 0 4 0
> f83 0 0 1 "McGill/Partition A/CELLO W-VIB/CELLOV B3.aif" 0 4 0
> f84 0 0 1 "McGill/Partition A/CELLO W-VIB/CELLOV C#4.aif" 0 4 0
> f85 0 0 1 "McGill/Partition A/CELLO W-VIB/CELLOV D#4.aif" 0 4 0
> f86 0 0 1 "McGill/Partition A/CELLO W-VIB/CELLOV F4.aif" 0 4 0
> f1 0 64 -2 0 5 23 46 68
> f2 0 64 -2 0 5  5  5  5
> ;Inst Start        Dur  Vel    Ton   Oct   Voice Stere Envlp Gliss Upsamp R-Env;Channel
> ;p1   p2           p3   p4     p5    p6    p7    p8    p9    p10   p11   R-Env;Channel
> i1  0.0000000000     8     1     0     1     1     8     0     0     0     0 ;      1
> i1  8.0000000000   160     1     0     1     1     8     0     0     0     0 ;      1
> i1 168.0000000000   160     1     0     1     1     8     0     0     0     0 ;      1
> i1 328.0000000000    96     1     0     1     1     8     0     0     0     0 ;      1
> i1 424.0000000000   160     1     0     1     1     8     0     0     0     0 ;      1
> i1 584.0000000000     8     1     0     1     1     8     0     0     0     0 ;      1
> i1  8.0000000000    49    80     0     4     2     8     1     0     0     1 ;      2
> i1 56.0000000000    17    80    30     4     2     8     1     0     0     1 ;      2
> i1 72.0000000000    65    80    60     4     2     8     1     0     0     1 ;      2
> i1 136.0000000000    81    80    65     4     2     8     1     0     0     1 ;      2
> i1 168.0000000000    49    80    23     4     2     8     1     0     0     1 ;      2
> i1 216.0000000000    32    80    18     4     2     8     1     0     0     1 ;      2
> i1 216.0000000000    32    80    60     4     2     8     1     0     0     1 ;      2
> i1 248.0000000000    17    80    37     4     2     8     1     0     0     1 ;      2
> i1 248.0000000000    17    80     7     5     2     8     1     0     0     1 ;      2
> i1 264.0000000000    17    80    48     4     2     8     1     0     0     1 ;      2
> i1 264.0000000000    17    80    18     5     2     8     1     0     0     1 ;      2
> i1 280.0000000000    33    80    24     4     2     8     1     0     0     1 ;      2
> i1 312.0000000000    33    80    24     4     2     8     1     0     0     1 ;      2
> i1 328.0000000000    33    80    66     4     2     8     1     0     0     1 ;      2
> i1 344.0000000000    17    80     7     4     2     8     1     0     0     1 ;      2
> i1 360.0000000000    17    80    43     3     2     8     1     0     0     1 ;      2
> i1 376.0000000000    33    80    54     3     2     8     1     0     0     1 ;      2
> i1 408.0000000000    65    80    27     4     2     8     1     0     0     1 ;      2
> i1 472.0000000000    17    80    31     4     2     8     1     0     0     1 ;      2
> i1 488.0000000000    65    80    55     4     2     8     1     0     0     1 ;      2
> i1 552.0000000000    41    80    69     4     2     8     1     0     0     1 ;      2
> i1  8.0000000000    49    80     0     4     2     8     1     0     1     1 ;      3
> i1 56.0000000000    49    80    30     4     2     8     1     0     1     1 ;      3
> i1 104.0000000000   145    80    35     4     2     8     1     0     1     1 ;      3
> i1 104.0000000000    65    80     4     5     2     8     1     0     1     1 ;      3
> i1 168.0000000000    49    80    13     5     2     8     1     0     0     1 ;      3
> i1 216.0000000000    33    80     4     5     2     8     1     0     0     1 ;      3
> i1 248.0000000000    89    80    66     3     2     8     1     0     0     1 ;      3
> i1 336.0000000000     9    80    43     4     2     8     1     0     0     1 ;      3
> i1 336.0000000000     9    80    13     4     2     8     1     0     0     1 ;      3
> i1 344.0000000000    17    80    49     3     2     8     1     0     0     1 ;      3
> i1 344.0000000000    17    80    37     4     2     8     1     0     0     1 ;      3
> i1 360.0000000000    33    80    31     4     2     8     1     0     0     1 ;      3
> i1 392.0000000000    81    80    40     4     2     8     1     0     0     1 ;      3
> i1 392.0000000000    81    80    11     4     2     8     1     0     0     1 ;      3
> i1 472.0000000000    49    80    31     4     2     8     1     0     0     1 ;      3
> i1 520.0000000000    65    80    35     4     2     8     1     0     0     1 ;      3
> i1 520.0000000000    65    80     5     5     2     8     1     0     0     1 ;      3
> i1  8.0000000000   118    80     0     4     3     8     1     0     0     1 ;      4
> i1 125.0000000000    22    80    64     3     3     8     1     0     0     1 ;      4
> i1 146.0000000000    23    80    13     4     3     8     1     0     0     1 ;      4
> i1 168.0000000000    65    80     4     4     3     8     1     0     0     1 ;      4
> i1 232.0000000000    17    80    71     3     3     8     1     0     0     1 ;      4
> i1 248.0000000000    17    80    66     3     3     8     1     0     0     1 ;      4
> i1 264.0000000000    17    80    24     4     3     8     1     0     0     1 ;      4
> i1 280.0000000000    17    80    18     4     3     8     1     0     0     1 ;      4
> i1 296.0000000000    17    80    13     4     3     8     1     0     0     1 ;      4
> i1 312.0000000000    17    80    66     3     3     8     1     0     0     1 ;      4
> i1 328.0000000000    17    80     2     4     3     8     1     0     0     1 ;      4
> i1 344.0000000000    17    80     7     4     3     8     1     0     0     1 ;      4
> i1 360.0000000000    33    80     1     4     3     8     1     0     0     1 ;      4
> i1 392.0000000000    33    80    67     3     3     8     1     0     0     1 ;      4
> i1 424.0000000000   118    80     2     4     3     8     1     0     0     1 ;      4
> i1 541.0000000000    22    80    65     3     3     8     1     0     0     1 ;      4
> i1 562.0000000000    23    80    15     4     3     8     1     0     0     1 ;      4
> i1 24.0000000000    65    80    42     4     4     8     1     0     0     1 ;      5
> i1 88.0000000000    50    80    48     4     4     8     1     0     0     1 ;      5
> i1 88.0000000000    50    80    18     5     4     8     1     0     0     1 ;      5
> i1 200.0000000000    97    80    48     4     4     8     1     0     0     1 ;      5
> i1 264.0000000000    33    80     7     4     4     8     1     0     0     1 ;      5
> i1 296.0000000000    49    80     2     4     4     8     1     0     0     1 ;      5
> i1 296.0000000000    49    80    43     4     4     8     1     0     0     1 ;      5
> i1 344.0000000000    49    80    61     3     4     8     1     0     0     1 ;      5
> i1 344.0000000000    17    80    19     4     4     8     1     0     0     1 ;      5
> i1 392.0000000000    33    80    54     3     4     8     1     0     0     1 ;      5
> i1 392.0000000000    33    80    24     4     4     8     1     0     0     1 ;      5
> i1 440.0000000000    65    80    41     4     4     8     1     0     0     1 ;      5
> i1 504.0000000000    50    80    49     4     4     8     1     0     0     1 ;      5
> i1 504.0000000000    50    80    19     5     4     8     1     0     0     1 ;      5
>  t0    1000       8   1000     168   1000     328   1000     424   1000     584   1000
>
> </CsScore>
> </CsoundSynthesizer>
>
>
>
>
> --- In MakeMicroMusic@yahoogroups.com, Mike Battaglia <battaglia01@...> wrote:
>>
>> See also:
>>
>> >
>> > Hz are the way to go if you want Hz. If you want pitch
>> > envelopes or vibrato with envelopes defined in cents, you
>> > have to run the lookup table gauntlet. But, even then,
>> > multiplying your target pitch by a modulation variable is
>> > going to be correct when that modulation's converted
>> > from zero. (It doesn't matter much otherwise, right?)
>> >
>> > The alternative is to convert from Hz to pitch units, add
>> > the modulation variable, and then convert back to Hz. Then
>> > you have to check your functions are accurate.
>> >
>> > As a final, desperate attempt to turn an obvious answer
>> > into an intelligent one, I'll mention that a small amount
>> > of vibrato or pitch-noise might actually help to correct
>> > the perceived pitch. It should be about the same size as
>> > the resolution of the tables you're using. Here's a
>> > helpful link:
>> >
>> > http://en.wikipedia.org/wiki/Stochastic_resonance
>> >
>> > Graham
>>
>
>
>
>
> ------------------------------------
>
> Yahoo! Groups Links
>
>
>
>

--
Aaron Krister Johnson
http://www.akjmusic.com
http://www.untwelve.org

I never thought of randomizing the articulation endpoints. What a great idea. I randomize the start times, but I never thought of doing the same for the end points. Of course, that's what happens in real life. I can't wait to try it! I've done a very crude form by making the durations separate from the lengths, but I should make the program do that work.

Prent
--- In MakeMicroMusic@yahoogroups.com, Aaron Krister Johnson <aaron@...> wrote:
>
> Great reference post, that, Prent...thanks! I'm sure Gene will have a
> lot to dig into there.
>
> You are so right about humanization tricks....in microcsound, I
> implement a gaussian distribution randomization function for such
> things as onset time and articulation endpoints, as you say. Not to
> mention the obvious trick of humanizing attack velocity, etc.
>
> Gaussian distribution random curves work well because they sort of
> model the whole "I mostly got it nailed into this narrow channel of
> values, but there are a few standout outliers" phenomenon that
> musicians naturally tend to do, as do so many natural phenomenon (e.g.
> the way stone steps might wear out based on how many people tend to
> walk in the center of the step as opposed to the side)
>
> AKJ