Hi all

Posted this on the Csound5 forum at Csounds.com - but looks like  
there's very little activity over there, so apologies if some of you  
read this twice!


I've been looking at the new HRTF opcodes, but getting rather strange  
results.

The attached .csd file is my own, and for some reason produces  
infinite amplitude. (I've attached the output from terminal at the  
end of the.csd file)

Assuming this was a simple mistake on my part, I tried the example  
given in the Manual - this time the output was zero!

Anyone got any ideas as to what I'm doing wrong??

For the record:

933 MHz PPC G4
OS X 10.4.11
Csound 5.10
Running Csound direct from terminal

Thanks,

Joe

Joe, 

Sorry that you received no response on Csounds.com.

I get the same result when rendering your CSD on my PPC G4 with OS X 10.5
and a Csound 5.10 that I compiled myself.

The problem is not you, it is Csound.  The HRTF data files contain floating
point data in little-endian byte order and Csound is not swapping the bytes
when it reads them in on a big-endian platform.  I wrote a simple program to
swap the bytes of the data files, and then your example works fine.

If you have the Apple Developer Tools installed, you can compile and run the
attached program on the data files as a workaround until the HRTF opcodes
are fixed.

To compile:    gcc -o swap4bytes swap4bytes.c
To run:        ./swap4bytes  

Anthony Kozar
mailing-lists-1001 AT anthonykozar DOT net
http://anthonykozar.net/


Joe O'Farrell wrote on 4/14/09 3:17 PM:

> 
> Hi all
> 
> Posted this on the Csound5 forum at Csounds.com - but looks like
> there's very little activity over there, so apologies if some of you
> read this twice!
> 
> 
> I've been looking at the new HRTF opcodes, but getting rather strange
> results.
> 
> The attached .csd file is my own, and for some reason produces
> infinite amplitude. (I've attached the output from terminal at the
> end of the.csd file)
> 
> Assuming this was a simple mistake on my part, I tried the example
> given in the Manual - this time the output was zero!
> 
> Anyone got any ideas as to what I'm doing wrong??
> 
> For the record:
> 
> 933 MHz PPC G4
> OS X 10.4.11
> Csound 5.10
> Running Csound direct from terminal

I thought endianess was an integer/fixe-point issue and that
all floating point data was the same regardless of processor.

Victor
----- Original Message ----- 
From: "Anthony Kozar" 
To: "Csound mailing list address" 
Sent: Wednesday, April 15, 2009 7:32 AM
Subject: [Csnd] Re: Infinite/zero amplitudes with new HRTF opcodes


> Joe,
>
> Sorry that you received no response on Csounds.com.
>
> I get the same result when rendering your CSD on my PPC G4 with OS X 10.5
> and a Csound 5.10 that I compiled myself.
>
> The problem is not you, it is Csound.  The HRTF data files contain 
> floating
> point data in little-endian byte order and Csound is not swapping the 
> bytes
> when it reads them in on a big-endian platform.  I wrote a simple program 
> to
> swap the bytes of the data files, and then your example works fine.
>
> If you have the Apple Developer Tools installed, you can compile and run 
> the
> attached program on the data files as a workaround until the HRTF opcodes
> are fixed.
>
> To compile:    gcc -o swap4bytes swap4bytes.c
> To run:        ./swap4bytes  
>
> Anthony Kozar
> mailing-lists-1001 AT anthonykozar DOT net
> http://anthonykozar.net/
>
>
> Joe O'Farrell wrote on 4/14/09 3:17 PM:
>
>>
>> Hi all
>>
>> Posted this on the Csound5 forum at Csounds.com - but looks like
>> there's very little activity over there, so apologies if some of you
>> read this twice!
>>
>>
>> I've been looking at the new HRTF opcodes, but getting rather strange
>> results.
>>
>> The attached .csd file is my own, and for some reason produces
>> infinite amplitude. (I've attached the output from terminal at the
>> end of the.csd file)
>>
>> Assuming this was a simple mistake on my part, I tried the example
>> given in the Manual - this time the output was zero!
>>
>> Anyone got any ideas as to what I'm doing wrong??
>>
>> For the record:
>>
>> 933 MHz PPC G4
>> OS X 10.4.11
>> Csound 5.10
>> Running Csound direct from terminal
>
>
> Send bugs reports to this list.
> To unsubscribe, send email sympa@lists.bath.ac.uk with body "unsubscribe 
> csound" 

> I thought endianess was an integer/fixe-point issue and that
> all floating point data was the same regardless of processor.
>
> Victor
> ----- Original Message -----
>

