I think the soundfont opcodes should be made optional. The
code
seems to be full of hacks. With fluidsynth, isn't that area
covered?

In any case, if we were to fix them, it's too late now for
5.01,
my packages are ready and I don't think I will have
time to rebuild them.

Victor

>
> Yes this probably is a bug on OS X!  I recently discovered
> that the sfont library opcodes were crashing on MacOS 9
> and it was because I failed to define WORDS_BIGENDIAN.
>
> Is there really no other endian reliant code in Csound
> anymore?  What about the utilities and the file formats
> that they read/write?
>
> Also, I believe that libsndfile may have a bug related to
> writing Ircam files.  I am not sure what the bug is yet,
> but it might be endian-related. (Ircam files are not
> endian-independent).  Either that or the sound file player
> that I am trying to play them with is buggy (very possible
> too).
>
> Anthony Kozar
> anthonykozar AT sbcglobal DOT net
>
>
> Istvan Varga wrote on 3/15/06 3:02 PM:
>
> > That should not really matter in most cases, with the
> > exception of the STK and possibly the Maldonado
> > SoundFont opcodes. The latter needs WORDS_BIGENDIAN to
> be defined (note that this macro is not defined anywhere
> > in SConstruct, even on OS X - a possible bug ?).
>
>
> --
> Send bugs reports to this list.
> To unsubscribe, send email to
> csound-unsubscribe@lists.bath.ac.uk

Victor,

There may be a lot of "hacks in the code," but I and my students use  
these opcodes quite a lot.

it would be great to continue supporting them and maybe improve them.

Dr. B.


On Mar 15, 2006, at 3:43 PM, Victor Lazzarini wrote:

> I think the soundfont opcodes should be made optional. The
> code
> seems to be full of hacks. With fluidsynth, isn't that area
> covered?
>
> In any case, if we were to fix them, it's too late now for
> 5.01,
> my packages are ready and I don't think I will have
> time to rebuild them.
>
> Victor
>
>>
>> Yes this probably is a bug on OS X!  I recently discovered
>> that the sfont library opcodes were crashing on MacOS 9
>> and it was because I failed to define WORDS_BIGENDIAN.
>>
>> Is there really no other endian reliant code in Csound
>> anymore?  What about the utilities and the file formats
>> that they read/write?
>>
>> Also, I believe that libsndfile may have a bug related to
>> writing Ircam files.  I am not sure what the bug is yet,
>> but it might be endian-related. (Ircam files are not
>> endian-independent).  Either that or the sound file player
>> that I am trying to play them with is buggy (very possible
>> too).
>>
>> Anthony Kozar
>> anthonykozar AT sbcglobal DOT net
>>
>>
>> Istvan Varga wrote on 3/15/06 3:02 PM:
>>
>>> That should not really matter in most cases, with the
>>> exception of the STK and possibly the Maldonado
>>> SoundFont opcodes. The latter needs WORDS_BIGENDIAN to
>> be defined (note that this macro is not defined anywhere
>>> in SConstruct, even on OS X - a possible bug ?).
>>
>>
>> --
>> Send bugs reports to this list.
>> To unsubscribe, send email to
>> csound-unsubscribe@lists.bath.ac.uk
> -- 
> Send bugs reports to this list.
> To unsubscribe, send email to csound-unsubscribe@lists.bath.ac.uk

We need to know whether they are actually working on OSX Csound 5. I have
not tried them. If there are lots of users on the Mac, it is important to make
sure they work. Too late though for 5.01.

The idea of implementing them with fluidsynth is good, since that is a well
support library.  This would go hand in hand with the idea of cleaning the
canonical csound code.

Victor

