new piece-"Desert Prayer"

I created this using microcsound. It was basically a sketch that was
polished and repolished. I must have listened to it about 100 times already,
each time changing something subtle in the performance or the actual notes
and rhythms.

There are neat things in here with legato that are awkward in polyphonic
MIDI, but a breeze in Csound, so that was a pleasant part of preparing this.
The instrument is a slightly modified version of a legato instrument
designed by Steven Yi (mainly, I nixed the delayed vibrato so you could hear
the tuning, and did some modification so I could control portamento
parameters from microcsound)

I hope you like it. It's dedicated to Kraig Grady; something about it evoked
his world in my mind.

Can anyone hazard a guess as to the tuning system used?

http://www.akjmusic.com/audio/desert_prayer.ogg
http://www.akjmusic.com/audio/desert_prayer.mp3

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

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

> There are neat things in here with legato that are awkward in polyphonic
> MIDI, but a breeze in Csound, so that was a pleasant part of preparing this.

It would be interesting to see the mc file; neat things in performance is something I'd like to be better at.

I'll post the .mc file but I'd love to hear guesses first about the tuning!

AKJ
On May 30, 2011 1:36 PM, "genewardsmith" <genewardsmith@...>
wrote:
>
> --- In tuning@yahoogroups.com, Aaron Krister Johnson <aaron@...> wrote:
>
>> There are neat things in here with legato that are awkward in polyphonic
>> MIDI, but a breeze in Csound, so that was a pleasant part of preparing
this.
>
> It would be interesting to see the mc file; neat things in performance is
something I'd like to be better at.
>
>
>
>
>
> ------------------------------------
>
> You can configure your subscription by sending an empty email to one
> of these addresses (from the address at which you receive the list):
> tuning-subscribe@yahoogroups.com - join the tuning group.
> tuning-unsubscribe@yahoogroups.com - leave the group.
> tuning-nomail@yahoogroups.com - turn off mail from the group.
> tuning-digest@yahoogroups.com - set group to send daily digests.
> tuning-normal@yahoogroups.com - set group to send individual emails.
> tuning-help@yahoogroups.com - receive general help information.
> Yahoo! Groups Links
>
>
>

It would make logical sense that this is in Centaur tuning for social
engineering reasons.
I can't say my ears are good enough to distinguish a lot of tunings (this is
not necessarily so bad)

The feel for me is Keith Emerson in a very reflective just intonation
moment. The levels were not a problem for me.
I thought there was a sufficiently "classical" dynamic range climax towards
the middle.

It is a piece worth listening to quite a few time.

Chris

On Mon, May 30, 2011 at 1:25 PM, Aaron Krister Johnson
<aaron@akjmusic.com>wrote:

>
>
> I created this using microcsound. It was basically a sketch that was
> polished and repolished. I must have listened to it about 100 times already,
> each time changing something subtle in the performance or the actual notes
> and rhythms.
>
> There are neat things in here with legato that are awkward in polyphonic
> MIDI, but a breeze in Csound, so that was a pleasant part of preparing this.
> The instrument is a slightly modified version of a legato instrument
> designed by Steven Yi (mainly, I nixed the delayed vibrato so you could hear
> the tuning, and did some modification so I could control portamento
> parameters from microcsound)
>
> I hope you like it. It's dedicated to Kraig Grady; something about it
> evoked his world in my mind.
>
> Can anyone hazard a guess as to the tuning system used?
>
> http://www.akjmusic.com/audio/desert_prayer.ogg
> http://www.akjmusic.com/audio/desert_prayer.mp3
>
> --
> Aaron Krister Johnson
> http://www.akjmusic.com
> http://www.untwelve.org
>
>
>

--- In tuning@yahoogroups.com, Aaron Krister Johnson <aaron@...> wrote:
>
> I'll post the .mc file but I'd love to hear guesses first about the tuning!

Great!

If anyone is interested in comparing/contrasting, I uploaded newer,
normalized to -3db files:

http://www.akjmusic.com/audio/desert_prayer_normalized.ogg
http://www.akjmusic.com/audio/desert_prayer_normalized.mp3

The piece has a big dynamic range, so short of compression, which I try to
avoid, and which mp3 sort of does anyway, not much can be done other than
giving it a boost.....and I'm also trying to, these days, keep some headroom
so as not to take part in this:

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

