This is a strange requirement. It disallows a 5.1 file, a 2nd-order B Format 
file (9 channels). While the latter is admittedly a little esoteric (but not 
much), 5.1 is the most likely multi-channel file format for most users working 
in surround. Does it really have to be a power of two?

Richard Dobson

Istvan Varga wrote:
..
> the orchestra sr setting. diskin2 can also read multichannel files (the
> number of channels must be power of two), 


...



-------------------------------------------------------
SF email is sponsored by - The IT Product Guide
Read honest & candid reviews on hundreds of IT Products from real users.
Discover which products truly live up to the hype. Start reading now.
http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click
_______________________________________________
Csound-devel mailing list
Csound-devel@lists.sourceforge.net

Richard Dobson wrote:

> This is a strange requirement. It disallows a 5.1 file, a 2nd-order B 
> Format file (9 channels). While the latter is admittedly a little 
> esoteric (but not much), 5.1 is the most likely multi-channel file 
> format for most users working in surround. Does it really have to be a 
> power of two?

Maybe this requirement could be eliminated by dynamically
allocating the buffers (which of course makes the code more
complicated). The reason for requiring power of two file
channels was that libsndfile can only read and seek the
sound file at sample frame boundaries, and buffers of 4096
mono samples (contained in the opcode structure) are used
by the opcode.
On the other hand, I may consider removing the feature of
channel mapping, and just require having the same number of
output variables as the number of channels in the file.


-------------------------------------------------------
SF email is sponsored by - The IT Product Guide
Read honest & candid reviews on hundreds of IT Products from real users.
Discover which products truly live up to the hype. Start reading now.
http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click
_______________________________________________
Csound-devel mailing list
Csound-devel@lists.sourceforge.net

Istvan,

5.1 support is quite essential.  Having a disking opcode that supported 5.1
would be a major addition to the language.  I hope that this new opcode can
be adapted to support this format/need.

Dr. B.

on 3/20/05 2:10 PM, Istvan Varga at istvan_v@fibermail.hu wrote:

> Richard Dobson wrote:
> 
>> This is a strange requirement. It disallows a 5.1 file, a 2nd-order B
>> Format file (9 channels). While the latter is admittedly a little
>> esoteric (but not much), 5.1 is the most likely multi-channel file
>> format for most users working in surround. Does it really have to be a
>> power of two?
> 
> Maybe this requirement could be eliminated by dynamically
> allocating the buffers (which of course makes the code more
> complicated). The reason for requiring power of two file
> channels was that libsndfile can only read and seek the
> sound file at sample frame boundaries, and buffers of 4096
> mono samples (contained in the opcode structure) are used
> by the opcode.
> On the other hand, I may consider removing the feature of
> channel mapping, and just require having the same number of
> output variables as the number of channels in the file.
> 
> 
> -------------------------------------------------------
> SF email is sponsored by - The IT Product Guide
> Read honest & candid reviews on hundreds of IT Products from real users.
> Discover which products truly live up to the hype. Start reading now.
> http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click
> _______________________________________________
> Csound-devel mailing list
> Csound-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/csound-devel

_______________________________________________________________________
 +  Dr. Richard Boulanger, Professor
 +  Music Synthesis Department, Berklee College of Music
 +  1140 Boylston Street  - Boston, MA  02215-3693
 +  Office Phone: (617) 747-2485   Office Fax: (617) 747-2564
 +  eMail: rboulanger@csounds.com  or  rboulanger@berklee.edu
 +  WebPage: http://csounds.com/boulanger/
________________________________________________________________________
 +  Almost Everything Csound @ http://csounds.com/
 +  The Csound Catalog with Audio @ http://csounds.com/catalog/
 +  The Csound Book @ http://csounds.com/book/
 +  The Csound Magazine @ http://csounds.com/ezine/
 +  CsoundForums @ http://csounds.com/phpBB2/
________________________________________________________________________



-------------------------------------------------------
SF email is sponsored by - The IT Product Guide
Read honest & candid reviews on hundreds of IT Products from real users.
Discover which products truly live up to the hype. Start reading now.
http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click
_______________________________________________
Csound-devel mailing list
Csound-devel@lists.sourceforge.net

