Hi Chuckk,

I think that you are using m and n correctly but they have been broken for
some time now.  What is happening is that when the n statement causes the
score reader to loop back to the m statement, it does not stop at the end of
the section and so reads the n statement again and gets into an infinite
loop until memory is exhausted or something "bad" happens.

Fortunately, I think that I finally have fixed this problem.  (Several other
people have asked about it recently).  I also fixed an error with both m and
n where they cause the next score line to be skipped if the newline
character comes directly after the name for the m or n statement.

I will commit these fixes tomorrow after a little more testing.  m and n
should be working again once 5.08 final is released.

Anthony Kozar
mailing-lists-1001 AT anthonykozar DOT net
http://anthonykozar.net/

Chuckk Hubbard wrote on 2/18/08 3:37 PM:

> Hi.
> If I uncomment the n statement line I get a crash, with a thousand lines
> saying:
> Duplicate 0: mark (/tmp/fileVSU7AO.sco,35)
> then:
> cannot open input file /tmp/fileVSU7AO.sco
> 
> with or without the s statement.  Did I use m and n right?
> Also, if I put the m statement after the 2nd ftable, I only get 7
> boops.  But I'm more concerned about the n statement, if anyone can
> tell me what's happening.
> Thanks
> -Chuckk
> 

These are very perceptive questions, Chuckk, and I was thinking all last
night in between sleep (and perhaps during) about what the answers should
be.  I've made some more comments below.

Chuckk Hubbard wrote on 2/19/08 3:12 AM:

> While we're on the subject, though, I'm curious, are m and/or n
> statements intended to act as section markers too?  It seems to me
> they would have to; because otherwise, this, for instance:

Well, being able to mark the middle of a section to repeat somewhere else
would be useful, I think, but it is not possible with the current
implementation.

> i1 5 1
> i1 6 1
> m refrain
> i1 7 2
> i1 9 2
> n refrain

There is actually a very serious problem with this input: it creates an
endless loop because there is no s, e, or r statement before the "n
refrain".  When Csound encounters an n statement, it immediately starts
re-reading the score file from the corresponding m marker.  The marked
statements are not stored in any in-memory buffer.

I was considering last night whether the n statement should be considered to
end a section because it always includes a copy of the s statement at the
end of the marked section.  The following does not seem unreasonable, but
does not currently work because of a bug in the score parser:

m sec1
i1 0 1
s
m sec2
i2 0 1
n sec1  ; this includes the above s
n sec2

> But that invites the question of whether previous t statements, or a,
> b, etc. should carry over m or n...

Well, AFAICT, the current implementation of the m statement does not start a
new section nor is it required to be at the beginning of a section.  So, I
think that t, b, and v will all affect the statements after an m until the
next s.  Also, the n statement does not explicitly begin a new section
(although it is intended to be at the beginning of one I think) and so you
can theoretically have other score statements before the n be a part of the
same section.  So, theoretically, you can do things like this:

i1 0 1
m sec1
i1 1 1
s
i2 0 1
n sec1

or 

i1 0 1 8.00
m sec1
i1 1 1 8.02
i1 2 1 8.03
s
b -1
n sec1

The first of these does not work but the second actually does.

I think that it would be very useful to be able to include any statements
before an n statement as part of the same section -- the n statement must
come last and "ends" the section.  However, due to difficulties with
detecting whether an n statement will cause an endless loop, I think that n
statements should not be allowed in any section that includes an m
statement.

I also think that it would be nice to be able to set multiple marks (m
statements) at different locations within the same section.  This does
currently work OK but the later marks can end up being defined more than
once (seemingly benignly so, but I would prevent this).

I will see what the other developers think about expanding the semantics of
m and n a little bit and adding better error checking in the process.

Anthony Kozar
mailing-lists-1001 AT anthonykozar DOT net
http://anthonykozar.net/

While testing and working on this (and adding new features and  
improvements I hope)
please check the advance statement too - I think it was skipping the  
first statement on the Mac
at least.

-dB


On Feb 19, 2008, at 1:45 PM, Anthony Kozar wrote:

> These are very perceptive questions, Chuckk, and I was thinking all  
> last
> night in between sleep (and perhaps during) about what the answers  
> should
> be.  I've made some more comments below.
>
> Chuckk Hubbard wrote on 2/19/08 3:12 AM:
>
>> While we're on the subject, though, I'm curious, are m and/or n
>> statements intended to act as section markers too?  It seems to me
>> they would have to; because otherwise, this, for instance:
>
> Well, being able to mark the middle of a section to repeat  
> somewhere else
> would be useful, I think, but it is not possible with the current
> implementation.
>
>> i1 5 1
>> i1 6 1
>> m refrain
>> i1 7 2
>> i1 9 2
>> n refrain
>
> There is actually a very serious problem with this input: it  
> creates an
> endless loop because there is no s, e, or r statement before the "n
> refrain".  When Csound encounters an n statement, it immediately  
> starts
> re-reading the score file from the corresponding m marker.  The marked
> statements are not stored in any in-memory buffer.
>
> I was considering last night whether the n statement should be  
> considered to
> end a section because it always includes a copy of the s statement  
> at the
> end of the marked section.  The following does not seem  
> unreasonable, but
> does not currently work because of a bug in the score parser:
>
> m sec1
> i1 0 1
> s
> m sec2
> i2 0 1
> n sec1  ; this includes the above s
> n sec2
>
>> But that invites the question of whether previous t statements, or a,
>> b, etc. should carry over m or n...
>
> Well, AFAICT, the current implementation of the m statement does  
> not start a
> new section nor is it required to be at the beginning of a  
> section.  So, I
> think that t, b, and v will all affect the statements after an m  
> until the
> next s.  Also, the n statement does not explicitly begin a new section
> (although it is intended to be at the beginning of one I think) and  
> so you
> can theoretically have other score statements before the n be a  
> part of the
> same section.  So, theoretically, you can do things like this:
>
> i1 0 1
> m sec1
> i1 1 1
> s
> i2 0 1
> n sec1
>
> or
>
> i1 0 1 8.00
> m sec1
> i1 1 1 8.02
> i1 2 1 8.03
> s
> b -1
> n sec1
>
> The first of these does not work but the second actually does.
>
> I think that it would be very useful to be able to include any  
> statements
> before an n statement as part of the same section -- the n  
> statement must
> come last and "ends" the section.  However, due to difficulties with
> detecting whether an n statement will cause an endless loop, I  
> think that n
> statements should not be allowed in any section that includes an m
> statement.
>
> I also think that it would be nice to be able to set multiple marks (m
> statements) at different locations within the same section.  This does
> currently work OK but the later marks can end up being defined more  
> than
> once (seemingly benignly so, but I would prevent this).
>
> I will see what the other developers think about expanding the  
> semantics of
> m and n a little bit and adding better error checking in the process.
>
> Anthony Kozar
> mailing-lists-1001 AT anthonykozar DOT net
> http://anthonykozar.net/
>
>
>
> Send bugs reports to this list.
> To unsubscribe, send email sympa@lists.bath.ac.uk with body  
> "unsubscribe csound"