AKJ

On Mon, May 30, 2011 at 8:17 PM, Chris Vaisvil <chrisvaisvil@...>wrote:

>
>
> It would make logical sense that this is in Centaur tuning for social
> engineering reasons.
> I can't say my ears are good enough to distinguish a lot of tunings (this
> is not necessarily so bad)
>
> The feel for me is Keith Emerson in a very reflective just intonation
> moment. The levels were not a problem for me.
> I thought there was a sufficiently "classical" dynamic range climax towards
> the middle.
>
> It is a piece worth listening to quite a few time.
>
> Chris
>
>
> On Mon, May 30, 2011 at 1:25 PM, Aaron Krister Johnson <aaron@...
> > wrote:
>
>>
>>
>> I created this using microcsound. It was basically a sketch that was
>> polished and repolished. I must have listened to it about 100 times already,
>> each time changing something subtle in the performance or the actual notes
>> and rhythms.
>>
>> There are neat things in here with legato that are awkward in polyphonic
>> MIDI, but a breeze in Csound, so that was a pleasant part of preparing this.
>> The instrument is a slightly modified version of a legato instrument
>> designed by Steven Yi (mainly, I nixed the delayed vibrato so you could hear
>> the tuning, and did some modification so I could control portamento
>> parameters from microcsound)
>>
>> I hope you like it. It's dedicated to Kraig Grady; something about it
>> evoked his world in my mind.
>>
>> Can anyone hazard a guess as to the tuning system used?
>>
>> http://www.akjmusic.com/audio/desert_prayer.ogg
>> http://www.akjmusic.com/audio/desert_prayer.mp3
>>
>> --
>> Aaron Krister Johnson
>> http://www.akjmusic.com
>> http://www.untwelve.org
>>
>>
>
>
>

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

On Mon, May 30, 2011 at 1:25 PM, Aaron Krister Johnson
<aaron@...> wrote:
>
> I created this using microcsound. It was basically a sketch that was polished and repolished. I must have listened to it about 100 times already, each time changing something subtle in the performance or the actual notes and rhythms.
>
> There are neat things in here with legato that are awkward in polyphonic MIDI, but a breeze in Csound, so that was a pleasant part of preparing this. The instrument is a slightly modified version of a legato instrument designed by Steven Yi (mainly, I nixed the delayed vibrato so you could hear the tuning, and did some modification so I could control portamento parameters from microcsound)
>
> I hope you like it. It's dedicated to Kraig Grady; something about it evoked his world in my mind.
> Can anyone hazard a guess as to the tuning system used?
> http://www.akjmusic.com/audio/desert_prayer.ogg
> http://www.akjmusic.com/audio/desert_prayer.mp3

I choose 34-equal?

-Mike

Aaron Krister Johnson <aaron@...> wrote:

> The piece has a big dynamic range, so short of compression,
> which I try to avoid, and which mp3 sort of does anyway,
> not much can be done other than giving it a boost.....and
> I'm also trying to, these days, keep some headroom
> so as not to take part in this:
> http://en.wikipedia.org/wiki/Loudness_war
>
> AKJ

Good show, don't compress it. You're right on the money
now at 91dB with no clipping. The Replay Gain spec calls
for 89 but 91 is perfectly alright.

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

-Carl

Carl,

I'm used to the 0dbfs standard, where 0db is the highest value without
clipping (in 16bit, it would be 32767)....so I'm not sure where/what
software you're using to see levels up in the 80s or 90s....can you clue me
in? I realize it's decibels, but I don't see how it can have any absolute
meaning without reference to the amplification and volume control involved,
which may vary according to listener settings.

AKJ

On Tue, May 31, 2011 at 3:13 AM, Carl Lumma <carl@...> wrote:

> Aaron Krister Johnson <aaron@...> wrote:
>
> > The piece has a big dynamic range, so short of compression,
> > which I try to avoid, and which mp3 sort of does anyway,
> > not much can be done other than giving it a boost.....and
> > I'm also trying to, these days, keep some headroom
> > so as not to take part in this:
> > http://en.wikipedia.org/wiki/Loudness_war
> >
> > AKJ
>
> Good show, don't compress it. You're right on the money
> now at 91dB with no clipping. The Replay Gain spec calls
> for 89 but 91 is perfectly alright.
>
> http://en.wikipedia.org/wiki/Replaygain
>
> -Carl
>
>
>
> ------------------------------------
>
> You can configure your subscription by sending an empty email to one
> of these addresses (from the address at which you receive the list):
> tuning-subscribe@yahoogroups.com - join the tuning group.
> tuning-unsubscribe@yahoogroups.com - leave the group.
> tuning-nomail@yahoogroups.com - turn off mail from the group.
> tuning-digest@yahoogroups.com - set group to send daily digests.
> tuning-normal@yahoogroups.com - set group to send individual emails.
> tuning-help@yahoogroups.com - receive general help information.
> Yahoo! Groups Links
>
>
>
>

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

It is SMPTE (film) based.

-20dBFS = 83dBSPL
so 89dBSPL = -14dBFS

There is a bit more to it than this but is at least the ballpark..

Steve P.

> Carl,
>
>
> I'm used to the 0dbfs standard, where 0db is the highest value
> without clipping (in 16bit, it would be 32767)....so I'm not sure
> where/what software you're using to see levels up in the 80s or
> 90s....can you clue me in? I realize it's decibels, but I don't see
> how it can have any absolute meaning without reference to the
> amplification and volume control involved, which may vary according
> to listener settings.
>
> AKJ
>
> On Tue, May 31, 2011 at 3:13 AM, Carl Lumma <carl@...> wrote:
> Aaron Krister Johnson <aaron@...> wrote:
>
> > The piece has a big dynamic range, so short of compression,
> > which I try to avoid, and which mp3 sort of does anyway,
> > not much can be done other than giving it a boost.....and
> > I'm also trying to, these days, keep some headroom
> > so as not to take part in this:
> > http://en.wikipedia.org/wiki/Loudness_war
> >
> > AKJ
>
> Good show, don't compress it. You're right on the money
> now at 91dB with no clipping. The Replay Gain spec calls
> for 89 but 91 is perfectly alright.
>
> http://en.wikipedia.org/wiki/Replaygain
>
> -Carl
>
>
>
> ------------------------------------
>
> You can configure your subscription by sending an empty email to one
> of these addresses (from the address at which you receive the list):
> tuning-subscribe@yahoogroups.com - join the tuning group.
> tuning-unsubscribe@yahoogroups.com - leave the group.
> tuning-nomail@yahoogroups.com - turn off mail from the group.
> tuning-digest@yahoogroups.com - set group to send daily digests.
> tuning-normal@yahoogroups.com - set group to send individual emails.
> tuning-help@yahoogroups.com - receive general help information.
> Yahoo! Groups Links
>
>
>
>
>
>
> --
> Aaron Krister Johnson
> http://www.akjmusic.com
> http://www.untwelve.org
>
>
>

Hi Aaron,

> I'm used to the 0dbfs standard, where 0db is the highest value
> without clipping (in 16bit, it would be 32767)....so I'm not
> sure where/what software you're using to see levels up in
> the 80s or 90s....can you clue me in?

That's the RMS average of the whole file (the mp3 file).

> I realize it's decibels, but I don't see how it can have any
> absolute meaning without reference to the amplification and
> volume control involved, which may vary according to listener
> settings.

I'm not sure exactly how Replay Gain anchors its decibels.

But yeah, you know the point of Replay Gain is that you don't
have to normalize the source, right? I figured you'd be all
over it since ogg supports it. To be fair, I haven't checked
the ogg file.

-Carl

Sounds interesting, and dammit, no, I didn't know about replay gain. Jeez,
the things I need to learn.... :)

So, how is the effect of this audibly different than compression?

AKJ

On Tue, May 31, 2011 at 11:59 AM, Carl Lumma <carl@...> wrote:

> Hi Aaron,
>
> > I'm used to the 0dbfs standard, where 0db is the highest value
> > without clipping (in 16bit, it would be 32767)....so I'm not
> > sure where/what software you're using to see levels up in
> > the 80s or 90s....can you clue me in?
>
> That's the RMS average of the whole file (the mp3 file).
>
> > I realize it's decibels, but I don't see how it can have any
> > absolute meaning without reference to the amplification and
> > volume control involved, which may vary according to listener
> > settings.
>
> I'm not sure exactly how Replay Gain anchors its decibels.
>
> But yeah, you know the point of Replay Gain is that you don't
> have to normalize the source, right? I figured you'd be all
> over it since ogg supports it. To be fair, I haven't checked
> the ogg file.
>
> -Carl
>
>
>
> ------------------------------------
>
> You can configure your subscription by sending an empty email to one
> of these addresses (from the address at which you receive the list):
> tuning-subscribe@yahoogroups.com - join the tuning group.
> tuning-unsubscribe@yahoogroups.com - leave the group.
> tuning-nomail@yahoogroups.com - turn off mail from the group.
> tuning-digest@yahoogroups.com - set group to send daily digests.
> tuning-normal@yahoogroups.com - set group to send individual emails.
> tuning-help@yahoogroups.com - receive general help information.
> Yahoo! Groups Links
>
>
>
>

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

--- Aaron Krister Johnson <aaron@...> wrote:

> Sounds interesting, and dammit, no, I didn't know about replay
> gain. Jeez, the things I need to learn.... :)

You mean you didn't follow the link to Replay Gain I sent two
messages ago? :)

> So, how is the effect of this audibly different than compression?

It's not compression! I think you mean, how's it different
to normalization. It isn't, except it's non-destructive on
the original recording since it's applied at playback.
Normalization does cause rounding errors to accumulate.
It's actually significant at 16 bits though not really at 32.
But in principle it's smarter to tell the player how loud you
are. Then I can set my player however I like.

-Carl

Hey Carl,

Yes I did follow the link! I was just relating that that was the first time
I heard of Replay Gain....your mention if it. :)

Right...normalization..so what you're saying is the Vorbis encodes peak info
in metadata tags? Neat. That's great and another reason to evangelize off
files for me over mp3...Carl, you shouldn't have.

I can see the advantage of this over losing the low bit info, for
sure.....thanks for bringing this to my awareness.

I suppose with purely electronic things like Csound, this means that the
best thing is to encode near normalized volumes when first rendering so as
to avoid the redundancy of post-normalizing. Allows you to create and
preserve more details due to better bit depth. And, when recording acoustic
instruments, going as hot as you can while being mindful of having 3db or so
of headroom just in case as insurance.

AKJ
On May 31, 2011 4:41 PM, "Carl Lumma" <carl@...> wrote:
> --- Aaron Krister Johnson <aaron@...> wrote:
>
>> Sounds interesting, and dammit, no, I didn't know about replay
>> gain. Jeez, the things I need to learn.... :)
>
> You mean you didn't follow the link to Replay Gain I sent two
> messages ago? :)
>
>> So, how is the effect of this audibly different than compression?
>
> It's not compression! I think you mean, how's it different
> to normalization. It isn't, except it's non-destructive on
> the original recording since it's applied at playback.
> Normalization does cause rounding errors to accumulate.
> It's actually significant at 16 bits though not really at 32.
> But in principle it's smarter to tell the player how loud you
> are. Then I can set my player however I like.
>
> -Carl
>
>
>
> ------------------------------------
>
> You can configure your subscription by sending an empty email to one
> of these addresses (from the address at which you receive the list):
> tuning-subscribe@yahoogroups.com - join the tuning group.
> tuning-unsubscribe@yahoogroups.com - leave the group.
> tuning-nomail@yahoogroups.com - turn off mail from the group.
> tuning-digest@yahoogroups.com - set group to send daily digests.
> tuning-normal@yahoogroups.com - set group to send individual emails.
> tuning-help@yahoogroups.com - receive general help information.
> Yahoo! Groups Links
>
>
>

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

> Right...normalization..so what you're saying is the Vorbis
> encodes peak info in metadata tags? Neat. That's great and
> another reason to evangelize off files for me over mp3...
> Carl, you shouldn't have.

mp3 can do it too, though AFAIK it's not part of the standard.

-Carl

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

> I can see the advantage of this over losing the low bit info, for
> sure.....thanks for bringing this to my awareness.

I doubt normalizing degrades things very much--does anyone who might actually know care to comment? I've never noticed such a thing, for what that's worth.

