I noticed the following code while poking around sread.c:

          MYFLT operate(MYFLT a, MYFLT b, char c)
          {
              MYFLT ans;
              extern MYFLT MOD(MYFLT,MYFLT);
        
              switch (c) {
              case '+': ans = a+b; break;
              case '-': ans = a-b; break;
              case '*': ans = a*b; break;
              case '/': ans = a/b; break;
              case '%': ans = MOD(a,b); break;
              case '^': ans = (MYFLT)pow((double)a, (double)b); break;
are    ---->  case '&': ans = (MYFLT)(((long)a)&((long)b)); break;
these  ---->  case '|': ans = (MYFLT)(((long)a)&((long)b)); break;
right  ---->  case '#': ans = (MYFLT)(((long)a)&((long)b)); break;
?????         default:
                err_printf(Str(X_312,"Internal error op=%c\n"), c);
                longjmp(cglob.exitjmp,1);
              }
              return ans;
           }

I figured these three lines shouldn't all calculate the same result.  But I
didn't even know that you could use logical operators in score expressions!
It doesn't seem to be documented in the manual.

Also, the @ and @@ operators seem to be giving incorrect results for some
values but not others:

f1    0    [@30]     10    1
f2    0    [@@71]    10    1    0.5
f3    0    [@499]    10    1
f4    0    [@@499]   10    1    0.5
f5    0    [@1000]   10    1
f6    0    [@@5123]  10    1    0.5

becomes

f 1 0.000000 0.000000 64 64 10 1
f 2 0.000000 0.000000 257 257 10 1 0.5
f 3 0.000000 0.000000 1024 1024 10 1
f 4 0.000000 0.000000 1025 1025 10 1 0.5
f 5 0.000000 0.000000 1024 1024 10 1
f 6 0.000000 0.000000 16385 16385 10 1 0.5

Only f5 is correct if I understand @ and @@.

Anthony Kozar
anthony.kozar@utoledo.edu
http://akozar.spymac.net/

Bitwise operation in the score have been around for a long time.  The
fact that I messed up the final version suggests that no one uses it!

2002-01-20    

	* sread.c (operate): Added bitwise operations
	(getscochar): Added bit operations to [], possibly wrong precedence?

I will fix/look

Regarding @ and @@ odd.  I have used this for a long time and never
saw any problem.  Will look.

==John ff

>>>>> "Anthony" == Anthony Kozar  writes:

 Anthony> I noticed the following code while poking around sread.c:
 Anthony>           MYFLT operate(MYFLT a, MYFLT b, char c)
 Anthony>           {
 Anthony>               MYFLT ans;
 Anthony>               extern MYFLT MOD(MYFLT,MYFLT);
        
 Anthony>               switch (c) {
 Anthony>               case '+': ans = a+b; break;
 Anthony>               case '-': ans = a-b; break;
 Anthony>               case '*': ans = a*b; break;
 Anthony>               case '/': ans = a/b; break;
 Anthony>               case '%': ans = MOD(a,b); break;
 Anthony>               case '^': ans = (MYFLT)pow((double)a, (double)b); break;
 Anthony> are    ---->  case '&': ans = (MYFLT)(((long)a)&((long)b)); break;
 Anthony> these  ---->  case '|': ans = (MYFLT)(((long)a)&((long)b)); break;
 Anthony> right  ---->  case '#': ans = (MYFLT)(((long)a)&((long)b)); break;
 Anthony> ?????         default:
 Anthony>                 err_printf(Str(X_312,"Internal error op=%c\n"), c);
 Anthony>                 longjmp(cglob.exitjmp,1);
 Anthony>               }
 Anthony>               return ans;
 Anthony>            }

 Anthony> I figured these three lines shouldn't all calculate the same result.  But I
 Anthony> didn't even know that you could use logical operators in score expressions!
 Anthony> It doesn't seem to be documented in the manual.

 Anthony> Also, the @ and @@ operators seem to be giving incorrect results for some
 Anthony> values but not others:

 Anthony> f1    0    [@30]     10    1
 Anthony> f2    0    [@@71]    10    1    0.5
 Anthony> f3    0    [@499]    10    1
 Anthony> f4    0    [@@499]   10    1    0.5
 Anthony> f5    0    [@1000]   10    1
 Anthony> f6    0    [@@5123]  10    1    0.5

 Anthony> becomes

 Anthony> f 1 0.000000 0.000000 64 64 10 1
 Anthony> f 2 0.000000 0.000000 257 257 10 1 0.5
 Anthony> f 3 0.000000 0.000000 1024 1024 10 1
 Anthony> f 4 0.000000 0.000000 1025 1025 10 1 0.5
 Anthony> f 5 0.000000 0.000000 1024 1024 10 1
 Anthony> f 6 0.000000 0.000000 16385 16385 10 1 0.5

 Anthony> Only f5 is correct if I understand @ and @@.

 Anthony> Anthony Kozar
 Anthony> anthony.kozar@utoledo.edu
 Anthony> http://akozar.spymac.net/