looks good - thanks especially for implementing cubic interp on diskin
ive been wanting that for a while!

but i do have some comments:

+ i see no reason to have 'diskin2' -- just replace diskin!

+ you are breakng the convention csound has for separate opcodes
for interpolation types [ oscil, oscili, oscil3 ].  i would think it 
would be
better to stay within that.   [ i myself actually would prefer to 
change all the
other opcodes to only have one version with an interp parameater like 
you
are doing here, but i have always got the impression from everybody else
that opcode inflation is preferred ]

+ no 24-bit support?

+ why stop at 16channels?  soundin supports something like 24

+ channelmap doesnt seem that useful to me.   id rather just have 
output args
    and ignore the ones i dont want -- although i do think its useful to 
be able
    to have option # of outputs that are not dependent on the # of 
channels in
    the file.   anyway, if you or others DO think it is useful, what 
about putting that
    into soundin opcode as well?

-m

On Mar 20, 2005, at 9:14 AM, Istvan Varga wrote:

>
> a1[, a2[, ... a16]]  diskin2  ifilcod, kpitch[, iskiptim[, iformat     
>  \
>                               [, iwsize[, iskipinit                    
>  \
>                               [, ichnmap1[, ichnmap2[, ... 
> ichnmap16]]]]]]]
>
> DESCRIPTION
> -----------
>
> Reads audio data from a file, and can alter its pitch using one of 
> several
> available interpolation types, as well as convert the sample rate to 
> match
> the orchestra sr setting. diskin2 can also read multichannel files (the
> number of channels must be power of two), and map the channels to any 
> number
> of output variables.
> diskin2 allows higher sound quality than diskin, and may have less 
> bugs,
> but there is also the disadvantage of higher CPU usage.
>
> INITIALIZATION
> --------------
>
> ifilcod - integer or character-string denoting the source soundfile
>     name. An integer denotes the file soundin.filcod ; a 
> character-string
>     (in double quotes, spaces permitted) gives the filename itself,
>     optionally a full pathname. If not a full path, the named file is
>     sought first in the current directory, then in that given by the
>     environment variable SSDIR (if defined) then by SFDIR. See also 
> GEN01.
>     The file should have 1, 2, 4, 8, or 16 channels.
>
> iskiptim (optional, defaults to zero) - time in seconds of input sound 
> to
>     be skipped, assuming kpitch=1. Can be negative, to add 
> -iskiptim/kpitch
>     seconds of delay instead of skipping sound.
>
> iformat (optional, defaults to zero) - sample format, for raw 
> (headerless)
>     files only. This parameter is ignored if the file has a header.
>     Allowed values are:
>       0: 16-bit short integers
>       1: 8-bit signed char (high-order 8 bits of a 16-bit integer)
>       2: 8-bit A-law bytes
>       3: 8-bit U-law bytes
>       4: 16-bit short integers
>       5: 32-bit long integers
>       6: 32-bit floats
>
> iwsize (optional, defaults to 1) - interpolation window size, in 
> samples.
>     Can be one of the following:
>       1: round to nearest sample (no interpolation, for kpitch=1)
>       2: linear interpolation
>       4: cubic interpolation
>> = 8: iwsize point sinc interpolation with anti-aliasing (slow)
>     Note: if interpolation is used, kpitch is automatically scaled by 
> the
>     ratio of the sample rate of the sound file and the orchestra, so 
> that
>     the file will always be played at the original pitch if kpitch is 
> 1.
>     However, the sample rate conversion is disabled if iwsize is 1.
>
> iskipinit (optional, defaults to 0) - skip initialization if set to any
>     non-zero value. This currently does not work correctly, so always 
> set
>     iskipinit to zero.
>
> ichnmap1 ... ichnmap16 (optional) - if specified, defines the mapping 
> of
>     sound file channels to output variables, and the number of ichnmap
>     parameters should be the same as the number of output channels.
>     The channel map is a list of integer values, in the range 1 to the
>     number of channels in the input file.
>     By default, file channel 1 is mapped to output channel 1, file 
> channel
>     2 to output channel 2 and so on.
>
> PERFORMANCE
> -----------
>
> a1 ... a16 - output signals, in the range -0dbfs to 0dbfs. Any samples
>     before the beginning (i.e. negative location) and after the end of
>     the file are assumed to be zero.
>
> kpitch - transpose the pitch of input sound by this factor (e.g. 0.5 
> means
>     one octave lower, 2 is one octave higher, and 1 is the original 
> pitch).
>     Fractional and negative values are allowed (the latter results in
>     playing the file backwards, however, in this case the skip time 
> parameter
>     should be set to some positive value, e.g. the length of the file,
>     otherwise nothing would be played).
>     If interpolation is enabled, and the sample rate of the file 
> differs
>     from the orchestra sample rate, the transpose ratio is 
> automatically
>     adjusted to make sure that kpitch=1 plays at the original pitch.
>     Using a high iwsize setting (40 or more) can significantly improve
>     sound quality when transposing up, although at the expense of high
>     CPU usage.
>
> EXAMPLE
> -------
>
> 
> 
> ; set this to a directory where beats.aiff can be found
> --env:SSDIR+=/Csound/Documentation/manual/examples
> 
> 
> sr      =  48000
> ksmps   =  32
> nchnls  =  2
>
>         instr 1
>
> iskptim =  0
>         if (p4 >= 0) igoto noRev
> iskptim =  2
> noRev:
> a1, a2  diskin2 "beats.aiff", p4, iskptim, 0, 32, 0, 1, 1
>         outs a1, a2
>         endin
>
> 
> 
>
> i 1 0 2 1
> i 1 3 1.3333 1.5
> i 1 5 3 -0.6667
> e
>
> 
> 
>