At 21:31 15/03/2006, you wrote:
>Victor,
>
>There may be a lot of "hacks in the code," but I and my students use
>these opcodes quite a lot.
>
>it would be great to continue supporting them and maybe improve them.
>
>Dr. B.
>
>
>On Mar 15, 2006, at 3:43 PM, Victor Lazzarini wrote:
>
>>I think the soundfont opcodes should be made optional. The
>>code
>>seems to be full of hacks. With fluidsynth, isn't that area
>>covered?
>>
>>In any case, if we were to fix them, it's too late now for
>>5.01,
>>my packages are ready and I don't think I will have
>>time to rebuild them.
>>
>>Victor
>>
>>>
>>>Yes this probably is a bug on OS X!  I recently discovered
>>>that the sfont library opcodes were crashing on MacOS 9
>>>and it was because I failed to define WORDS_BIGENDIAN.
>>>
>>>Is there really no other endian reliant code in Csound
>>>anymore?  What about the utilities and the file formats
>>>that they read/write?
>>>
>>>Also, I believe that libsndfile may have a bug related to
>>>writing Ircam files.  I am not sure what the bug is yet,
>>>but it might be endian-related. (Ircam files are not
>>>endian-independent).  Either that or the sound file player
>>>that I am trying to play them with is buggy (very possible
>>>too).
>>>
>>>Anthony Kozar
>>>anthonykozar AT sbcglobal DOT net
>>>
>>>
>>>Istvan Varga wrote on 3/15/06 3:02 PM:
>>>
>>>>That should not really matter in most cases, with the
>>>>exception of the STK and possibly the Maldonado
>>>>SoundFont opcodes. The latter needs WORDS_BIGENDIAN to
>>>be defined (note that this macro is not defined anywhere
>>>>in SConstruct, even on OS X - a possible bug ?).
>>>
>>>
>>>--
>>>Send bugs reports to this list.
>>>To unsubscribe, send email to
>>>csound-unsubscribe@lists.bath.ac.uk
>>--
>>Send bugs reports to this list.
>>To unsubscribe, send email to csound-unsubscribe@lists.bath.ac.uk
>
>--
>Send bugs reports to this list.
>To unsubscribe, send email to csound-unsubscribe@lists.bath.ac.uk

Victor Lazzarini
Music Technology Laboratory
Music Department
National University of Ireland, Maynooth 

It seems to me that one "standard way of using" csound is not possible with the fluidsynth opcodes, but is possible with the sf family opcodes:

When csound process an instrument's audio,
normally each instance of the instrument is treated separately.
This means one can have e.g. "monophonic distorion" effects,
if the effect is coded into the same instrument as produces the audio to be distorted.
The fluidsynth opcodes seem to only output audio from the synth instance,
and if several voices are played simultaneously, all of them are mixed before the csound user "gets access" to the audio signal.
The same is true for the VST plugins.

This functionality might be regarded as a "special case not often used",
and so not of high priority. But it is indeed a flexibility that sometimes is very useful (even if I do not use it right now).

Oeyvind