On Wed, Jun 1, 2011 at 2:15 AM, genewardsmith
<genewardsmith@...> wrote:
>
> --- In tuning@yahoogroups.com, Aaron Krister Johnson <aaron@...> wrote:
>
> > I can see the advantage of this over losing the low bit info, for
> > sure.....thanks for bringing this to my awareness.
>
> I doubt normalizing degrades things very much--does anyone who might actually know care to comment? I've never noticed such a thing, for what that's worth.

It's not so much the normalizing that degrades things as it is that if
you record at a low amplitude you've thrown away bit depth, and then
increasing the volume isn't going to bring it back. From a more
theoretical perspective, to amplify after the fact will amplify the
quantization error along with the signal, so the goal is to record as
hot as possible without clipping.

Aside from the issue of preventing high levels of quantization error,
normalizing after the fact would mean additional roundoff error
accumulating. This post-normalization roundoff error can be treated as
a "noise source" that you're adding to the original signal again. It
will have an amplitude of at most one bit. This means for a 16-bit
signal, its amplitude in dBFS will be maximized at 10 * log(1 /
(2^16)) = -48.165 dBFS peak to peak. Not completely inaudible, but not
the end of the world either. If you're instead concerned with power
then multiply that by 2 to get ~96 dBFS which is about what the cited
figure for the noise floor for 16-bit sampling generally is, except
you're supposed to add 1.76 for some reason and I don't remember why.
Either way, all of this noise is going to actually be harmonic and
intermodulation distortion products from the original signal.

In practice I never notice anything from normalizing after the fact,
nor do I notice much from FFTs done on fixed-point processors which
can cause similar roundoff error. I do notice a huge difference with
regard to quantization error and how hot you record the signal to
begin with.

-Mike

If you record to 24 bits you can peak at -20 and normalise without fear of loss. Not needing to be hot is a good reason for 24bits.
Steve P.

On 1 Jun 2011, at 07:41, Mike Battaglia <battaglia01@...> wrote:

> On Wed, Jun 1, 2011 at 2:15 AM, genewardsmith
> <genewardsmith@...> wrote:
> >
> > --- In tuning@yahoogroups.com, Aaron Krister Johnson <aaron@...> wrote:
> >
> > > I can see the advantage of this over losing the low bit info, for
> > > sure.....thanks for bringing this to my awareness.
> >
> > I doubt normalizing degrades things very much--does anyone who might actually know care to comment? I've never noticed such a thing, for what that's worth.
>
> It's not so much the normalizing that degrades things as it is that if
> you record at a low amplitude you've thrown away bit depth, and then
> increasing the volume isn't going to bring it back. From a more
> theoretical perspective, to amplify after the fact will amplify the
> quantization error along with the signal, so the goal is to record as
> hot as possible without clipping.
>
> Aside from the issue of preventing high levels of quantization error,
> normalizing after the fact would mean additional roundoff error
> accumulating. This post-normalization roundoff error can be treated as
> a "noise source" that you're adding to the original signal again. It
> will have an amplitude of at most one bit. This means for a 16-bit
> signal, its amplitude in dBFS will be maximized at 10 * log(1 /
> (2^16)) = -48.165 dBFS peak to peak. Not completely inaudible, but not
> the end of the world either. If you're instead concerned with power
> then multiply that by 2 to get ~96 dBFS which is about what the cited
> figure for the noise floor for 16-bit sampling generally is, except
> you're supposed to add 1.76 for some reason and I don't remember why.
> Either way, all of this noise is going to actually be harmonic and
> intermodulation distortion products from the original signal.
>
> In practice I never notice anything from normalizing after the fact,
> nor do I notice much from FFTs done on fixed-point processors which
> can cause similar roundoff error. I do notice a huge difference with
> regard to quantization error and how hot you record the signal to
> begin with.
>
> -Mike
>

The standard floats version of Csound renders 32-bit audio internally before
conversion to standard 16-bit wag audio, and the doubles version does the
same with an incredible 64 bits!

There was an article about how it's audibly apparent; I.e. the difference
between 64 and 32....in any event Csound doubles version is supposed to be
one of the smoothest signal generators around, or so say the developers.

The point being when using it, one should try to get the signal reasonably
hot as usual to preserve the smooth effect of this incredible bit depth in
16bits, as usual.

