[Csnd] [PD] release of csound~ for pd

[Stefan Kersten]

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>