> From: Victor Lazzarini [Victor.Lazzarini@nuim.ie]
> Sent: 2006-03-16 10:20:06 CET
> To: csound@lists.bath.ac.uk
> Subject: Re: [Csnd] SoundFont Opcodes
> 
> We need to know whether they are actually working on OSX Csound 5. I have
> not tried them. If there are lots of users on the Mac, it is important to make
> sure they work. Too late though for 5.01.
> 
> The idea of implementing them with fluidsynth is good, since that is a well
> support library.  This would go hand in hand with the idea of cleaning the
> canonical csound code.
> 
> Victor
> 
> At 21:31 15/03/2006, you wrote:
> >Victor,
> >
> >There may be a lot of "hacks in the code," but I and my students use
> >these opcodes quite a lot.
> >
> >it would be great to continue supporting them and maybe improve them.
> >
> >Dr. B.
> >
> >
> >On Mar 15, 2006, at 3:43 PM, Victor Lazzarini wrote:
> >
> >>I think the soundfont opcodes should be made optional. The
> >>code
> >>seems to be full of hacks. With fluidsynth, isn't that area
> >>covered?
> >>
> >>In any case, if we were to fix them, it's too late now for
> >>5.01,
> >>my packages are ready and I don't think I will have
> >>time to rebuild them.
> >>
> >>Victor
> >>
> >>>
> >>>Yes this probably is a bug on OS X!  I recently discovered
> >>>that the sfont library opcodes were crashing on MacOS 9
> >>>and it was because I failed to define WORDS_BIGENDIAN.
> >>>
> >>>Is there really no other endian reliant code in Csound
> >>>anymore?  What about the utilities and the file formats
> >>>that they read/write?
> >>>
> >>>Also, I believe that libsndfile may have a bug related to
> >>>writing Ircam files.  I am not sure what the bug is yet,
> >>>but it might be endian-related. (Ircam files are not
> >>>endian-independent).  Either that or the sound file player
> >>>that I am trying to play them with is buggy (very possible
> >>>too).
> >>>
> >>>Anthony Kozar
> >>>anthonykozar AT sbcglobal DOT net
> >>>
> >>>
> >>>Istvan Varga wrote on 3/15/06 3:02 PM:
> >>>
> >>>>That should not really matter in most cases, with the
> >>>>exception of the STK and possibly the Maldonado
> >>>>SoundFont opcodes. The latter needs WORDS_BIGENDIAN to
> >>>be defined (note that this macro is not defined anywhere
> >>>>in SConstruct, even on OS X - a possible bug ?).
> >>>
> >>>
> >>>--
> >>>Send bugs reports to this list.
> >>>To unsubscribe, send email to
> >>>csound-unsubscribe@lists.bath.ac.uk
> >>--
> >>Send bugs reports to this list.
> >>To unsubscribe, send email to csound-unsubscribe@lists.bath.ac.uk
> >
> >--
> >Send bugs reports to this list.
> >To unsubscribe, send email to csound-unsubscribe@lists.bath.ac.uk
> 
> Victor Lazzarini
> Music Technology Laboratory
> Music Department
> National University of Ireland, Maynooth 
> 
> -- 
> Send bugs reports to this list.
> To unsubscribe, send email to csound-unsubscribe@lists.bath.ac.uk
> 

Hi Victor,

I remember that some months back there were many issues involving the 
sf family of opcodes in Csound 5 insofar as that they print endless 
strings of garbage data.

Now, the error is much more elegant but still renders these important 
opcodes *unusuable* on Csound 5 on OS X (all versions). I tested this 
with my CVS built version that is slightly newer than the previous 
release (simply because I wanted to try Anthony Kozar's barmodel 
example :D)

This is the console output

//--

Elapsed time at end of score sort: real: 0.104s, CPU: 0.020s
Csound version 5.01.0 beta (float samples) Mar 11 2006

[...]

0dBFS level = 32768.0

******************************************
**  Csound SoundFont2 support ver. 1.2  **
**          by Gabriel Maldonado        **
**        g.maldonado@agora.stm.it      **
** http://web.tiscalinet.it/G-Maldonado **
******************************************

Csound tidy up: Bus error

//--

As you can see it results in a Bus error. This behaviour is both 
reliable and consistent with several commandline options.

For this example, Csound was run with the commandline:

//--

./csound -odac:1 -idevaudio:1 -+noninterleaved=1 -+rtaudio=CoreAudio 
-b1024 -B1024 -M0 -d ${FILENAME}

//--

The following Csound code was used and works perfectly in MacCsound 
version 1.2a5.

Note that it uses the Mac OS X system SoundFont which is the exact same 
that QuickTime Player uses when playing midi files.

As such, the location of the SoundFont used need not be changed because 
this specific SoundFont is actually part of OS X.

//--




sr		= 44100
kr		= 441
ksmps	= 100
nchnls	= 2

gi2 sfload "/Library/Audio/Sounds/Banks/synthgms.sf2"

	sfilist		gi2
	sfplist		gi2
	sfpassign		0, gi2

	instr 1

ifreq	cpsmidi
iamp		ampmidi 2
inum		notnum
ivel		veloc