This opens up the whole topic as well of noise floor dithering, too, which
is considered good practice. I'm not sure what a survey would reveal about
dithering being a standard rendering option in most DAWS, that would be
interesting.

AKJ
On Jun 1, 2011 4:33 AM, "Steve Parker" <steve@...> wrote:
> If you record to 24 bits you can peak at -20 and normalise without fear of
loss. Not needing to be hot is a good reason for 24bits.
> Steve P.
>
> On 1 Jun 2011, at 07:41, Mike Battaglia <battaglia01@...> wrote:
>
>> On Wed, Jun 1, 2011 at 2:15 AM, genewardsmith
>> <genewardsmith@...> wrote:
>> >
>> > --- In tuning@yahoogroups.com, Aaron Krister Johnson <aaron@...> wrote:
>> >
>> > > I can see the advantage of this over losing the low bit info, for
>> > > sure.....thanks for bringing this to my awareness.
>> >
>> > I doubt normalizing degrades things very much--does anyone who might
actually know care to comment? I've never noticed such a thing, for what
that's worth.
>>
>> It's not so much the normalizing that degrades things as it is that if
>> you record at a low amplitude you've thrown away bit depth, and then
>> increasing the volume isn't going to bring it back. From a more
>> theoretical perspective, to amplify after the fact will amplify the
>> quantization error along with the signal, so the goal is to record as
>> hot as possible without clipping.
>>
>> Aside from the issue of preventing high levels of quantization error,
>> normalizing after the fact would mean additional roundoff error
>> accumulating. This post-normalization roundoff error can be treated as
>> a "noise source" that you're adding to the original signal again. It
>> will have an amplitude of at most one bit. This means for a 16-bit
>> signal, its amplitude in dBFS will be maximized at 10 * log(1 /
>> (2^16)) = -48.165 dBFS peak to peak. Not completely inaudible, but not
>> the end of the world either. If you're instead concerned with power
>> then multiply that by 2 to get ~96 dBFS which is about what the cited
>> figure for the noise floor for 16-bit sampling generally is, except
>> you're supposed to add 1.76 for some reason and I don't remember why.
>> Either way, all of this noise is going to actually be harmonic and
>> intermodulation distortion products from the original signal.
>>
>> In practice I never notice anything from normalizing after the fact,
>> nor do I notice much from FFTs done on fixed-point processors which
>> can cause similar roundoff error. I do notice a huge difference with
>> regard to quantization error and how hot you record the signal to
>> begin with.
>>
>> -Mike
>>

Aaron, I just got around to listening to this, and I want you to know I
really like it. It really works as a "Desert Prayer" for me.

Now back to your regularly scheduled Csound discussion.... :)

Regards,
Jake

Thanks, Jake, I appreciate the comment!

BTW, I mentioned that article on the audibility of Csound floats vs. doubles
in ABX listening:

http://ruccas.org/pub/Gogins/*csound*abx.pdf

Reminds me that I should really be rendering my Csound things in the doubles
version, although honestly the floats version is fine for me, and obviously
has the slight edge for speed in RT situations, and that become critical
with certain things, like physical models.

AKJ

On Wed, Jun 1, 2011 at 8:58 AM, Jake Freivald <jdfreivald@...> wrote:

>
>
> Aaron, I just got around to listening to this, and I want you to know I
> really like it. It really works as a "Desert Prayer" for me.
>
> Now back to your regularly scheduled Csound discussion.... :)
>
> Regards,
> Jake
>
>
>
>

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

On 1 Jun 2011, at 14:34, Aaron Krister Johnson wrote:

> The point being when using it, one should try to get the signal > reasonably hot as usual to preserve the smooth effect of this > incredible bit depth in 16bits, as usual.

One should normalize at the point of truncation.
There is absolutely no need for a hot signal if storing with 24 bits or more.
The audio isn't smoother, the noise floor is just lower down.
Even with 24 the quantization noise is a long way below other noises present.

Steve P.

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

> > I can see the advantage of this over losing the low bit info, for
> > sure.....thanks for bringing this to my awareness.
>
> I doubt normalizing degrades things very much--does anyone
> who might actually know care to comment?

It's audible if you do it a few times. I dunno about "much".

