Hi List--

I figured today this would be good to post to the devel list instead of 
the regular list because it deals with the "engineering" side of things 
rather than the musical side. (An important distinction one developer 
points out recently!!)

I have this UDO I'm working with as an interface to a pedal board that 
outputs program change messages, here's a diagram:

-----------------------------
|  0  |  1  |  2  |  3  |  4  |
|  5  |  6  |  7  |  8  |  9  |
----------------------------

opcode	footarray, kk, o

gi1	xin

kstatus, kchan, kd1, kd2	midiin

if	(kstatus == 192 && kd1 == 01) then
knum	=	kd1
kval	=	(kd2 + 1)
elseif	(kstatus == 192 && kd1 == 02) then
knum	=	kd1
kval	=	(kd2 + 1)
elseif	(kstatus == 192 && kd1 == 03) then
knum	=	kd1
kval	=	(kd2 + 1)
elseif	(kstatus == 192 && kd1 == 04) then
knum	=	kd1
kval	=	(kd2 + 1)
elseif	(kstatus == 192 && kd1 == 05) then
knum	=	kd1
kval	=	(kd2 + 1)
elseif	(kstatus == 192 && kd1 == 06) then
knum	=	kd1
kval	=	(kd2 + 1)
elseif	(kstatus == 192 && kd1 == 07) then
knum	=	kd1
kval	=	(kd2 + 1)
elseif	(kstatus == 192 && kd1 == 08) then
knum	=	kd1
kval	=	(kd2 + 1)
elseif	(kstatus == 192 && kd1 == 09) then
knum	=	kd1
kval	=	(kd2 + 1)
else
	endif

	xout	knum, kval

	endop

The idea is that it senses MIDI program change messages and passes 
information based on the information contained in Data Byte 1 of the 
MIDI messages.

The problem is that it doesn't seem to output anything at the Data Byte 
2 when receiving program change messages!!?

How can it be implemented so that the control outputs a boolean true/ 
false (0 or 1) kind of thing when the message is sent and then 
immediately outputs a 0 (much like a note on / note off kind of thing)?

Here is the UDO example in context, in unified CSD format; however 
again since the official release is Csound 4.x, it remains consistent 
with that API (although it was tested and works with Csound5.)





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

gifn1	ftgen	1, 0, 16384, 10, 1

/*--- ---*/

	opcode	footarray, kk, o

gi1	xin

kstatus, kchan, kd1, kd2	midiin

if	(kstatus == 192 && kd1 == 01) then
knum	=	kd1
kval	=	(kd2 + 1)
elseif	(kstatus == 192 && kd1 == 02) then
knum	=	kd1
kval	=	(kd2 + 1)
elseif	(kstatus == 192 && kd1 == 03) then
knum	=	kd1
kval	=	(kd2 + 1)
elseif	(kstatus == 192 && kd1 == 04) then
knum	=	kd1
kval	=	(kd2 + 1)
elseif	(kstatus == 192 && kd1 == 05) then
knum	=	kd1
kval	=	(kd2 + 1)
elseif	(kstatus == 192 && kd1 == 06) then
knum	=	kd1
kval	=	(kd2 + 1)
elseif	(kstatus == 192 && kd1 == 07) then
knum	=	kd1
kval	=	(kd2 + 1)
elseif	(kstatus == 192 && kd1 == 08) then
knum	=	kd1
kval	=	(kd2 + 1)
elseif	(kstatus == 192 && kd1 == 09) then
knum	=	kd1
kval	=	(kd2 + 1)
else
	endif

	xout	knum, kval

	endop

/*--- ---*/

		instr	1	;  printing test

knum, kval	footarray

;	printks	"Prog Ch #: %d, Prog Ch Val: %d\\n\\n", 0.1, knum, kval
	printk2	knum
	printk2	kval

		endin

/*--- ---*/

		instr	2	;  musical example

gifn1	ftgen	1, 0, 16384, 10, 1
kenv	init	220

knum, kval	footarray

if	(knum == 1) then
koff	line	1, 1, 0.000001
koff	=	koff * 10000
else
	endif