Fixed the @ problem -- it only allowed even powers as I
got-it-wrong(tm)

Probably time for bugfix 12

==John ffitch

On 7/1/04 1:27 AM, jpff@codemist.co.uk etched in stone:

> Bitwise operation in the score have been around for a long time.  The
> fact that I messed up the final version suggests that no one uses it!

Indeed ! ;)

On 7/1/04 1:57 AM, jpff@codemist.co.uk etched in stone:

> Fixed the @ problem -- it only allowed even powers as I
> got-it-wrong(tm)
> 
> Probably time for bugfix 12

Thanks for the fixes John.  While we are looking at score interpretation
issues, here are a few more to chew on.  (Not to throw more work at you -- I
could try to fix these if you want me to do so).

1)  ^+ and ^- don't work properly if the instrument number is carried.

i 1    0    1
i 1    4
i 1    5
i .    ^+2

becomes

w 0 60
i 1 0.000000 0.000000 1.000000 1.000000
i 1 2.000000 2.000000 1.000000 1.000000
i 1 4.000000 4.000000 1.000000 1.000000
i 1 5.000000 5.000000 1.000000 1.000000

(I would note that the manual erroneously shows these operators with spaces
as ^ + x and ^ - x).


2)  Multiple t-statements in the same section cause i-statements to be
misinterpreted.


Ex.  ;;; tempobug2.sco ;;;

t 0.000 132.000
i 1 0.000 0.237 48 48
i 1 1.000 0.237 60 56

t 2.000 143.999
t 2.500 131.532
t 3.083 130.623
t 4.167 129.705

i 1 2.000 0.237 48 44
i 1 3.000 0.237 60 56
i 1 4.000 0.237 68 56
e

    ;;; score.srt ;;;

w 0.000 132.000
t 2.000 143.999
t 2.500 131.532
t 3.083 130.623
t 4.167 129.705
i 1 0.000000 0.000000 0.237000 0.107727 48 48
i 1 1.000000 0.454545 0.237000 0.107727 60 56
i 1 2.000000 0.909091 0.237000 0.107727 48 44
i 1 3.000000 1.363636 0.237000 0.107727 60 56
i 1 4.000000 1.818182 0.237000 0.107727 68 56
e

    ;;; tempobug2 output listing ;;;

Csound Version 4.23f11 (Apr 19 2004)
[...]
SECTION 1:
error in score.  illegal opcode t (ASCII 116)
error in score.  illegal opcode t (ASCII 116)
error in score.  illegal opcode t (ASCII 116)
error in score.  illegal opcode t (ASCII 116)
new alloc for instr 1:
WARNING: instr 1 uses 5 p-fields but is given 7
B  0.000 ..  1.000 T  1.000 TT  1.000 M:      0.0
WARNING: instr 1 uses 5 p-fields but is given 7
B  1.000 ..  1.455 T  1.455 TT  1.455 M:     21.0
B  1.455 ..  2.000 T  2.000 TT  2.000 M:      0.0
[etc.]

Now, I know that you aren't supposed to have multiple t-statements but this
is how the Mac Midi2Csound program outputs tempo changes.  I still think
that it is a bug to not deal with them gracefully.

What seems to be happening is that sread() only changes the first t -> w and
then when the orchestra receives them, even though it prints a warning, it
seems to be interpreting the following i-statements as unwarped (??).  So is
the correct fix here to have sread() remove the offending t's or to have the
performance not freak out about them (or both)?


3)  While debugging m & n, I discovered that there appears to be some of
Gab's code for nested and overlapping repeats in canonical (is this
correct?).  However, the {} score opcodes don't seem to be working either.

Ex.

{ 4 nn
    i1    0    1
    i1    +    0.5
    i1    +    .
}

only plays the three notes once, but produces these messages when running:

sorting score ...
External LOOP=4 Level:1
    ... done

The code for {} is present in the original 4.23 in which m and n work, but
this feature does not seem to do much except print out the above message.
Is this supposed to work?
(This feature is completely undocumented in the canonical manual AFAIK).


I will continue to look into these issues, but if someone else knows how to
easily solve them, be my guest.

Thanks!


Anthony Kozar
anthony.kozar@utoledo.edu
http://akozar.spymac.net/

when do you want to do that?  i have some bug fixes [and bugs to fix]
i can cvs or send you

-m

I think that I have solved the problem below.  (Hopefully without creating
any new ones :)  Looking into another problem though with negative
instrument numbers ...

Will update CVS later.

Anthony

On 7/1/04 3:44 AM, Anthony Kozar etched in stone:

> 1)  ^+ and ^- don't work properly if the instrument number is carried.
> 
> i 1    0    1
> i 1    4
> i 1    5
> i .    ^+2

I updated CVS with this bug fix and another bug in the error reporting for
the ^+ operator as well.