Regardless, it still makes sense for all audio sources
to tell us how loud they are.

-Carl

For some reason I got a feeling similar to when I'm playing with 11 equal.

--- In tuning@yahoogroups.com, Aaron Krister Johnson <aaron@...> wrote:
>
> I created this using microcsound. It was basically a sketch that was
> polished and repolished. I must have listened to it about 100 times already,
> each time changing something subtle in the performance or the actual notes
> and rhythms.
>
> There are neat things in here with legato that are awkward in polyphonic
> MIDI, but a breeze in Csound, so that was a pleasant part of preparing this.
> The instrument is a slightly modified version of a legato instrument
> designed by Steven Yi (mainly, I nixed the delayed vibrato so you could hear
> the tuning, and did some modification so I could control portamento
> parameters from microcsound)
>
> I hope you like it. It's dedicated to Kraig Grady; something about it evoked
> his world in my mind.
>
> Can anyone hazard a guess as to the tuning system used?
>
> http://www.akjmusic.com/audio/desert_prayer.ogg
> http://www.akjmusic.com/audio/desert_prayer.mp3
>
> --
> Aaron Krister Johnson
> http://www.akjmusic.com
> http://www.untwelve.org
>

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

> I'm not sure what a survey would reveal about
> dithering being a standard rendering option in most DAWS, that
> would be interesting.

It's available in all DAWs I know of. I've been doing
it since the '90s. -C.

You're right about 24bits (having no need to record hot)....specifically, I
was referring to the fact that Csound *internally* calculates in 32- or
64-bit values, then translates the info 16-bit when rendering to .wav
(although there is an option for 24-bit using the flag "--format=24bit" or
"-3" option)

AKJ

On Wed, Jun 1, 2011 at 10:11 AM, Steve Parker <steve@...> wrote:

>
>
>
> On 1 Jun 2011, at 14:34, Aaron Krister Johnson wrote:
>
> The point being when using it, one should try to get the signal reasonably
> hot as usual to preserve the smooth effect of this incredible bit depth in
> 16bits, as usual.
>
>
> One should normalize at the point of truncation.
> There is absolutely no need for a hot signal if storing with 24 bits or
> more.
> The audio isn't smoother, the noise floor is just lower down.
> Even with 24 the quantization noise is a long way below other noises
> present.
>
> Steve P.
>
>
>
>
>

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

Aaron Krister Johnson <aaron@...> wrote:
> You're right about 24bits (having no need to record
> hot)....specifically, I was referring to the fact that
> Csound *internally* calculates in 32- or 64-bit values,
> then translates the info 16-bit when rendering to .wav
> (although there is an option for 24-bit using the flag
> "--format=24bit" or "-3" option)

I believe Csound also uses floating point internally, so
the level's completely irrelevant until you render.

Graham

--- In tuning@yahoogroups.com, Graham Breed <gbreed@...> wrote:
>
> Aaron Krister Johnson <aaron@...> wrote:
> > You're right about 24bits (having no need to record
> > hot)....specifically, I was referring to the fact that
> > Csound *internally* calculates in 32- or 64-bit values,
> > then translates the info 16-bit when rendering to .wav
> > (although there is an option for 24-bit using the flag
> > "--format=24bit" or "-3" option)
>
> I believe Csound also uses floating point internally, so
> the level's completely irrelevant until you render.

But floating point numbers are still represented in bits so
why should level be irrelevant?

Kalle

"Kalle Aho" <kalleaho@...> wrote:
>
> --- In tuning@yahoogroups.com, Graham Breed <gbreed@...>
> wrote:

> > I believe Csound also uses floating point internally, so
> > the level's completely irrelevant until you render.
>
> But floating point numbers are still represented in bits
> so why should level be irrelevant?

Because you can change the level by changing the exponent,
and leaving the mantissa untouched. IEEE 32-bit floating
point gives you a range of 2^-126 with the exponent, so
numbers down to 1.2e-38. That's huge.

Another way of thinking about it: you effectively have a 24
bit mantissa. It's effectively standard 24-bit PCM
along with an integer telling you the level . . . down to
37 leading zeros as a decimal.

Graham