if	(knum == 2) then
kenv	line	420, 2, 880
elseif	(knum == 3) then
kenv	line	880, 2, 420
else
kenv	=	220
	endif

aout	oscil	koff, kenv, 1

	outs	aout, aout

		endin

/*--- ---*/

		instr	3	;  better musical example

knum, kval	footarray

if	(knum == 2) then
	event	"i", 4, 0, 0.5
else
	goto	contin
	endif

contin:
		endin

/*--- ---*/

		instr	4

a1	oscil	10000, 220, 1

	outs	a1, a1

		endin

/*--- ---*/

instr 5
   ; Create a trigger and set its initial value to 1.
   ktrigger init 1

   ; If the trigger is equal to 0, continue playing.
   ; If not, schedule another event.
   if (ktrigger == 0) goto contin
     ; kscoreop="i", an i-statement.
     ; kinsnum=2, play Instrument #2.
     ; kwhen=1, start at 1 second.
     ; kdur=0.5, play for a half-second.
     event "i", 4, 1, 0.5

     ; Make sure the event isn't triggered again.
     ktrigger = 0

contin:
   a1 oscils 10000, 440, 1
   outs a1, a1
endin


;i1	0	1000
;i2	0	1000
i3	0	1000
/* event.sco */
; Make sure the score plays for two seconds.
f 0 1000

; Play Instrument #1 for a half-second.
;i 5 0 0.5

e





-David

Not entirely sure I get you here David. But a couple of points:

- kd2 will be zero on a program change message, but nothing is stopping 
you from changing it inside your conditional block
- if you put your midi opcode in a midi parser instrument, you can 
always spawn subsequent messages with an event call ( for the immediate 
boolean message later )
- a midi in call lasts for only one kpass, so you could also set a krate 
value that gets cleared on the subsequent kpass of the parser instrument
- on any kpass that gets NO midi message, kstatus is 0 I believe, so you 
could conditionalize on that as well to revert your flag to 0 on the 
next kpass that does not have some other value in data2
- you can tighten the code up by doing:

if ( ( kstatus == 192 ) && ( kd1 >= 01 ) && ( kd1 <= 09 ) )
    knum = kd1
    kval = 1
endif

However I'm not sure I understand exactly what you want the behaviour to 
be ...

Iain
	

