hi!  the latest csound.ppc (0.2.0b) is great.  it's totaly stable on my
machine (8500/120) and it's so nice not to have to quite every thirty
seconds!

but i'm having a strange problem:  sometimes when there are errors in my
orc/sco files, they won't appear in the output window until i hit kill and
close.  that is, i hit generate, the output window opens and maybe writes a
line or two, then perf either says "perfing" or "perf aborted" and just
waits.  nothing further happens in the output window.  then if i hit close
and then kill, all of the error messages will flash on the output window
for a moment just before the window closes!  i've been going crazy perfing
pieces over and over again just so that i can try to read, in that brief
moment, what sorts of errors i've dreamed up this time!  has anyone else
using this version (0.2.0b) seen similar behavior?  any suggestions?
here's an obviously flawed orc/score that will cause the behavior i'm
talking about:

orc:
+++++

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


instr 1
		asampout = asamp1 + asamp2
		out	asampout
endin

+++++

sco:

+++++

i1    0    10


douglas irving repetto  (a.k.a. irving bellemead)

email: glmrboy@music.calarts.edu
http://shoko.calarts.edu/~glmrboy

*       *       *       *       *       *       *       *

"What a lovely dog!  Does it have a phone?"

*       *       *       *       *       *       *       *

At 12:26 PM -0800 3/10/97, douglas irving repetto wrote:
>hi!  the latest csound.ppc (0.2.0b) is great.
>
>but i'm having a strange problem:[the screen output appears briefly
>after (KILL) before disappearing.  Has anyone else
>using this version (0.2.0b) seen similar behavior?  any suggestions?
>here's an obviously flawed orc/score that will cause the behavior i'm
>talking about:

It happens so often to me I thought it was a feature not a bug. I figured
it was supposed to help us develop our code debugging skills ;^).

But seriously, for version 0.2b software it's a minor inconvenience IMHO.

-----------------------------------------------------------------------------
Erik Spjut (rhymes with cute) - Associate Professor of Engineering   and/or
Associate Director for Engineering Computing in the Engineering Design Center
Harvey Mudd College, Claremont, CA 91711  USA
Erik_Spjut@hmc.edu     Ph & Voice mail (909) 607-3890     Fax (909) 621-8967

> 
> hi!  the latest csound.ppc (0.2.0b) is great.  it's totaly stable on my
...

> moment, what sorts of errors i've dreamed up this time!  has anyone else
> using this version (0.2.0b) seen similar behavior?  any suggestions?
> here's an obviously flawed orc/score that will cause the behavior i'm
> talking about:

Hi Doug,

Try changing the size of the output text buffer in the set buffers
dialog in csound.ppc.  It gets set to 50000 somehow and all the messages
get put in the buffer, which doesn't get flushed until quitting.

In our next release we have put a lot more buffer flushing in the code.
We have also fixed a bug that causes a crash with a bad MIDI orchestra,
added some new MIDI opcodes, support (beta) for 32bit float soundfiles, 
REAL TIME SOUND INPUT (marginally useful, long delay, but what the hell -
we have it basically working (well not crashing) on the development 
machine) and most of all we have incorporated John Fitches changes and
bug fixes and all of 3.45 opcodes into the release.  

We are hoping to get this out within the next week or so. We are hoping...

There are also sopme changes to the Front End ("launcher"), of which Matt
Ingalls is most aware - these are just the upcoming perf fixes.

Dave

> It happens so often to me I thought it was a feature not a bug. I figured

call it a bug or a feature, the problem is due to the port.  To use the
UNIX standard io (printf, etc...) we have to (unless we want to put in
a lot of work) use this SIOUX window supplied by Metrowerks.

The problem is that the window is really slow and can slow up generation
up to 20 times, unless a large text buffer is used.
But, if there is an error in the orchestra, the text buffer may never
fill up and consequently NEVER be flushed!!

To get around this, set the text buffer to '0' when debugging an
orchestra (from the 'set buffers' menu option), or you can use the
'listing file' piping output to a text file
rather than the SIOUX window.

Another problem (which may only be with the new version yet to be released
- code Warror 11) is that the buffer is automatically flushed after every
endof line.  so, if you are doing score generation stuff it could still
really slow it down (so you have to either turn off note amplitude
messages or use a listing file)

i think this is listed in the manual, plus was listed in the 'known bugs'
which accidentally was lost (sorry) with the last release...

we are planning on fixing this eventually, but it will be a big pain in
the butt!!

-matt