I also uploaded the changes to dl_opcodes.c that I made months ago to add
opcode plugin support for MacOS 9.  Should work the same as on other
platforms ( --opcode-lib=libname ) with the important caveat that the
"libname" that the user types in must exactly match the name of the code
fragment in the plugin library.  Since this name is invisible to the user,
it is highly recommended that anyone compiling opcode plugins for MacOS 9
make the filename and code fragment name identical.  (This also means that
pathnames are not allowed as the argument to --opcode-lib on MacOS 9).

Anthony Kozar
anthony.kozar@utoledo.edu
http://akozar.spymac.net/


On 7/1/04 4:49 PM, Anthony Kozar etched in stone:

> I think that I have solved the problem below.

> On 7/1/04 3:44 AM, Anthony Kozar etched in stone:
> 
>> 1)  ^+ and ^- don't work properly if the instrument number is carried.

Hi,
I just checked out the v19-devel branch for portaudio and Hooray! ASIO 
is now fixed (don't get the snapshot because it is out of date, you must 
get the sources from cvs). However, I wanted to check with Csound but I 
get the following error:

g++ -dynamic -o cscore.exe util1\cscore\cscore_main.o 
-LC:\projects\csound5\windows_dlls -Lcygwin_import_libs 
-LC:\tools\mingw\lib -LC:\tools\libsndfile-1.0.10pre8 
-LC:\tools\portaudiov19\lib -LC:\tools\fltk-1.1.5rc1\lib 
-LC:\msys\1.0\local\lib -LC:\tools\fluidsynth -L. -L. -L. 
-L\usr\include\lib -L\usr\local\lib -lcsound -lsndfile -lfltk -lstdc++ 
-lsupc++ -lkernel32 -lgdi32 -lwsock32 -lole32 -luuid
./libcsound.a(mididevice.o)(.text+0xca): In function `OpenMIDIDevice':
h:/c_progs/csound5/OOps/mididevice.c:203: undefined reference to 
`midiInGetNumDevs@0'
./libcsound.a(mididevice.o)(.text+0x109):h:/c_progs/csound5/OOps/mididevice.c:209: 
undefined reference to `midiInGetDevCapsA@12'
./libcsound.a(mididevice.o)(.text+0x18e):h:/c_progs/csound5/OOps/mididevice.c:228: 
undefined reference to `midiInOpen@20'
./libcsound.a(mididevice.o)(.text+0x1a3):h:/c_progs/csound5/OOps/mididevice.c:228: 
undefined reference to `midiInStart@4'
./libcsound.a(mididevice.o)(.text+0x3be): In function `CloseMIDIDevice':
h:/c_progs/csound5/OOps/mididevice.c:597: undefined reference to 
`midiInStop@4'
./libcsound.a(mididevice.o)(.text+0x3d3):h:/c_progs/csound5/OOps/mididevice.c:597: 
undefined reference to `midiInReset@4'
./libcsound.a(mididevice.o)(.text+0x40a):h:/c_progs/csound5/OOps/mididevice.c:618: 
undefined reference to `midiInClose@4'
./libcsound.a(midisend.o)(.text+0x21): In function `send_midi_message':
h:/c_progs/csound5/OOps/midisend.c:200: undefined reference to 
`midiOutShortMsg@8'
./libcsound.a(midisend.o)(.text+0x57): In function `note_on':
h:/c_progs/csound5/OOps/midisend.c:205: undefined reference to 
`midiOutShortMsg@8'
./libcsound.a(midisend.o)(.text+0x85): In function `note_off':
h:/c_progs/csound5/OOps/midisend.c:210: undefined reference to 
`midiOutShortMsg@8'
./libcsound.a(midisend.o)(.text+0xb7): In function `control_change':
h:/c_progs/csound5/OOps/midisend.c:215: undefined reference to 
`midiOutShortMsg@8'
./libcsound.a(midisend.o)(.text+0xdf): In function `after_touch':
h:/c_progs/csound5/OOps/midisend.c:220: undefined reference to 
`midiOutShortMsg@8'
./libcsound.a(midisend.o)(.text+0x10f):h:/c_progs/csound5/OOps/midisend.c:225: 
more undefined references to `midiOutShortMsg@8' follow
./libcsound.a(midisend.o)(.text+0x2b8): In function `openMIDIout':
h:/c_progs/csound5/OOps/midisend.c:240: undefined reference to 
`midiOutGetNumDevs@0'
./libcsound.a(midisend.o)(.text+0x335):h:/c_progs/csound5/OOps/midisend.c:253: 
undefined reference to `midiOutGetDevCapsA@12'
./libcsound.a(midisend.o)(.text+0x360):h:/c_progs/csound5/OOps/midisend.c:255: 
undefined reference to `midiOutOpen@20'
scons: building terminated because of errors.
scons: *** [cscore.exe] Error 1


Andres