I remember that the old soundfont opcodes (i.e. sfload, sfplist, 
sfilist, sfpassign, sfpreset, sfplay, sfplaym, sfinstr, sfinstrm)
were never intended to provide a literal emulation of CreativeLabs 
synthesizers. They have been introduced only with the purpose to easily 
access to sf2 sample keymaps (not the parameters related to LFOs, 
envelopes, filters and so on), whose output (and input) can be modified 
and processed by means of all the csound power. These opcodes, if used 
together with other Csound native opcodes, allow to handle the sf2 
sample keymaps in several ways that creativelabs synthesizers simply 
cannot allow, such as, for example:

FM (and AM) with samples at audio rate,
customized and asymmetrical micro-tuning scales
modify the starting read point of a sample note per note

On the other part, the sound quality of original Live and Audigy card 
sampler surpasses that of the other software emulation, due to a 
proprietary 8-point realtime interpolation.

Summing up, i think that both fluidsynth and old sf2 opcodes can be 
useful for different categories of use.

Gabriel

Michael Gogins wrote:

> I have also committed the "fluid" plugin opcode (also runs as a VST plugin),
> based on Peter Hanappe's FluidSynth SoundFont 2 synthesizer. While Csound
> has had a degree of SoundFont support for some time, the fluid opcode
> implements all aspects of the SoundFont 2 specification and enables
> SoundFonts to be used with their key mappings and effects intact.
> 

In replying to the query on the main list, I have found a bug in 
filepeak. It hits if the instrument containing filepeak is called more 
than once. In case this hasn't been fixed elsewhere:

The code is in sndinfUG.c::filepeak():

void filepeak(SNDINFOPEAK *p)
{
     ...
     int channel = (int)(*p->channel + FL(0.5));
     ...
     if ((hdr = getsndinfo((SNDINFO *)p)) != NULL

the reason for the bug will be apparent from the definitions of SNDINFO 
and SNDINFOPEAK:

typedef struct {
   OPDS  h;
   MYFLT *r1, *ifilno;
   long audsize;
} SNDINFO;

typedef struct {
   OPDS  h;
   MYFLT *r1, *ifilno, *channel;
   long audsize;
} SNDINFOPEAK;


i.e. SNDINFOPEAK is not in fact "derived from" SNDINFO.

the fix is therefore to clone a proper SNDINFO:

add:  SNDINFO info;
	info.h = p->h;
	info.r1 = p->r1;
	info.ifilno = p->ifilno;
	info.audsize = p->audsize;
then write:
     if ((hdr = getsndinfo(&info  )) != NULL
	...




Richard Dobson

OK; now in sources

Thanks Richard and John!


On Thu, 2003-10-23 at 06:37, John ffitch wrote:
> OK; now in sources
> 
> 

in addition, filepeak should return its value relative to 0dbfs - been on
my todo list for years now, was hoping you would get to it before
me, richard :)

-m




On Thu, 23 Oct 2003, Richard Dobson wrote:

> In replying to the query on the main list, I have found a bug in
> filepeak. It hits if the instrument containing filepeak is called more
> than once. In case this hasn't been fixed elsewhere:
>
> The code is in sndinfUG.c::filepeak():
>
> void filepeak(SNDINFOPEAK *p)
> {
>      ...
>      int channel = (int)(*p->channel + FL(0.5));
>      ...
>      if ((hdr = getsndinfo((SNDINFO *)p)) != NULL
>
> the reason for the bug will be apparent from the definitions of SNDINFO
> and SNDINFOPEAK:
>
> typedef struct {
>    OPDS  h;
>    MYFLT *r1, *ifilno;
>    long audsize;
> } SNDINFO;
>
> typedef struct {
>    OPDS  h;
>    MYFLT *r1, *ifilno, *channel;
>    long audsize;
> } SNDINFOPEAK;
>
>
> i.e. SNDINFOPEAK is not in fact "derived from" SNDINFO.
>
> the fix is therefore to clone a proper SNDINFO:
>
> add:  SNDINFO info;
> 	info.h = p->h;
> 	info.r1 = p->r1;
> 	info.ifilno = p->ifilno;
> 	info.audsize = p->audsize;
> then write:
>      if ((hdr = getsndinfo(&info  )) != NULL
> 	...
>
>
>
>
> Richard Dobson
>
>
>
>

I think that depends on how one wants to use it. The "raw" PEAK value is 
already relative to 1.0, so can be used directly as a factor in custom 
normalization, etc; and it may often be useful to get what is actually 
in the PEAK chunk, not only a value modifed by the orch 0dbfs.  So I 
suggest this should be a new optional arg to filepeak.

In any case, it is very easy to make it relative to orch 0dbfs:

ipeak filepeak "floatsnd.wav"
irelpeak = ipeak * 0dbfs

etc etc etc...


We can't just change the output value as that can be sure to break an 
important orch somewhere. Unless of course we can be sure nobody 
actually uses that opcode!


Richard Dobson



Matt J. Ingalls wrote:

> in addition, filepeak should return its value relative to 0dbfs - been on
> my todo list for years now, was hoping you would get to it before
> me, richard :)
> 
> -m
> 
> 
> 
> 

well you want the output of filepeak to be in the same units as the output
of soundin, right?





On Thu, 23 Oct 2003, Richard Dobson wrote:

> I think that depends on how one wants to use it. The "raw" PEAK value is
> already relative to 1.0, so can be used directly as a factor in custom
> normalization, etc; and it may often be useful to get what is actually
> in the PEAK chunk, not only a value modifed by the orch 0dbfs.  So I
> suggest this should be a new optional arg to filepeak.
>
> In any case, it is very easy to make it relative to orch 0dbfs:
>
> ipeak filepeak "floatsnd.wav"
> irelpeak = ipeak * 0dbfs
>
> etc etc etc...
>
>
> We can't just change the output value as that can be sure to break an
> important orch somewhere. Unless of course we can be sure nobody
> actually uses that opcode!
>
>
> Richard Dobson
>
>
>
> Matt J. Ingalls wrote:
>
> > in addition, filepeak should return its value relative to 0dbfs - been on
> > my todo list for years now, was hoping you would get to it before
> > me, richard :)
> >
> > -m
> >
> >
> >
> >
>
>
>