Richard Dobson wrote:

Changing orcs according to the i/o range is the one thing we need to avoid. We need orcs to be completely portable.

i agree.

The problem is only that of the 'raw' range. I maintain that the only sane range (and one compatible with everythng else, clearly including MAX/MSP and PD) is +-1.0. But ~some~ users reserve the right to read/write raw floats in any range whatsoever (or rather, in no range!), so we need to cover that somehow. At the moment, in my 0dbfs code, I have 1.0 hard-coded as the floats range, everywhere, except for 'raw' where I ignore 0dbfs completely, and use Istvan's 'floatran_noscl' alternatives. But this is clearly wrong for csound~ in PD, and presumably for csound~ in Max too.

but what amplitude range corresponds to 0dB inside an orchestra? +-1.0? are there actually opcodes that expect different ranges to work properly? if i'm not missing anything, 0dbfs is used for interfacing with the external world, while there still needs to be a means to specify the dynamic range inside an orchestra (or keep it fixed at a reasonable default, e.g. +-1.0). i seem to be confused :)

All we need is a mechanism (possibly in the main 'O' structure) to signal use of 0dbfs (or the current formatted conversions) for raw streams. As I consider this will be the predominant behaviour for the majority of Csound users (and certianly for Csound running uinside PD or MAX), I would like to make this the default, and have a command flag, if one is needed at all, to suppress 0dbfs conversion for raw files only. As by definition, 'raw' data can never come in from hardware, only from disk, it should be possible (haven't looked at the code yet) to override 'raw' automatically when input is from a real-time source. If this is sufficient, then no flag is needed.

note that a realtime source doesn't necessarily have to be a hardware device (as in csound~, both msp and pd).

If streamed floats in a different range really are a possibility, one trick might be to add an optional numeric argument to the -f flag, such as " -f1000" to say that the range of incoming floats is +- 1000.0.

sounds reasonable.

Ironically, had I kept in the code that (unintentionally) converted raw float streams, PD Csound might well be working already!

yes, it does. in not so recent versions of csound ;)

I'm now applying 0dbfs handling to soundin and diskin. A ~lot~ of easy but tedious code to add in <sigh>.

thanks for your efforts!

<sk>