ipres	init	1
ipres	midic7	10, 0, 127	; set total number of presets contained in
			                     ; file as mximum value
			                     ; Controller 10 changes preset number

kamp		linsegr	1, 1, 1, .618, 0 ; adjust the release time to suit the 
sample set
kfreq	init	1
a1,a2	sfplay	ivel, inum, kamp*iamp, kfreq, int(ipres), 0

	outs	a1,a2

	endin



f0  3600





I can see that Istvan has committed the necessary changes to deal with 
endianness and I await the anonymous CVS to catch up with these 
_important_ fixes so that I may test this example further and report 
back to this list.


-David

On Mar 16, 2006, at 4:20 AM, Victor Lazzarini wrote:

> We need to know whether they are actually working on OSX Csound 5. I 
> have
> not tried them. If there are lots of users on the Mac, it is important 
> to make
> sure they work. Too late though for 5.01.
>
> The idea of implementing them with fluidsynth is good, since that is a 
> well
> support library.  This would go hand in hand with the idea of cleaning 
> the
> canonical csound code.
>
> Victor
>
> At 21:31 15/03/2006, you wrote:
>> Victor,
>>
>> There may be a lot of "hacks in the code," but I and my students use
>> these opcodes quite a lot.
>>
>> it would be great to continue supporting them and maybe improve them.
>>
>> Dr. B.

Perhaps the endianess fixes might solve the problem.