if ( kstatus =
> opcode footarray, kk, o
> 
> gi1 xin
> 
> kstatus, kchan, kd1, kd2 midiin
> 
> if (kstatus == 192 && kd1 == 01) then
> knum = kd1
> kval = (kd2 + 1)
> elseif (kstatus == 192 && kd1 == 02) then
> knum = kd1
> kval = (kd2 + 1)
> elseif (kstatus == 192 && kd1 == 03) then
> knum = kd1
> kval = (kd2 + 1)
> elseif (kstatus == 192 && kd1 == 04) then
> knum = kd1
> kval = (kd2 + 1)
> elseif (kstatus == 192 && kd1 == 05) then
> knum = kd1
> kval = (kd2 + 1)
> elseif (kstatus == 192 && kd1 == 06) then
> knum = kd1
> kval = (kd2 + 1)
> elseif (kstatus == 192 && kd1 == 07) then
> knum = kd1
> kval = (kd2 + 1)
> elseif (kstatus == 192 && kd1 == 08) then
> knum = kd1
> kval = (kd2 + 1)
> elseif (kstatus == 192 && kd1 == 09) then
> knum = kd1
> kval = (kd2 + 1)
> else
> endif
> 
> xout knum, kval
> 
> endop
> 
> The idea is that it senses MIDI program change messages and passes 
> information based on the information contained in Data Byte 1 of the 
> MIDI messages.
> 
> The problem is that it doesn't seem to output anything at the Data Byte 
> 2 when receiving program change messages!!?
> 
> How can it be implemented so that the control outputs a boolean true/ 
> false (0 or 1) kind of thing when the message is sent and then 
> immediately outputs a 0 (much like a note on / note off kind of thing)?
> 
> Here is the UDO example in context, in unified CSD format; however again 
> since the official release is Csound 4.x, it remains consistent with 
> that API (although it was tested and works with Csound5.)
> 
> 
> 
> 
> 
> sr = 44100
> kr = 441
> ksmps = 100
> nchnls = 2
> 
> gifn1 ftgen 1, 0, 16384, 10, 1
> 
> /*--- ---*/
> 
> opcode footarray, kk, o
> 
> gi1 xin
> 
> kstatus, kchan, kd1, kd2 midiin
> 
> if (kstatus == 192 && kd1 == 01) then
> knum = kd1
> kval = (kd2 + 1)
> elseif (kstatus == 192 && kd1 == 02) then
> knum = kd1
> kval = (kd2 + 1)
> elseif (kstatus == 192 && kd1 == 03) then
> knum = kd1
> kval = (kd2 + 1)
> elseif (kstatus == 192 && kd1 == 04) then
> knum = kd1
> kval = (kd2 + 1)
> elseif (kstatus == 192 && kd1 == 05) then
> knum = kd1
> kval = (kd2 + 1)
> elseif (kstatus == 192 && kd1 == 06) then
> knum = kd1
> kval = (kd2 + 1)
> elseif (kstatus == 192 && kd1 == 07) then
> knum = kd1
> kval = (kd2 + 1)
> elseif (kstatus == 192 && kd1 == 08) then
> knum = kd1
> kval = (kd2 + 1)
> elseif (kstatus == 192 && kd1 == 09) then
> knum = kd1
> kval = (kd2 + 1)
> else
> endif
> 
> xout knum, kval
> 
> endop
> 
> /*--- ---*/
> 
> instr 1 ; printing test
> 
> knum, kval footarray
> 
> ; printks "Prog Ch #: %d, Prog Ch Val: %d\\n\\n", 0.1, knum, kval
> printk2 knum
> printk2 kval
> 
> endin
> 
> /*--- ---*/
> 
> instr 2 ; musical example
> 
> gifn1 ftgen 1, 0, 16384, 10, 1
> kenv init 220
> 
> knum, kval footarray
> 
> if (knum == 1) then
> koff line 1, 1, 0.000001
> koff = koff * 10000
> else
> endif
> 
> if (knum == 2) then
> kenv line 420, 2, 880
> elseif (knum == 3) then
> kenv line 880, 2, 420
> else
> kenv = 220
> endif
> 
> aout oscil koff, kenv, 1
> 
> outs aout, aout
> 
> endin
> 
> /*--- ---*/
> 
> instr 3 ; better musical example
> 
> knum, kval footarray
> 
> if (knum == 2) then
> event "i", 4, 0, 0.5
> else
> goto contin
> endif
> 
> contin:
> endin
> 
> /*--- ---*/
> 
> instr 4
> 
> a1 oscil 10000, 220, 1
> 
> outs a1, a1
> 
> endin
> 
> /*--- ---*/
> 
> instr 5
> ; Create a trigger and set its initial value to 1.
> ktrigger init 1
> 
> ; If the trigger is equal to 0, continue playing.
> ; If not, schedule another event.
> if (ktrigger == 0) goto contin
> ; kscoreop="i", an i-statement.
> ; kinsnum=2, play Instrument #2.
> ; kwhen=1, start at 1 second.
> ; kdur=0.5, play for a half-second.
> event "i", 4, 1, 0.5
> 
> ; Make sure the event isn't triggered again.
> ktrigger = 0
> 
> contin:
> a1 oscils 10000, 440, 1
> outs a1, a1
> endin
> 
> 
> ;i1 0 1000
> ;i2 0 1000
> i3 0 1000
> /* event.sco */
> ; Make sure the score plays for two seconds.
> f 0 1000
> 
> ; Play Instrument #1 for a half-second.
> ;i 5 0 0.5
> 
> e
> 
> 
> 
> 
> 
> -David


-------------------------------------------------------
This SF.Net email is sponsored by:
Power Architecture Resource Center: Free content, downloads, discussions,
and more. http://solutions.newsforge.com/ibmarch.tmpl
_______________________________________________
Csound-devel mailing list
Csound-devel@lists.sourceforge.net

Hi Iain--

On Oct 20, 2005, at 4:57 PM, Iain Duncan wrote:

> Not entirely sure I get you here David. But a couple of points:
>
> - kd2 will be zero on a program change message, but nothing is 
> stopping you from changing it inside your conditional block

I understand this now but I was previously unaware! Read on to find out 
more

> - if you put your midi opcode in a midi parser instrument, you can 
> always spawn subsequent messages with an event call ( for the 
> immediate boolean message later )

> - a midi in call lasts for only one kpass, so you could also set a 
> krate value that gets cleared on the subsequent kpass of the parser 
> instrument

> - on any kpass that gets NO midi message, kstatus is 0 I believe, so 
> you could conditionalize on that as well to revert your flag to 0 on 
> the next kpass that does not have some other value in data2

Thanks for these tips!

> if ( ( kstatus == 192 ) && ( kd1 >= 01 ) && ( kd1 <= 09 ) )
>    knum = kd1
>    kval = 1
> endif

This is a very interesing use of &&.

> However I'm not sure I understand exactly what you want the behaviour 
> to be ...

Actually I figured it out. I wanted it to output a boolean true if a 
program change was sent. The thing was I had been expecting the 1 to 
appear at Data Byte 2 which it was not. Using the following DEBUG 
instrument:

instr	1

kstatus, kchan, kd1, kd2	midiin

	printk2	kstatus
;	printk2	kchan
	printk2	kd1
	printk2	kd2

		endin

I noticed the output when sending Prog Change 1 is:

  i1   176.00000	<--  Continuous Control Status byte
  i1    32.00000	<--  CC, bank select 32, data byte 1
  i1   192.00000	<--  Prog change Status byte
  i1     1.00000	<--  Prog change number, data byte 1
  i1     0.00000	<--  midiin buffer not pending any messages

So based on this information I implement the original idea in the 
following UDO (which of course is on the repository)

opcode  footarray, kk, o

gi1     xin

kstatus, kchan, kd1, kd2        midiin

kval  =  0

if      (kstatus == 176 && kd1 == 32) then
kval    =       0
elseif  (kstatus == 192) then
knum    =       kd1
kval    =       1
         endif

         xout    knum, kval

         endop

Of course given the level of experience and knowledge readers of this 
list collectively share, I always welcome suggestions for improvements 
or efficiencies with the code as previous suggestions have always been 
most helpful.

Here's a musical example demonstrating the above UDO

/*--- ---*/

                 instr   1

knum, kval      footarray

if      (knum == 1 && kval == 1) kgoto one
if      (knum == 2 && kval == 1) kgoto two
if      (knum == 3 && kval == 1) kgoto three
         kgoto   contin

one:
         event   "i", 2, 0, 2, 8.02, 0.25
kgoto   contin

two:
         event   "i", 2, 0, 2, 8.07, 0.75
kgoto contin

three:
         event   "i", 2, 0, 2, 8.00, 1.00
kgoto contin

contin:
knum    =       0
                 endin

/*--- ---*/

                 instr   2

kpan    =       p5
a1      oscil   10000, cpspch(p4), 1

kenv    linseg  0.000001, 0.05, 1, p3, 1, 0.05, 0.000001

aout    =       a1 * kenv

         outs    aout * (1 - kpan), aout * kpan

                 endin

/*--- ---*/


-David

I would suggest some heavy testing of that, one thing you might have to 
be careful of is what happens if midi in gets used in other places too 
on the same kpass and are needed for other instruments? ( I dunno, do 
they both get the message? )

Iain

David Akbari wrote:
> Hi Iain--
> 
> On Oct 20, 2005, at 4:57 PM, Iain Duncan wrote:
> 
>     Not entirely sure I get you here David. But a couple of points:
> 
>     - kd2 will be zero on a program change message, but nothing is
>     stopping you from changing it inside your conditional block
> 
> 
> I understand this now but I was previously unaware! Read on to find out 
> more
> 
>     - if you put your midi opcode in a midi parser instrument, you can
>     always spawn subsequent messages with an event call ( for the
>     immediate boolean message later )
> 
> 
>     - a midi in call lasts for only one kpass, so you could also set a
>     krate value that gets cleared on the subsequent kpass of the parser
>     instrument
> 
> 
>     - on any kpass that gets NO midi message, kstatus is 0 I believe, so
>     you could conditionalize on that as well to revert your flag to 0 on
>     the next kpass that does not have some other value in data2
> 
> 
> Thanks for these tips!
> 
>     if ( ( kstatus == 192 ) && ( kd1 >= 01 ) && ( kd1 <= 09 ) )
>     knum = kd1
>     kval = 1
>     endif
> 
> 
> This is a very interesing use of &&.
> 
>     However I'm not sure I understand exactly what you want the
>     behaviour to be ...
> 
> 
> Actually I figured it out. I wanted it to output a boolean true if a 
> program change was sent. The thing was I had been expecting the 1 to 
> appear at Data Byte 2 which it was not. Using the following DEBUG 
> instrument:
> 
> instr 1
> 
> kstatus, kchan, kd1, kd2 midiin
> 
> printk2 kstatus
> ; printk2 kchan
> printk2 kd1
> printk2 kd2
> 
> endin
> 
> I noticed the output when sending Prog Change 1 is:
> 
> i1 176.00000 <-- Continuous Control Status byte
> i1 32.00000 <-- CC, bank select 32, data byte 1
> i1 192.00000 <-- Prog change Status byte
> i1 1.00000 <-- Prog change number, data byte 1
> i1 0.00000 <-- midiin buffer not pending any messages
> 
> So based on this information I implement the original idea in the 
> following UDO (which of course is on the repository)
> 
> opcode footarray, kk, o
> 
> gi1 xin
> 
> kstatus, kchan, kd1, kd2 midiin
> 
> kval = 0
> 
> if (kstatus == 176 && kd1 == 32) then
> kval = 0
> elseif (kstatus == 192) then
> knum = kd1
> kval = 1
> endif
> 
> xout knum, kval
> 
> endop
> 
> Of course given the level of experience and knowledge readers of this 
> list collectively share, I always welcome suggestions for improvements 
> or efficiencies with the code as previous suggestions have always been 
> most helpful.
> 
> Here's a musical example demonstrating the above UDO
> 
> /*--- ---*/
> 
> instr 1
> 
> knum, kval footarray
> 
> if (knum == 1 && kval == 1) kgoto one
> if (knum == 2 && kval == 1) kgoto two
> if (knum == 3 && kval == 1) kgoto three
> kgoto contin
> 
> one:
> event "i", 2, 0, 2, 8.02, 0.25
> kgoto contin
> 
> two:
> event "i", 2, 0, 2, 8.07, 0.75
> kgoto contin
> 
> three:
> event "i", 2, 0, 2, 8.00, 1.00
> kgoto contin
> 
> contin:
> knum = 0
> endin
> 
> /*--- ---*/
> 
> instr 2
> 
> kpan = p5
> a1 oscil 10000, cpspch(p4), 1
> 
> kenv linseg 0.000001, 0.05, 1, p3, 1, 0.05, 0.000001
> 
> aout = a1 * kenv
> 
> outs aout * (1 - kpan), aout * kpan
> 
> endin
> 
> /*--- ---*/
> 
> 
> -David


-------------------------------------------------------
This SF.Net email is sponsored by:
Power Architecture Resource Center: Free content, downloads, discussions,
and more. http://solutions.newsforge.com/ibmarch.tmpl
_______________________________________________
Csound-devel mailing list
Csound-devel@lists.sourceforge.net

David Akbari wrote:

> So based on this information I implement the original idea in the 
> following UDO (which of course is on the repository)
> 
> opcode footarray, kk, o
> 
> gi1 xin
> 
> kstatus, kchan, kd1, kd2 midiin
> 
> kval = 0
> 
> if (kstatus == 176 && kd1 == 32) then
> kval = 0
> elseif (kstatus == 192) then
> knum = kd1
> kval = 1
> endif
> 
> xout knum, kval
> 
> endop

Here is a simplified version of the UDO. By the way, why
is the 'gi1 xin' needed ? Does using 0 for input types not
work in some versions of Csound ?

opcode footarray, kk, 0

kstatus, kchan, kd1, kd2 midiin

if (kstatus == 192) then
knum = kd1
kval = 1
else
knum = 0
kval = 0
endif

xout knum, kval

endop



-------------------------------------------------------
This SF.Net email is sponsored by:
Power Architecture Resource Center: Free content, downloads, discussions,
and more. http://solutions.newsforge.com/ibmarch.tmpl
_______________________________________________
Csound-devel mailing list
Csound-devel@lists.sourceforge.net

On Oct 21, 2005, at 9:08 AM, Istvan Varga wrote:

> By the way, why
> is the 'gi1 xin' needed ? Does using 0 for input types not
> work in some versions of Csound ?

In MacCsound, the compiler complains if there is no xin opcode inside 
of the UDO definition. So while using 0 explicitly is not illegal, the 
absence of xin seems like it is.

It seems the problem has been fixed in Csound5.

Speaking of this, is the following instr 0 statement legal?

#include	"udo1.udo"
#include	"udo2.udo"

Because if I put that in the Csound5 orc, it gives an error while if I 
do

#include	"udo1.udo"

#include	"udo2.udo"

performance proceeds as expected. Is this the expected behaviour?


-David



-------------------------------------------------------
This SF.Net email is sponsored by:
Power Architecture Resource Center: Free content, downloads, discussions,
and more. http://solutions.newsforge.com/ibmarch.tmpl
_______________________________________________
Csound-devel mailing list
Csound-devel@lists.sourceforge.net

On Oct 21, 2005, at 3:40 PM, Steven Yi wrote:

> Hmm... just from the email, I'd guess a last line return from the
> first #include is chopped off and then the first line of udo2.udo is
> attached to the end of the contents of udo1.udo--if udo1.udo ends with
> an endop line and udo2.udo starts with a opcode line.
>
> What error message do you get?
>

Csound version 5.00.0 beta (double samples) Oct 21 2005
libsndfile-1.0.11
UnifiedCSD:  /Users/daveakbari/Desktop/NIHON_footarray.csd
STARTING FILE
Creating orchestra
Creating score
orchname:  /var/tmp/tmp.orc
scorename: /var/tmp/tmp.sco
rtaudio: CoreAudio module enabled
rtmidi: PortMIDI module enabled
**** OSC: liblo started ****
orch compiler:
Macro definition for MIDI2CPS
Macro definition for FILE1
Macro definition for FILE2
Macro definition for FILE3
Macro definition for FILE4
Macro definition for FILE5
Macro definition for FILE6
Macro definition for FILE7
Macro definition for FILE8
899 lines read
         opcode  rbatonXYZ       kkkkkk  o
         opcode  rbatonPot       kkkkkkk o
         opcode  rbatonPercPad   kkkkkk  o
         opcode  p5glove kkkkkkkkkkk     0
         opcode  lowpass k       kk
         opcode  LogCurve        k       kk
         opcode  hysteresis      kkk     kkk
         opcode  gainslider      k       k
         opcode  flip    k       kk
         opcode  ExpCurve        k       kk
         opcode  Deflutter       k       k
         opcode  cpsmid  k       k
         opcode  footarray       kk      0
error:  no legal opcode, line 613:
                 endop#include   "ampSlider.udo"
error:  instr not allowed in opcode block, line 626:
                 instr   1
         instr   1
error:  endin not allowed in opcode blk, line 712:
                 endin
error:  instr not allowed in opcode block, line 716:
                 instr   2
         instr   2
error:  endin not allowed in opcode blk, line 727:
                 endin
error:  instr not allowed in opcode block, line 731:
                 instr   3
         instr   3
error:  endin not allowed in opcode blk, line 742:
                 endin
error:  instr not allowed in opcode block, line 746:
                 instr   4
         instr   4
error:  endin not allowed in opcode blk, line 757:
                 endin
error:  instr not allowed in opcode block, line 761:
                 instr   5
         instr   5
error:  endin not allowed in opcode blk, line 772:
                 endin
error:  instr not allowed in opcode block, line 776:
                 instr   6
         instr   6
error:  endin not allowed in opcode blk, line 787:
                 endin
error:  instr not allowed in opcode block, line 791:
                 instr   7
         instr   7
error:  endin not allowed in opcode blk, line 802:
                 endin
error:  instr not allowed in opcode block, line 806:
                 instr   8
         instr   8
error:  endin not allowed in opcode blk, line 817:
                 endin
error:  instr not allowed in opcode block, line 821:
                 instr   9
         instr   9
error:  endin not allowed in opcode blk, line 832:
                 endin
error:  instr not allowed in opcode block, line 836:
                 instr   10
         instr   10
error:  endin not allowed in opcode blk, line 897:
                 endin


-David



-------------------------------------------------------
This SF.Net email is sponsored by:
Power Architecture Resource Center: Free content, downloads, discussions,
and more. http://solutions.newsforge.com/ibmarch.tmpl
_______________________________________________
Csound-devel mailing list
Csound-devel@lists.sourceforge.net

First check that there is actually a newline at the end of "udo1.udo"
but this sounds like a bug long since announced as fixed.  At one time
#include'd files were not terminated correctly.  has this resurfaced
or was it not fixed?
==John ffitch


-------------------------------------------------------
This SF.Net email is sponsored by:
Power Architecture Resource Center: Free content, downloads, discussions,
and more. http://solutions.newsforge.com/ibmarch.tmpl
_______________________________________________
Csound-devel mailing list
Csound-devel@lists.sourceforge.net

Steven Yi wrote:

> Been in a self management mode today and organizing things and saw
> this email.  Is this bug with #includes and no newlines at end of file
> still causing a bug?

I did some tests, and it seems that problems occur only if the included
file does not have a newline at the end at all, rather than requiring an
extra blank line. So, I am not sure if this is really a bug, as files
should be correctly terminated.


-------------------------------------------------------
This SF.Net email is sponsored by the JBoss Inc.
Get Certified Today * Register for a JBoss Training Course
Free Certification Exam for All Training Attendees Through End of 2005
Visit http://www.jboss.com/services/certification for more information
_______________________________________________
Csound-devel mailing list
Csound-devel@lists.sourceforge.net

Not having a newline at the end of a file is not "incorrectly terminated."

:)