-------------------------------------------------------
SF email is sponsored by - The IT Product Guide
Read honest & candid reviews on hundreds of IT Products from real users.
Discover which products truly live up to the hype. Start reading now.
http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click
_______________________________________________
Csound-devel mailing list
Csound-devel@lists.sourceforge.net

matt wrote:

> looks good - thanks especially for implementing cubic interp on diskin
> ive been wanting that for a while!
> 
> but i do have some comments:
> 
> + i see no reason to have 'diskin2' -- just replace diskin!

diskin is simpler to use than diskin2, and is probably also faster by
a few times, so it does make sense to have the alternative. Also,
diskin2 does not have the "wrap" mode.

> + you are breakng the convention csound has for separate opcodes
> for interpolation types [ oscil, oscili, oscil3 ].  i would think it 
> would be
> better to stay within that.   [ i myself actually would prefer to change 
> all the
> other opcodes to only have one version with an interp parameater like you
> are doing here, but i have always got the impression from everybody else
> that opcode inflation is preferred ]

You mean something like diskin (no interpolation), diskini (linear),
diskin3 (cubic), and diskinx (sinc interpolation as in deltapx,
vdelayx etc.), as separate opcodes ? This may make sense, but would
result in a lot of code duplication (something I do not generally like).

> + no 24-bit support?

diskin2 uses libsndfile (which is the standard way of handling sound
files in Csound5), and supports all formats recognized by libsndfile.
While there is no 24 bit setting for raw sound files, the opcode should
read e.g. a 24 bit AIFF or WAV file without problems.

> + why stop at 16channels?  soundin supports something like 24

The original diskin has only 4 channels, and I thought 16 should
be enough for most uses. The number may be increased, though,
if there is a real demand.

> + channelmap doesnt seem that useful to me.   id rather just have output 
> args
>    and ignore the ones i dont want -- although i do think its useful to 
> be able
>    to have option # of outputs that are not dependent on the # of 
> channels in
>    the file.   anyway, if you or others DO think it is useful, what 
> about putting that
>    into soundin opcode as well?

I can remove the channel map (would simplify and possibly speed up the
code), but then the number of output args must match the number of
channels in the file, or an init error will occur. I do not like the
way most soundin type opcodes behave with inconsistent channel counts
(that is, e.g. reading the mono file as if it was stereo, resulting in
having the pitch off by an octave etc.), even if this can be useful
in rare cases for special effects.