At 14:51 16/03/2006, you wrote:
>Hi Victor,
>
>I remember that some months back there were many issues involving the sf 
>family of opcodes in Csound 5 insofar as that they print endless strings 
>of garbage data.
>
>Now, the error is much more elegant but still renders these important 
>opcodes *unusuable* on Csound 5 on OS X (all versions). I tested this with 
>my CVS built version that is slightly newer than the previous release 
>(simply because I wanted to try Anthony Kozar's barmodel example :D)
>
>This is the console output
>
>//--
>
>Elapsed time at end of score sort: real: 0.104s, CPU: 0.020s
>Csound version 5.01.0 beta (float samples) Mar 11 2006
>
>[...]
>
>0dBFS level = 32768.0
>
>******************************************
>**  Csound SoundFont2 support ver. 1.2  **
>**          by Gabriel Maldonado        **
>**        g.maldonado@agora.stm.it      **
>** http://web.tiscalinet.it/G-Maldonado **
>******************************************
>
>Csound tidy up: Bus error
>
>//--
>
>As you can see it results in a Bus error. This behaviour is both reliable 
>and consistent with several commandline options.
>
>For this example, Csound was run with the commandline:
>
>//--
>
>./csound -odac:1 -idevaudio:1 -+noninterleaved=1 -+rtaudio=CoreAudio 
>-b1024 -B1024 -M0 -d ${FILENAME}
>
>//--
>
>The following Csound code was used and works perfectly in MacCsound 
>version 1.2a5.
>
>Note that it uses the Mac OS X system SoundFont which is the exact same 
>that QuickTime Player uses when playing midi files.
>
>As such, the location of the SoundFont used need not be changed because 
>this specific SoundFont is actually part of OS X.
>
>//--
>
>
>
>
>sr              = 44100
>kr              = 441
>ksmps   = 100
>nchnls  = 2
>
>gi2 sfload "/Library/Audio/Sounds/Banks/synthgms.sf2"
>
>         sfilist         gi2
>         sfplist         gi2
>         sfpassign               0, gi2
>
>         instr 1
>
>ifreq   cpsmidi
>iamp            ampmidi 2
>inum            notnum
>ivel            veloc
>
>ipres   init    1
>ipres   midic7  10, 0, 127      ; set total number of presets contained in
>                                              ; file as mximum value
>                                              ; Controller 10 changes 
> preset number
>
>kamp            linsegr 1, 1, 1, .618, 0 ; adjust the release time to suit 
>the sample set
>kfreq   init    1
>a1,a2   sfplay  ivel, inum, kamp*iamp, kfreq, int(ipres), 0
>
>         outs    a1,a2
>
>         endin
>
>
>
>f0  3600
>
>
>
>
>
>I can see that Istvan has committed the necessary changes to deal with 
>endianness and I await the anonymous CVS to catch up with these 
>_important_ fixes so that I may test this example further and report back 
>to this list.
>
>
>-David
>
>On Mar 16, 2006, at 4:20 AM, Victor Lazzarini wrote:
>
>>We need to know whether they are actually working on OSX Csound 5. I have
>>not tried them. If there are lots of users on the Mac, it is important to 
>>make
>>sure they work. Too late though for 5.01.
>>
>>The idea of implementing them with fluidsynth is good, since that is a well
>>support library.  This would go hand in hand with the idea of cleaning the
>>canonical csound code.
>>
>>Victor
>>
>>At 21:31 15/03/2006, you wrote:
>>>Victor,
>>>
>>>There may be a lot of "hacks in the code," but I and my students use
>>>these opcodes quite a lot.
>>>
>>>it would be great to continue supporting them and maybe improve them.
>>>
>>>Dr. B.
>
>--
>Send bugs reports to this list.
>To unsubscribe, send email to csound-unsubscribe@lists.bath.ac.uk

Victor Lazzarini
Music Technology Laboratory
Music Department
National University of Ireland, Maynooth 

Yes, I thought about this way of doing it too.
But never implemented it,
as I figured it would require one fluid instance per simultaneous voice of the same instrument/timbre. And I thought it just would be too much clutter.
But as you say, it would be possible.

Oeyvind



> From: Steven Yi [stevenyi@gmail.com]
> Sent: 2006-03-16 17:23:45 CET
> To: csound@lists.bath.ac.uk
> Subject: Re: [Csnd] SoundFont Opcodes
> 
> Hi Oeyvind,
> 
> This isn't quite correct; when Michael first built the Fluid opcodes,
> I myself wanted to have this capacity to apply effects per instrument.
>  You are right in saying that you output from the  synth instance, but
> I modified Michael's original design so that you can instantiate as
> many engines as you need.  This isn't the most optimal design as you
> potentially will duplicate loading instruments into memory if you want
> to have two instances and want to use different effects on each, but
> it's about as flexible a design one can do with the Fluidsynth API
> that I can see and still have that capacity for signal processing
> different instruments.
> 
> steven
> 
> 
> On 3/16/06, Oeyvind Brandtsegg  wrote:
> > It seems to me that one "standard way of using" csound is not possible with the fluidsynth opcodes, but is possible with the sf family opcodes:
> >
> > When csound process an instrument's audio,
> > normally each instance of the instrument is treated separately.
> > This means one can have e.g. "monophonic distorion" effects,
> > if the effect is coded into the same instrument as produces the audio to be distorted.
> > The fluidsynth opcodes seem to only output audio from the synth instance,
> > and if several voices are played simultaneously, all of them are mixed before the csound user "gets access" to the audio signal.
> > The same is true for the VST plugins.
> >
> > This functionality might be regarded as a "special case not often used",
> > and so not of high priority. But it is indeed a flexibility that sometimes is very useful (even if I do not use it right now).
> >
> > Oeyvind
> >
> >
> >
> > > From: Victor Lazzarini [Victor.Lazzarini@nuim.ie]
> > > Sent: 2006-03-16 10:20:06 CET
> > > To: csound@lists.bath.ac.uk
> > > Subject: Re: [Csnd] SoundFont Opcodes
> > >
> > > We need to know whether they are actually working on OSX Csound 5. I have
> > > not tried them. If there are lots of users on the Mac, it is important to make
> > > sure they work. Too late though for 5.01.
> > >
> > > The idea of implementing them with fluidsynth is good, since that is a well
> > > support library.  This would go hand in hand with the idea of cleaning the
> > > canonical csound code.
> > >
> > > Victor
> > >
> > > At 21:31 15/03/2006, you wrote:
> > > >Victor,
> > > >
> > > >There may be a lot of "hacks in the code," but I and my students use
> > > >these opcodes quite a lot.
> > > >
> > > >it would be great to continue supporting them and maybe improve them.
> > > >
> > > >Dr. B.
> > > >
> > > >
> > > >On Mar 15, 2006, at 3:43 PM, Victor Lazzarini wrote:
> > > >
> > > >>I think the soundfont opcodes should be made optional. The
> > > >>code
> > > >>seems to be full of hacks. With fluidsynth, isn't that area
> > > >>covered?
> > > >>
> > > >>In any case, if we were to fix them, it's too late now for
> > > >>5.01,
> > > >>my packages are ready and I don't think I will have
> > > >>time to rebuild them.
> > > >>
> > > >>Victor
> > > >>
> > > >>>
> > > >>>Yes this probably is a bug on OS X!  I recently discovered
> > > >>>that the sfont library opcodes were crashing on MacOS 9
> > > >>>and it was because I failed to define WORDS_BIGENDIAN.
> > > >>>
> > > >>>Is there really no other endian reliant code in Csound
> > > >>>anymore?  What about the utilities and the file formats
> > > >>>that they read/write?
> > > >>>
> > > >>>Also, I believe that libsndfile may have a bug related to
> > > >>>writing Ircam files.  I am not sure what the bug is yet,
> > > >>>but it might be endian-related. (Ircam files are not
> > > >>>endian-independent).  Either that or the sound file player
> > > >>>that I am trying to play them with is buggy (very possible
> > > >>>too).
> > > >>>
> > > >>>Anthony Kozar
> > > >>>anthonykozar AT sbcglobal DOT net
> > > >>>
> > > >>>
> > > >>>Istvan Varga wrote on 3/15/06 3:02 PM:
> > > >>>
> > > >>>>That should not really matter in most cases, with the
> > > >>>>exception of the STK and possibly the Maldonado
> > > >>>>SoundFont opcodes. The latter needs WORDS_BIGENDIAN to
> > > >>>be defined (note that this macro is not defined anywhere
> > > >>>>in SConstruct, even on OS X - a possible bug ?).
> > > >>>
> > > >>>
> > > >>>--
> > > >>>Send bugs reports to this list.
> > > >>>To unsubscribe, send email to
> > > >>>csound-unsubscribe@lists.bath.ac.uk
> > > >>--
> > > >>Send bugs reports to this list.
> > > >>To unsubscribe, send email to csound-unsubscribe@lists.bath.ac.uk
> > > >
> > > >--
> > > >Send bugs reports to this list.
> > > >To unsubscribe, send email to csound-unsubscribe@lists.bath.ac.uk
> > >
> > > Victor Lazzarini
> > > Music Technology Laboratory
> > > Music Department
> > > National University of Ireland, Maynooth
> > >
> > > --
> > > Send bugs reports to this list.
> > > To unsubscribe, send email to csound-unsubscribe@lists.bath.ac.uk
> > >
> >
> >
> --
> Send bugs reports to this list.
> To unsubscribe, send email to csound-unsubscribe@lists.bath.ac.uk
> 

I was seeing the same behavior on MacOS 9 before I corrected the endian
compilation problem.  I would fully anticipate that compiling with
WORDS_BIGENDIAN defined will make the soundfont opcodes usable on MacOS X
again.

Anthony

PS.  The soundfont opcodes WILL be working in the impending 5.01 release for
MacOS 7-9.

Victor Lazzarini wrote on 3/16/06 9:57 AM:

> Perhaps the endianess fixes might solve the problem.

>> ******************************************
>> **  Csound SoundFont2 support ver. 1.2  **
>> **          by Gabriel Maldonado        **
>> **        g.maldonado@agora.stm.it      **
>> ** http://web.tiscalinet.it/G-Maldonado **
>> ******************************************
>> 
>> Csound tidy up: Bus error