--- In tuning@yahoogroups.com, Graham Breed <gbreed@...> wrote:
>
> "Kalle Aho" <kalleaho@...> wrote:
> >
> > --- In tuning@yahoogroups.com, Graham Breed <gbreed@>
> > wrote:
>
> > > I believe Csound also uses floating point internally, so
> > > the level's completely irrelevant until you render.
> >
> > But floating point numbers are still represented in bits
> > so why should level be irrelevant?
>
> Because you can change the level by changing the exponent,
> and leaving the mantissa untouched. IEEE 32-bit floating
> point gives you a range of 2^-126 with the exponent, so
> numbers down to 1.2e-38. That's huge.
>
> Another way of thinking about it: you effectively have a 24
> bit mantissa. It's effectively standard 24-bit PCM
> along with an integer telling you the level . . . down to
> 37 leading zeros as a decimal.

Ah, OK. So why do they recommend rendering finished Csound pieces in
double precision? What effect does it have on the sound?

Kalle

"Kalle Aho" <kalleaho@...> wrote:

> Ah, OK. So why do they recommend rendering finished
> Csound pieces in double precision? What effect does it
> have on the sound?

Csound uses a single floating point type for everything,
not only the audio rendering. Experiment has shown that
switching from C floats to doubles (32- to 64-bit) can
improve the sound. It's probably because of cumulative
rounding errors in some of the opcodes. If they knew which
ones, they could probably fix them fairly easily to work
with plain floats. But it's easier still to use doubles
everywhere, and doesn't have much overhead (C libraries are
optimized for doubles anyway), so that's recommended.

Graham

There's a big difference between processing in double precision and rendering to it.
There are plenty of good reasons for the former but none for the latter.

Steve P.

On 2 Jun 2011, at 19:16, Graham Breed wrote:

> > Ah, OK. So why do they recommend rendering finished
> > Csound pieces in double precision? What effect does it
> > have on the sound?
>
> Csound uses a single floating point type for everything,
> not only the audio rendering. Experiment has shown that
> switching from C floats to doubles (32- to 64-bit) can
> improve the sound. It's probably because of cumulative
> rounding errors in some of the opcodes. If they knew which
> ones, they could probably fix them fairly easily to work
> with plain floats. But it's easier still to use doubles
> everywhere, and doesn't have much overhead (C libraries are
> optimized for doubles anyway), so that's recommended.

--- In tuning@yahoogroups.com, Graham Breed <gbreed@...> wrote:
>
> "Kalle Aho" <kalleaho@...> wrote:
>
> > Ah, OK. So why do they recommend rendering finished
> > Csound pieces in double precision? What effect does it
> > have on the sound?
>
> Csound uses a single floating point type for everything,
> not only the audio rendering. Experiment has shown that
> switching from C floats to doubles (32- to 64-bit) can
> improve the sound. It's probably because of cumulative
> rounding errors in some of the opcodes. If they knew which
> ones, they could probably fix them fairly easily to work
> with plain floats. But it's easier still to use doubles
> everywhere, and doesn't have much overhead (C libraries are
> optimized for doubles anyway), so that's recommended.

OK, thanks!

--- In tuning@yahoogroups.com, Steve Parker <steve@...> wrote:
>
> There's a big difference between processing in double precision and
> rendering to it.
> There are plenty of good reasons for the former but none for the latter.
>
> Steve P.

I meant rendering *with* double precision version of Csound, not
rendering to double precision.

Kalle

> On 2 Jun 2011, at 19:16, Graham Breed wrote:
>
> > > Ah, OK. So why do they recommend rendering finished
> > > Csound pieces in double precision? What effect does it
> > > have on the sound?
> >
> > Csound uses a single floating point type for everything,
> > not only the audio rendering. Experiment has shown that
> > switching from C floats to doubles (32- to 64-bit) can
> > improve the sound. It's probably because of cumulative
> > rounding errors in some of the opcodes. If they knew which
> > ones, they could probably fix them fairly easily to work
> > with plain floats. But it's easier still to use doubles
> > everywhere, and doesn't have much overhead (C libraries are
> > optimized for doubles anyway), so that's recommended.
>

Ah.. understood!

Steve P.

On 2 Jun 2011, at 20:47, Kalle Aho wrote:

> I meant rendering *with* double precision version of Csound, not
> rendering to double precision.