-------------------------------------------------------
SF email is sponsored by - The IT Product Guide
Read honest & candid reviews on hundreds of IT Products from real users.
Discover which products truly live up to the hype. Start reading now.
http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click
_______________________________________________
Csound-devel mailing list
Csound-devel@lists.sourceforge.net

On Mar 20, 2005, at 12:02 PM, Istvan Varga wrote:

> matt wrote:
>
>> looks good - thanks especially for implementing cubic interp on diskin
>> ive been wanting that for a while!
>> but i do have some comments:
>> + i see no reason to have 'diskin2' -- just replace diskin!
>
> diskin is simpler to use than diskin2, and is probably also faster by
> a few times, so it does make sense to have the alternative. Also,
> diskin2 does not have the "wrap" mode.

still seems like not enough reason to have a separate opcode.  the 
improvements
you are making are worth any extra performance loss in my opinion.  if 
you could
add the 'wrap' mode that would be best imo!

>
>> + you are breakng the convention csound has for separate opcodes
>> for interpolation types [ oscil, oscili, oscil3 ].  i would think it 
>> would be
>> better to stay within that.   [ i myself actually would prefer to 
>> change all the
>> other opcodes to only have one version with an interp parameater like 
>> you
>> are doing here, but i have always got the impression from everybody 
>> else
>> that opcode inflation is preferred ]
>
> You mean something like diskin (no interpolation), diskini (linear),
> diskin3 (cubic), and diskinx (sinc interpolation as in deltapx,
> vdelayx etc.), as separate opcodes ? This may make sense, but would
> result in a lot of code duplication (something I do not generally 
> like).

really? couldnt you just use the same p-time code, and just make those 
opcodes'
init routine set the interpolation parameter and then call your current 
code?



>
>> + no 24-bit support?
>
> diskin2 uses libsndfile (which is the standard way of handling sound
> files in Csound5), and supports all formats recognized by libsndfile.
> While there is no 24 bit setting for raw sound files, the opcode should
> read e.g. a 24 bit AIFF or WAV file without problems.


actually now looking at the [ csound4 ] code, it looks like even the 
soundin/diskin
has some format parameters left out:

       0: 16-bit short integers
       1: 8-bit signed char (high-order 8 bits of a 16-bit integer)
       2: 8-bit A-law bytes
       3: 8-bit U-law bytes
       4: 16-bit short integers
       5: 32-bit long integers
       6: 32-bit floats

should have these 3 as well:
   7: 8-bit unsigned int
   8: 24-bit int
   9: 64-bit doubles

>
>> + why stop at 16channels?  soundin supports something like 24
>
> The original diskin has only 4 channels, and I thought 16 should
> be enough for most uses. The number may be increased, though,
> if there is a real demand.

  i think it makes sense to be identical to soundin - it is inevitable 
that
someone is going to come along and ask why they can do >16 channels
in soundin but not in diskin2!

>
>> + channelmap doesnt seem that useful to me.   id rather just have 
>> output args
>>    and ignore the ones i dont want -- although i do think its useful 
>> to be able
>>    to have option # of outputs that are not dependent on the # of 
>> channels in
>>    the file.   anyway, if you or others DO think it is useful, what 
>> about putting that
>>    into soundin opcode as well?
>
> I can remove the channel map (would simplify and possibly speed up the
> code), but then the number of output args must match the number of
> channels in the file, or an init error will occur. I do not like the
> way most soundin type opcodes behave with inconsistent channel counts

i agree - but i guess i was thinking to not have channel map input 
parameters but let
the opcode be smart enough to handle when # output parameters != file 
channels.



-------------------------------------------------------
SF email is sponsored by - The IT Product Guide
Read honest & candid reviews on hundreds of IT Products from real users.
Discover which products truly live up to the hype. Start reading now.
http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click
_______________________________________________
Csound-devel mailing list
Csound-devel@lists.sourceforge.net

Well, there is no law that demands you use all bytes in a buffer. You can have 
your 4096, but for a 6-chan file just use 4092....


Richard Dobson