This should be considered a bug.  Any possibility of using this as a
"feature" are far outweighed by the inscrutability of the error it causes,
in my opinion.

Anthony Kozar
anthonykozar AT sbcglobal DOT net
http://akozar.spymac.net/


Istvan Varga wrote on 10/31/05 4:37 AM:

> I did some tests, and it seems that problems occur only if the included
> file does not have a newline at the end at all, rather than requiring an
> extra blank line. So, I am not sure if this is really a bug, as files
> should be correctly terminated.



-------------------------------------------------------
SF.Net email is sponsored by:
Tame your development challenges with Apache's Geronimo App Server. Download
it for free - -and be entered to win a 42" plasma tv or your very own
Sony(tm)PSP.  Click here to play: http://sourceforge.net/geronimo.php
_______________________________________________
Csound-devel mailing list
Csound-devel@lists.sourceforge.net

Disagree.  It is not a bug but exactly as I would expect.

The semantics is that the line
#include "foo"
is replaced by the contents of the file foo. If that file were the
characters "abc" then that is what is inserted.  If it is "abc\n" then
four characters are inserted.

Garbage in, garbage out.

==John ffitch


-------------------------------------------------------
SF.Net email is sponsored by:
Tame your development challenges with Apache's Geronimo App Server. Download
it for free - -and be entered to win a 42" plasma tv or your very own
Sony(tm)PSP.  Click here to play: http://sourceforge.net/geronimo.php
_______________________________________________
Csound-devel mailing list
Csound-devel@lists.sourceforge.net