Let me assure you that as a compiler writer I have had 4 different byte
orders and three or four different representations of floating point.
==John

So what is IEEE floating-point supposed to be/mean?
----- Original Message ----- 
From: 
To: 
Sent: Wednesday, April 15, 2009 10:04 AM
Subject: [Csnd] Re: Re: Re: Infinite/zero amplitudes with new HRTF opcodes


>> I thought endianess was an integer/fixe-point issue and that
>> all floating point data was the same regardless of processor.
>>
>> Victor
>> ----- Original Message -----
>>
>
> Let me assure you that as a compiler writer I have had 4 different byte
> orders and three or four different representations of floating point.
> ==John
>
>
>
>
> Send bugs reports to this list.
> To unsubscribe, send email sympa@lists.bath.ac.uk with body "unsubscribe 
> csound" 

victor wrote:
> I thought endianess was an integer/fixe-point issue and that
> all floating point data was the same regardless of processor.
> 

It's all to do with the byte-addressing of memory relative to registers, 
(the byte being still the nominal baseline unit of memory**), so 
endianness applies to all multi-byte numerics. Stored in memory, a float 
is simply an array of four (or eight) bytes, and its "floatness" if I 
can call it that is a function of a higher level of computation 
(co-processor, SSE, software emulation etc). Since a float has to go via 
a main register to transfer to external ram or disk, it becomes a 
pseudo-integer and is duly treated as a numeric entity for endianness 
purposes.

Sorry if this is less than clear - been a very long time since I 
actually read up on x86 v Motorola/PPC  architectures!

Richard Dobson


** perhaps the time is close  when, Star Trek style, we will abandon the 
byte as the smallest memory unit and refer to the "quad", and thence 
"teraquads" (or "petaquads"?).

Richard Dobson wrote:
.. so
> endianness applies to all multi-byte numerics

.. I guess I should say "native" numerics. A 300 bit (or 
arbitrary-length) very-large-number would be a free-for-all format-wise. 
And even today the float is not quite a first-class native CPU type - 
values have to transfer to/from the co-processor. At least the IEEE 
standard defines the format of sign+exponent+mantissa+bias for 
portability purposes. It still leaves endianness representations to the 
needs of the host implementation. I recall being told long ago (by John 
very likely) that there were two alternative IEEE double-precision 
standards around, while there was just the one single-precision one. 
They still (AFAIK) have to go through native integer CPU registers. 
There are interesting specializations, not least Apple's 80-bit float 
format as famously used in the AIFF file format, all of which has 
likewise to be dealt with with respect to endianness.


Richard Dobson

Thanks for all the replies - at least I know I haven't totally lost  
it! (Not yet anyway… ;-)  )

Sorry if I sounded a bit huffy about Csounds.com forum - wasn't meant  
to be at all. Just noticed when I posted that the last contribution  
was from about six weeks before, so thought maybe it wasn't the first  
port of call - then I remembered the list… Merely wished to apologise  
to anyone who read the query twice.

Fairly sure the Dev tools are buried on one of the drives here  
somewhere, so will try Anthony's workround - for which MANY thanks!

Joe



PS Victor - must get round to recording Recycling properly!!

Joe O'Farrell wrote on 4/15/09 12:01 PM:

> Sorry if I sounded a bit huffy about Csounds.com forum - wasn't meant
> to be at all. Just noticed when I posted that the last contribution
> was from about six weeks before, so thought maybe it wasn't the first
> port of call - then I remembered the listŠ Merely wished to apologise
> to anyone who read the query twice.

Just to be clear, I did not think you sounded "huffy".  I was apologizing
because I don't think we are very consistent about checking the Csounds.com
forums for help requests.  I myself occassionally get into "mode" where I
spend a week responding to as many forum posts as I can but then I soon
forget to check back when things are quiet for a few days ...

> Fairly sure the Dev tools are buried on one of the drives here
> somewhere, so will try Anthony's workround - for which MANY thanks!

BTW, I'd recommend keeping the original HRTF data files around since the
next version of Csound should fix the byte-swapping issue.

Anthony

Now I remember what makes the Csound community so special…

Many thanks again to Anthony - opcode now working perfectly.

Rather more remarkably, the results were fairly close to what I'd  
planned!

Thanks again to all

Joe

> Rather more remarkably, the results were fairly close to what I'd  
> planned!

… and might have been even closer if I could tell the difference  
between .0001 and 1.0001!

What was that about LSB and MSB again?? ;-)

J