Istvan Varga wrote:


> Maybe this requirement could be eliminated by dynamically
> allocating the buffers (which of course makes the code more
> complicated). The reason for requiring power of two file
> channels was that libsndfile can only read and seek the
> sound file at sample frame boundaries, and buffers of 4096
> mono samples (contained in the opcode structure) are used
> by the opcode.




-------------------------------------------------------
SF email is sponsored by - The IT Product Guide
Read honest & candid reviews on hundreds of IT Products from real users.
Discover which products truly live up to the hype. Start reading now.
http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click
_______________________________________________
Csound-devel mailing list
Csound-devel@lists.sourceforge.net

Matt Ingalls wrote:

> really? couldnt you just use the same p-time code, and just make those 
> opcodes'
> init routine set the interpolation parameter and then call your current 
> code?

If you want the opcode aliases, then it can be done, but I still think
that having a single opcode is simpler. It also allows for setting the
interpolation type with a global variable in the orchestra (e.g. linear
for quick real time "draft" use, and something very high for a final
deferred time run).

> should have these 3 as well:
>   7: 8-bit unsigned int
>   8: 24-bit int
>   9: 64-bit doubles

Again, these are only needed for raw files. Any file with a header
will be read by libsndfile and converted to MYFLT, no matter what
sample format it uses. Nevertheless, adding new format options for
raw files is easy.

>  i think it makes sense to be identical to soundin - it is inevitable that
> someone is going to come along and ask why they can do >16 channels
> in soundin but not in diskin2!

Well, then there will be 24 channels.

> i agree - but i guess i was thinking to not have channel map input 
> parameters but let
> the opcode be smart enough to handle when # output parameters != file 
> channels.

That would be anything but trivial. What is the preferred mapping of
e.g. a 7 channel file to 3 output variables (knowing nothing about
the purpose of any particular channel), or from 11 to 17 ?


-------------------------------------------------------
SF email is sponsored by - The IT Product Guide
Read honest & candid reviews on hundreds of IT Products from real users.
Discover which products truly live up to the hype. Start reading now.
http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click
_______________________________________________
Csound-devel mailing list
Csound-devel@lists.sourceforge.net

On Mar 20, 2005, at 12:56 PM, Istvan Varga wrote:

> Matt Ingalls wrote:
>
>> really? couldnt you just use the same p-time code, and just make 
>> those opcodes'
>> init routine set the interpolation parameter and then call your 
>> current code?
>
> If you want the opcode aliases, then it can be done, but I still think
> that having a single opcode is simpler. It also allows for setting the
> interpolation type with a global variable in the orchestra (e.g. linear
> for quick real time "draft" use, and something very high for a final
> deferred time run).

like i said before, i agree with you --
  but that is not how all the other table/oscil/etc opcodes are 
structured!

>
>> should have these 3 as well:
>>   7: 8-bit unsigned int
>>   8: 24-bit int
>>   9: 64-bit doubles
>
> Again, these are only needed for raw files. Any file with a header
> will be read by libsndfile and converted to MYFLT, no matter what
> sample format it uses. Nevertheless, adding new format options for
> raw files is easy.
>
>>  i think it makes sense to be identical to soundin - it is inevitable 
>> that
>> someone is going to come along and ask why they can do >16 channels
>> in soundin but not in diskin2!
>
> Well, then there will be 24 channels.
>
>> i agree - but i guess i was thinking to not have channel map input 
>> parameters but let
>> the opcode be smart enough to handle when # output parameters != file 
>> channels.
>
> That would be anything but trivial. What is the preferred mapping of
> e.g. a 7 channel file to 3 output variables (knowing nothing about
> the purpose of any particular channel), or from 11 to 17 ?

i was thinking you would have to as many outputs as the highest channel 
number you wanted,
but maybe that is too weird --



-------------------------------------------------------
SF email is sponsored by - The IT Product Guide
Read honest & candid reviews on hundreds of IT Products from real users.
Discover which products truly live up to the hype. Start reading now.
http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click
_______________________________________________
Csound-devel mailing list
Csound-devel@lists.sourceforge.net