But #include "foo" is followed by \n.

And following your logic,

#include "foo"
#include "bar"

would be replaced by the contents of foo with the contents of bar on the
next line, since #include "bar" occurs on the next line.

:)

jpff@codemist.co.uk wrote on 11/2/05 1:53 AM:

> Disagree.  It is not a bug but exactly as I would expect.
> 
> The semantics is that the line
> #include "foo"
> is replaced by the contents of the file foo. If that file were the
> characters "abc" then that is what is inserted.  If it is "abc\n" then
> four characters are inserted.



-------------------------------------------------------
SF.Net email is sponsored by:
Tame your development challenges with Apache's Geronimo App Server. Download
it for free - -and be entered to win a 42" plasma tv or your very own
Sony(tm)PSP.  Click here to play: http://sourceforge.net/geronimo.php
_______________________________________________
Csound-devel mailing list
Csound-devel@lists.sourceforge.net

No you did not read what I said

> the line
> #include "foo"
> is replaced by the contents of the file foo.
Not the line minus the last character

==John ffitch


-------------------------------------------------------
SF.Net email is sponsored by:
Tame your development challenges with Apache's Geronimo App Server. Download
it for free - -and be entered to win a 42" plasma tv or your very own
Sony(tm)PSP.  Click here to play: http://sourceforge.net/geronimo.php
_______________________________________________
Csound-devel mailing list
Csound-devel@lists.sourceforge.net

On Oct 31, 2005, at 10:03 AM, Steven Yi wrote:

> I've modified the UDO repository to now add a newline at the end of
> the generated files, so I think at least that will be correct now.

IMHO, this was the biggest issue presented as a result of this feature 
of the language.

Since the UDO database has since been corrected, I don't see any issue 
with keeping the current behavior, so long as we all remember to append 
a newline to the end of our header files!

Of course it is always no problem to remember these behaviour for our 
own personal use, but perhaps this feature is worthy of mentioning in 
the canonical reference manual? At present the currently cited 
contextual example is incorrect. Found here:

http://www.csounds.com/manual/html/include.html

An excerpt...

"An extreme form would be to have each instrument defines as a macro, 
with the instrument number as a parameter. Then an entire orchestra 
could be constructed from a number of #include statements followed by 
macro calls.

   #include “clarinet”
   #include “flute”
   #include “bassoon”
   $CLARINET(1)
   $FLUTE(2)
   $BASSOON(3)"

This example would of course result in a preliminary exit from the 
csoundPerformKsmps() loop and subsequent fatal error message even 
though syntactically there is nothing wrong (assuming the current 
instance of Csound is able to locate all #include'ed files from 
INCDIR.)


-David


-------------------------------------------------------
SF.Net email is sponsored by:
Tame your development challenges with Apache's Geronimo App Server. Download
it for free - -and be entered to win a 42" plasma tv or your very own
Sony(tm)PSP.  Click here to play: http://sourceforge.net/geronimo.php
_______________________________________________
Csound-devel mailing list
Csound-devel@lists.sourceforge.net

David Akbari wrote:

>   #include “clarinet”
>   #include “flute”
>   #include “bassoon”
>   $CLARINET(1)
>   $FLUTE(2)
>   $BASSOON(3)"
> 
> This example would of course result in a preliminary exit from the 
> csoundPerformKsmps() loop and subsequent fatal error message even though 
> syntactically there is nothing wrong (assuming the current instance of 
> Csound is able to locate all #include'ed files from INCDIR.)

As far as I have tested it, the example works fine (after replacing the
non-ASCII quote-like characters and removing the extra quote character
from the last line). The CsFileB sections in the attached CSD file
expand to:

---- clarinet ----
#define CLARINET(x) #
instr $x
endin
#
---- flute ----
#define FLUTE(x) #
instr $x
endin
#
---- bassoon ----
#define BASSOON(x) #
instr $x
endin
#
--------

David Akbari wrote:

>   #include “clarinet”
>   #include “flute”
>   #include “bassoon”
>   $CLARINET(1)
>   $FLUTE(2)
>   $BASSOON(3)"
> 
> This example would of course result in a preliminary exit from the 
> csoundPerformKsmps() loop and subsequent fatal error message even though 
> syntactically there is nothing wrong (assuming the current instance of 
> Csound is able to locate all #include'ed files from INCDIR.)

As far as I have tested it, the example works fine (after replacing the
non-ASCII quote-like characters and removing the extra quote character
from the last line). The CsFileB sections in the attached CSD file
expand to:

---- clarinet ----
#define CLARINET(x) #
instr $x
endin
#
---- flute ----
#define FLUTE(x) #
instr $x
endin
#
---- bassoon ----
#define BASSOON(x) #
instr $x
endin
#
--------