I'm dusting off an old Csound project from 2013, which would have been
written for whatever version of Csound was current at the time.  When I
try to compile it with the version currently installed on my system, which
is Csound 6.04, it doesn't work; Csound gives the error "score error:  {:
invalid repeat count".

With a bit of experimentation, I've determined that the issue is with
using square-bracket calculations in the repeat count of the curly-brace
repeat construct.  I had syntax like this in the score:

{ [$A+$B]
i1 2 3 4 5
i1 4 5 6 7
}

Although both my example and my actual file were using macros inside the
square brackets, and in my actual file I was doing this inside a macro
definition of its own, I've verified that Csound also fails if I use just
"[2]" or similar as the repeat count, outside a macro definition; it is
having square brackets in the repeat count at all that causes the problem,
not the involvement of macros.  I haven't (yet) experimented with
different old versions of Csound to see which ones can compile the file,
but I'm sure that in 2013 when I wrote this file I must have had a Csound
that could work with it.

So, my questions are:  was this feature deliberately removed from Csound
some time in the last few years?  Is its failure to work in 6.04 a bug?
Is there some easy workaround?  I think I can modify my file by doing the
calculation by hand and substituting the result in without using
square-bracket calculations, but it'd be nice if I could compile my file
unmodified.

-- 
Matthew Skala
mskala@ansuz.sooke.bc.ca                 People before tribes.
https://ansuz.sooke.bc.ca/

Csound mailing list
Csound@listserv.heanet.ie
https://listserv.heanet.ie/cgi-bin/wa?A0=CSOUND
Send bugs reports to
        https://github.com/csound/csound/issues
Discussions of bugs and features can be posted here

On Sun, 19 May 2019, Pete Goodeve wrote:
> Is that curly-brace construct documented *anywhere*?  I've searched
> the manual without finding any reference. I thought it would be an
> alternative to the 'r' statement but experimentally it's not -- it runs
> n instances in parallel.

I don't think it's obscure, it's right here in the canonical manual:

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

I don't believe it really runs n instances in parallel.  What it does is
it repeats n copies of the contents in the score as if they had been
explicitly typed n times.  If the statements contained in the braces have
directly-specified numeric p2 values then yes, they'll execute
simultaneously, but they don't have to be written that way.  I'm using it,
and I think this is the normal way to use it, with stuff like "^+1" and
"<" in the p-fields to make the different repetitions of the statements
happen at different times and with different parameters.  Although I'm not
using this part of the syntax in the piece currently at issue, there is
also an optional macro name redefined with a different number per
iteration, which can be used to make the reptitions differ from each
other.

-- 
Matthew Skala
mskala@ansuz.sooke.bc.ca                 People before tribes.
https://ansuz.sooke.bc.ca/

Csound mailing list
Csound@listserv.heanet.ie
https://listserv.heanet.ie/cgi-bin/wa?A0=CSOUND
Send bugs reports to
        https://github.com/csound/csound/issues
Discussions of bugs and features can be posted here

I will look to see if I can allow [] and macros in the repeat count.  This 
area is somewhat byzantine.....



On Sun, 19 May 2019, Pete Goodeve wrote:

> Sorry -- can't resist poking my nose in when I see something I know
> nothing about...! (:-/)
>
> Is that curly-brace construct documented *anywhere*?  I've searched
> the manual without finding any reference. I thought it would be an
> alternative to the 'r' statement but experimentally it's not -- it runs
> n instances in parallel.
>
> Anyway, I can corroborate the finding.  In Csound 6, a construct
> like:
>
>   { 3
>    i1...
>   }
>
> works,
>
>   { [3]
>    i1...
>   }
>
> gives "invalid repeat count".
>
> The latter in Csound 5 works fine.  I also find that in Csound 6
> "r [3]" gives the same error.
>
> 	-- Pete --
>
>
>
> On Sat, May 18, 2019 at 09:45:18PM -0400, mskala@ANSUZ.SOOKE.BC.CA wrote:
>> I'm dusting off an old Csound project from 2013, which would have been
>> written for whatever version of Csound was current at the time.  When I
>> try to compile it with the version currently installed on my system, which
>> is Csound 6.04, it doesn't work; Csound gives the error "score error:  {:
>> invalid repeat count".
>>
>> With a bit of experimentation, I've determined that the issue is with
>> using square-bracket calculations in the repeat count of the curly-brace
>> repeat construct.  I had syntax like this in the score:
>>
>> { [$A+$B]
>> i1 2 3 4 5
>> i1 4 5 6 7
>> }
>>
>> Although both my example and my actual file were using macros inside the
>> square brackets, and in my actual file I was doing this inside a macro
>> definition of its own, I've verified that Csound also fails if I use just
>> "[2]" or similar as the repeat count, outside a macro definition; it is
>> having square brackets in the repeat count at all that causes the problem,
>> not the involvement of macros.  I haven't (yet) experimented with
>> different old versions of Csound to see which ones can compile the file,
>> but I'm sure that in 2013 when I wrote this file I must have had a Csound
>> that could work with it.
>>
>> So, my questions are:  was this feature deliberately removed from Csound
>> some time in the last few years?  Is its failure to work in 6.04 a bug?
>> Is there some easy workaround?  I think I can modify my file by doing the
>> calculation by hand and substituting the result in without using
>> square-bracket calculations, but it'd be nice if I could compile my file
>> unmodified.
>>
>> --
>> Matthew Skala
>> mskala@ansuz.sooke.bc.ca                 People before tribes.
>> https://ansuz.sooke.bc.ca/
>>
>> Csound mailing list
>> Csound@listserv.heanet.ie
>> https://listserv.heanet.ie/cgi-bin/wa?A0=CSOUND
>> Send bugs reports to
>>         https://github.com/csound/csound/issues
>> Discussions of bugs and features can be posted here
>
> Csound mailing list
> Csound@listserv.heanet.ie
> https://listserv.heanet.ie/cgi-bin/wa?A0=CSOUND
> Send bugs reports to
>        https://github.com/csound/csound/issues
> Discussions of bugs and features can be posted here
>

Csound mailing list
Csound@listserv.heanet.ie
https://listserv.heanet.ie/cgi-bin/wa?A0=CSOUND
Send bugs reports to
        https://github.com/csound/csound/issues
Discussions of bugs and features can be posted here

The curent implementation expnds al macros and macro-related forms before 
lexing an parsing.  In particular the use of expressions within [ ] is a 
parsing issue with an arbitrary memry requirement.  In the macro expansion 
stage the number of loops is either an explicit positive integer or a 
macro call defining a positive integer.

I looked at extending this to bracketted values and concluding that while 
possible it would take a great deal of code at least 200 lines but I 
suspect significantly more.  This code would duplicate code esewhere with 
added complications.

The manual to my mind says it takes an integer value and that was always 
the intension.  Maye if=t should be clarified.



On Sun, 19 May 2019, mskala@ANSUZ.SOOKE.BC.CA wrote:

> On Sun, 19 May 2019, Pete Goodeve wrote:
>> Is that curly-brace construct documented *anywhere*?  I've searched
>> the manual without finding any reference. I thought it would be an
>> alternative to the 'r' statement but experimentally it's not -- it runs
>> n instances in parallel.
>
> I don't think it's obscure, it's right here in the canonical manual:
>
>   http://www.csounds.com/manual/html/leftbrace.html
>
> I don't believe it really runs n instances in parallel.  What it does is
> it repeats n copies of the contents in the score as if they had been
> explicitly typed n times.  If the statements contained in the braces have
> directly-specified numeric p2 values then yes, they'll execute
> simultaneously, but they don't have to be written that way.  I'm using it,
> and I think this is the normal way to use it, with stuff like "^+1" and
> "<" in the p-fields to make the different repetitions of the statements
> happen at different times and with different parameters.  Although I'm not
> using this part of the syntax in the piece currently at issue, there is
> also an optional macro name redefined with a different number per
> iteration, which can be used to make the reptitions differ from each
> other.
>
> -- 
> Matthew Skala
> mskala@ansuz.sooke.bc.ca                 People before tribes.
> https://ansuz.sooke.bc.ca/
>
> Csound mailing list
> Csound@listserv.heanet.ie
> https://listserv.heanet.ie/cgi-bin/wa?A0=CSOUND
> Send bugs reports to
>        https://github.com/csound/csound/issues
> Discussions of bugs and features can be posted here
>

Csound mailing list
Csound@listserv.heanet.ie
https://listserv.heanet.ie/cgi-bin/wa?A0=CSOUND
Send bugs reports to
        https://github.com/csound/csound/issues
Discussions of bugs and features can be posted here

On Mon, 20 May 2019, john wrote:
> I looked at extending this to bracketted values and concluding that while
> possible it would take a great deal of code at least 200 lines but I suspect
> significantly more.  This code would duplicate code esewhere with added
> complications.
>
> The manual to my mind says it takes an integer value and that was always the
> intension.  Maye if=t should be clarified.

That's disappointing because it worked in older versions and has been
broken by a change in Csound version.  This is a regression report, not a
request for "extension"; and the reason to expect it to work is that
square-bracketed calculations work in p-fields in general, and the manual
describes the parameter to { as a p-field.  If it can't accept a
calculated integer as other integer p-fields do (which is plausible if the
{ has been changed from once being like other score statemetns, to now
being some kind of syntactic thing handled differently from other score
statements) then the parameter shouldn't be documented as a p-field.
Saying "integer" isn't enough to convey that it does not follow the same
general rules as other p-fields.

Anyway, is it easy to determine what was the last version of Csound in
which it was possible to use calculated values in the { repeat count?
If I have to rewrite my score to work with a current version, I'd
like to have a baseline to compare against to make sure I am changing
nothing else.

-- 
Matthew Skala
mskala@ansuz.sooke.bc.ca                 People before tribes.
https://ansuz.sooke.bc.ca/

Csound mailing list
Csound@listserv.heanet.ie
https://listserv.heanet.ie/cgi-bin/wa?A0=CSOUND
Send bugs reports to
        https://github.com/csound/csound/issues
Discussions of bugs and features can be posted here

I have a version that does some of tis.  Accepts an integer, a macro an 
integer in [] and a macro in [].  Just started to do hte expression coding

On Sun, 19 May 2019, Pete Goodeve wrote:

> Sorry -- can't resist poking my nose in when I see something I know
> nothing about...! (:-/)
>
> Is that curly-brace construct documented *anywhere*?  I've searched
> the manual without finding any reference. I thought it would be an
> alternative to the 'r' statement but experimentally it's not -- it runs
> n instances in parallel.
>
> Anyway, I can corroborate the finding.  In Csound 6, a construct
> like:
>
>   { 3
>    i1...
>   }
>
> works,
>
>   { [3]
>    i1...
>   }
>
> gives "invalid repeat count".
>
> The latter in Csound 5 works fine.  I also find that in Csound 6
> "r [3]" gives the same error.
>
> 	-- Pete --
>
>
>
> On Sat, May 18, 2019 at 09:45:18PM -0400, mskala@ANSUZ.SOOKE.BC.CA wrote:
>> I'm dusting off an old Csound project from 2013, which would have been
>> written for whatever version of Csound was current at the time.  When I
>> try to compile it with the version currently installed on my system, which
>> is Csound 6.04, it doesn't work; Csound gives the error "score error:  {:
>> invalid repeat count".
>>
>> With a bit of experimentation, I've determined that the issue is with
>> using square-bracket calculations in the repeat count of the curly-brace
>> repeat construct.  I had syntax like this in the score:
>>
>> { [$A+$B]
>> i1 2 3 4 5
>> i1 4 5 6 7
>> }
>>
>> Although both my example and my actual file were using macros inside the
>> square brackets, and in my actual file I was doing this inside a macro
>> definition of its own, I've verified that Csound also fails if I use just
>> "[2]" or similar as the repeat count, outside a macro definition; it is
>> having square brackets in the repeat count at all that causes the problem,
>> not the involvement of macros.  I haven't (yet) experimented with
>> different old versions of Csound to see which ones can compile the file,
>> but I'm sure that in 2013 when I wrote this file I must have had a Csound
>> that could work with it.
>>
>> So, my questions are:  was this feature deliberately removed from Csound
>> some time in the last few years?  Is its failure to work in 6.04 a bug?
>> Is there some easy workaround?  I think I can modify my file by doing the
>> calculation by hand and substituting the result in without using
>> square-bracket calculations, but it'd be nice if I could compile my file
>> unmodified.
>>
>> --
>> Matthew Skala
>> mskala@ansuz.sooke.bc.ca                 People before tribes.
>> https://ansuz.sooke.bc.ca/
>>
>> Csound mailing list
>> Csound@listserv.heanet.ie
>> https://listserv.heanet.ie/cgi-bin/wa?A0=CSOUND
>> Send bugs reports to
>>         https://github.com/csound/csound/issues
>> Discussions of bugs and features can be posted here
>
> Csound mailing list
> Csound@listserv.heanet.ie
> https://listserv.heanet.ie/cgi-bin/wa?A0=CSOUND
> Send bugs reports to
>        https://github.com/csound/csound/issues
> Discussions of bugs and features can be posted here
>

Csound mailing list
Csound@listserv.heanet.ie
https://listserv.heanet.ie/cgi-bin/wa?A0=CSOUND
Send bugs reports to
        https://github.com/csound/csound/issues
Discussions of bugs and features can be posted here

I now have code that does what you asked -- about 200 extra lines as I 
suggested.  Only mildly tested and the calvculation in the [] is in 
integer mode without the power operator (I hope to fix that lacuna when I 
have time/energy).

At present this is only in the naw_arrays branch as that is whta  was 
dong, but I will look into moving it to develop for easier access.

I wil try to add some more words to the manual page.

==John ff

On Sat, 18 May 2019, mskala@ANSUZ.SOOKE.BC.CA wrote:

> I'm dusting off an old Csound project from 2013, which would have been
> written for whatever version of Csound was current at the time.  When I
> try to compile it with the version currently installed on my system, which
> is Csound 6.04, it doesn't work; Csound gives the error "score error:  {:
> invalid repeat count".
>
> With a bit of experimentation, I've determined that the issue is with
> using square-bracket calculations in the repeat count of the curly-brace
> repeat construct.  I had syntax like this in the score:
>
> { [$A+$B]
> i1 2 3 4 5
> i1 4 5 6 7
> }
>
> Although both my example and my actual file were using macros inside the
> square brackets, and in my actual file I was doing this inside a macro
> definition of its own, I've verified that Csound also fails if I use just
> "[2]" or similar as the repeat count, outside a macro definition; it is
> having square brackets in the repeat count at all that causes the problem,
> not the involvement of macros.  I haven't (yet) experimented with
> different old versions of Csound to see which ones can compile the file,
> but I'm sure that in 2013 when I wrote this file I must have had a Csound
> that could work with it.
>
> So, my questions are:  was this feature deliberately removed from Csound
> some time in the last few years?  Is its failure to work in 6.04 a bug?
> Is there some easy workaround?  I think I can modify my file by doing the
> calculation by hand and substituting the result in without using
> square-bracket calculations, but it'd be nice if I could compile my file
> unmodified.
>
> -- 
> Matthew Skala
> mskala@ansuz.sooke.bc.ca                 People before tribes.
> https://ansuz.sooke.bc.ca/
>
> Csound mailing list
> Csound@listserv.heanet.ie
> https://listserv.heanet.ie/cgi-bin/wa?A0=CSOUND
> Send bugs reports to
>        https://github.com/csound/csound/issues
> Discussions of bugs and features can be posted here
>

Csound mailing list
Csound@listserv.heanet.ie
https://listserv.heanet.ie/cgi-bin/wa?A0=CSOUND
Send bugs reports to
        https://github.com/csound/csound/issues
Discussions of bugs and features can be posted here

On Thu, 23 May 2019, john wrote:
> I now have code that does what you asked -- about 200 extra lines as I
> suggested.  Only mildly tested and the calvculation in the [] is in integer
> mode without the power operator (I hope to fix that lacuna when I have
> time/energy).

Thanks!

-- 
Matthew Skala
mskala@ansuz.sooke.bc.ca                 People before tribes.
https://ansuz.sooke.bc.ca/

Csound mailing list
Csound@listserv.heanet.ie
https://listserv.heanet.ie/cgi-bin/wa?A0=CSOUND
Send bugs reports to
        https://github.com/csound/csound/issues
Discussions of bugs and features can be posted here

On Thu, 23 May 2019, mskala@ANSUZ.SOOKE.BC.CA wrote:
> On Thu, 23 May 2019, john wrote:
> > I now have code that does what you asked -- about 200 extra lines as I
> > suggested.  Only mildly tested and the calvculation in the [] is in integer
> > mode without the power operator (I hope to fix that lacuna when I have
> > time/energy).
>
> Thanks!

Update:  doesn't seem to work on expressions that contain parentheses.
The error message is

** ] case
illegal placement of '(' in [] expression{: invalid repeat count

Even so simple an expression as [(1)] gives this message; I haven't been
able to come up with any example of an expression containing parentheses
that works.  I think this happens because the "type" variable is always
set to 1 before entering the switch statement in bodmas(), and the switch
statement throws this error if a '(' character is encountered when type is
not zero.

I attempted a "git bisect" to try to find the last version of Csound in
which it worked, and I suspect the issue was introduced with Csound 6, but
it's not as clear as I might like.  Versions before 6 fail to compile on
my current system, apparently because of updates in dependencies, but the
earliest 6.0 versions still show the problem and appear to have
introduced all-new parsing, which would be a reasonable place to expect
the syntax to have changed.

Rather than implementing a whole new parser (*and* a new integer-only
model of computation) just for brace repeat count expressions, or my going
to great lengths to spin up an outdated version of Csound to compile my
old files, it's probably best that I try to rewrite my score to no longer
use a calculated value for the repeat count.

-- 
Matthew Skala
mskala@ansuz.sooke.bc.ca                 People before tribes.
https://ansuz.sooke.bc.ca/

Csound mailing list
Csound@listserv.heanet.ie
https://listserv.heanet.ie/cgi-bin/wa?A0=CSOUND
Send bugs reports to
        https://github.com/csound/csound/issues
Discussions of bugs and features can be posted here

Sorry it is meant to.  Does that construct work in I statements?  The code is almost the same I thought.
Will look tomorrow.

⁣Sent from TypeApp ​

On May 23, 2019, 18:12, at 18:12, mskala@ansuz.sooke.bc.ca wrote:
>On Thu, 23 May 2019, mskala@ANSUZ.SOOKE.BC.CA wrote:
>> On Thu, 23 May 2019, john wrote:
>> > I now have code that does what you asked -- about 200 extra lines
>as I
>> > suggested.  Only mildly tested and the calvculation in the [] is in
>integer
>> > mode without the power operator (I hope to fix that lacuna when I
>have
>> > time/energy).
>>
>> Thanks!
>
>Update:  doesn't seem to work on expressions that contain parentheses.
>The error message is
>
>** ] case
>illegal placement of '(' in [] expression{: invalid repeat count
>
>Even so simple an expression as [(1)] gives this message; I haven't
>been
>able to come up with any example of an expression containing
>parentheses
>that works.  I think this happens because the "type" variable is always
>set to 1 before entering the switch statement in bodmas(), and the
>switch
>statement throws this error if a '(' character is encountered when type
>is
>not zero.
>
>I attempted a "git bisect" to try to find the last version of Csound in
>which it worked, and I suspect the issue was introduced with Csound 6,
>but
>it's not as clear as I might like.  Versions before 6 fail to compile
>on
>my current system, apparently because of updates in dependencies, but
>the
>earliest 6.0 versions still show the problem and appear to have
>introduced all-new parsing, which would be a reasonable place to expect
>the syntax to have changed.
>
>Rather than implementing a whole new parser (*and* a new integer-only
>model of computation) just for brace repeat count expressions, or my
>going
>to great lengths to spin up an outdated version of Csound to compile my
>old files, it's probably best that I try to rewrite my score to no
>longer
>use a calculated value for the repeat count.
>
>-- 
>Matthew Skala
>mskala@ansuz.sooke.bc.ca                 People before tribes.
>https://ansuz.sooke.bc.ca/
>
>Csound mailing list
>Csound@listserv.heanet.ie
>https://listserv.heanet.ie/cgi-bin/wa?A0=CSOUND
>Send bugs reports to
>        https://github.com/csound/csound/issues
>Discussions of bugs and features can be posted here

Csound mailing list
Csound@listserv.heanet.ie
https://listserv.heanet.ie/cgi-bin/wa?A0=CSOUND
Send bugs reports to
        https://github.com/csound/csound/issues
Discussions of bugs and features can be posted here

On Thu, 23 May 2019, John ff wrote:
> On May 23, 2019, 18:12, at 18:12, mskala@ansuz.sooke.bc.ca wrote:
> >Update:  doesn't seem to work on expressions that contain parentheses.
>
> Sorry it is meant to.  Does that construct work in I statements?  The
> code is almost the same I thought.

Bracketed expressions that contain parentheses do work in I statements (or
at least, do not produce this error; I haven't tested them extensively for
correctness).  The critical difference seems to be that the similar code
in Engine/sread.c sets the type variable inside the switch() statement,
only when it actually has read a number; whereas the new code for
bracketed repeat count expressions unconditionally attempts to read a
number, and then sets type=1, before entering the switch() statement at all.

In the mean time, I've attempted to rewrite my score file to work with
current Csound and have run into a few other issues.  Left-brace repeats
sometimes cause segfaults even when the repeat count is a literal integer
constant (no calculation).  It seems to be more likely when the amount of
repeated material is greater (more repeats OR more stuff inside the
repeat) but size doesn't completely determine the behaviour.  I ended up
writing a Perl program to expand out all the repeats, so as not to use the
left-brace feature in Csound at all, and the result compiles but doesn't
sound like the original.  Some notes seem to be sounding simultaneously
that were sequential in old Csound, possibly because of syntax like
"^+1.0" in p2 not having the same meaning.  I don't have a coherent
account yet of exactly what's wrong, though, bearing in mind that my real
goal is just to compile the same piece of music I had before, and not to
particularly debug Csound.  In general it looks like score handling has
changed a lot in 6.0.

-- 
Matthew Skala
mskala@ansuz.sooke.bc.ca                 People before tribes.
https://ansuz.sooke.bc.ca/

Csound mailing list
Csound@listserv.heanet.ie
https://listserv.heanet.ie/cgi-bin/wa?A0=CSOUND
Send bugs reports to
        https://github.com/csound/csound/issues
Discussions of bugs and features can be posted here

I think it is better now -- please try
=J

Csound mailing list
Csound@listserv.heanet.ie
https://listserv.heanet.ie/cgi-bin/wa?A0=CSOUND
Send bugs reports to
        https://github.com/csound/csound/issues
Discussions of bugs and features can be posted here

On Fri, 24 May 2019, john wrote:
> I think it is better now -- please try

With commit 0001f43 from the develop branch, it still says "score error:
{: invalid repeat count" but no longer complains about the parentheses
specifically.  It apparently fails on all use of a bracketed calculation
as the repeat count, even "[1]".

Would it be helpful if I prepared a set of test cases?  My original score
isn't easy to transfer because it depends on a few hundred megabytes of
sample material, but - given a few days, and only if it'll be helpful - I
could easily prepare some smaller self-contained scores demonstrating the
issues.

-- 
Matthew Skala
mskala@ansuz.sooke.bc.ca                 People before tribes.
https://ansuz.sooke.bc.ca/

Csound mailing list
Csound@listserv.heanet.ie
https://listserv.heanet.ie/cgi-bin/wa?A0=CSOUND
Send bugs reports to
        https://github.com/csound/csound/issues
Discussions of bugs and features can be posted here

I have tried a number of configurations which so far all have worked.  So 
yes, I would love some simple examples.  So does not need an orchestra as 
score expansion is completely separate.

Csound mailing list
Csound@listserv.heanet.ie
https://listserv.heanet.ie/cgi-bin/wa?A0=CSOUND
Send bugs reports to
        https://github.com/csound/csound/issues
Discussions of bugs and features can be posted here

The csd below all works; so I need an example of it being wrong

==John ff



instr 1
exitnow
endin



#define A #2#
#define B #5#

i2 0 1 "[2]"
{ [2]
i1 2 3 4 5
i1 4 5 6 7
}
s

i2 0 1 "2"
{ 2
i1 2 3 4 5
i1 4 5 6 7
}
s

i2 0 1 "[(2)]"
{ [(2)]
i1 2 3 4 5
i1 4 5 6 7
}
s

i2 0 1 "[A+2]"
{ [$A+2]
i1 2 3 4 5
i1 4 5 6 7
}
s

i2 0 1 "[A+B]"
{ [$A+$B]
i1 2 3 4 5
i1 4 5 6 7
}
s

i2 0 1 "[1+3*4]"
{ [1+3*4]
i1 2 3 4 5
i1 4 5 6 7
}
s

e






On Fri, 24 May 2019, mskala@ANSUZ.SOOKE.BC.CA wrote:

> On Fri, 24 May 2019, john wrote:
>> I think it is better now -- please try
>
> With commit 0001f43 from the develop branch, it still says "score error:
> {: invalid repeat count" but no longer complains about the parentheses
> specifically.  It apparently fails on all use of a bracketed calculation
> as the repeat count, even "[1]".
>
> Would it be helpful if I prepared a set of test cases?  My original score
> isn't easy to transfer because it depends on a few hundred megabytes of
> sample material, but - given a few days, and only if it'll be helpful - I
> could easily prepare some smaller self-contained scores demonstrating the
> issues.
>
> -- 
> Matthew Skala
> mskala@ansuz.sooke.bc.ca                 People before tribes.
> https://ansuz.sooke.bc.ca/
>
> Csound mailing list
> Csound@listserv.heanet.ie
> https://listserv.heanet.ie/cgi-bin/wa?A0=CSOUND
> Send bugs reports to
>        https://github.com/csound/csound/issues
> Discussions of bugs and features can be posted here
>

Csound mailing list
Csound@listserv.heanet.ie
https://listserv.heanet.ie/cgi-bin/wa?A0=CSOUND
Send bugs reports to
        https://github.com/csound/csound/issues
Discussions of bugs and features can be posted here

On Sat, 25 May 2019, john wrote:
> The csd below all works; so I need an example of it being wrong

Thank you for your efforts.  These cases are almost the same as the set I
was preparing, which I said yesterday I'd have ready in a few days.  When
I tried to run them immediately, none of them worked.  However, after
deleting my entire local Csound repository and re-cloning it from Github,
the latest version in the develop branch (which I *thought* was exactly
the same revision I'd been testing) compiles these cases, so it looks
like there was something wrong with my local copy, possibly related to
confusion in the build system caused when I switched between branches, or
the local hacking I need to do after every git operation to get it to
compile without attempting to use Java.

The case of a macro taking a parameter still doesn't work, but is not
really important:

#define F(X) #($X/2)#

i2 0 1 "[$F(4)]"
{ [$F(4)]
i1 2 3 4 5
i1 4 5 6 7
}
s

Unfortunately, my big file from 2013 still doesn't produce the same output
now that it did in 2013 - there seems to be something causing some events
(maybe programmatically-generated ones?) to all happen at once, so that
the amplitude goes way out of range - but it will take me some time to
figure out what the problem there actually is, and it seems unrelated to
brace repeats.  At least now (with a minor change to avoid using macro
parameters in repeat counts) it compiles!

-- 
Matthew Skala
mskala@ansuz.sooke.bc.ca                 People before tribes.
https://ansuz.sooke.bc.ca/

Csound mailing list
Csound@listserv.heanet.ie
https://listserv.heanet.ie/cgi-bin/wa?A0=CSOUND
Send bugs reports to
        https://github.com/csound/csound/issues
Discussions of bugs and features can be posted here

I now have a version that treats nacros without argumets correctly.  No 
attempt at macros with argumets yet -- I think I know howto do it but it 
will takre a while.  The new code may be fragile but it is gong the 
correct 
way
==J

On Sat, 25 May 2019, mskala@ANSUZ.SOOKE.BC.CA wrote:

> On Sat, 25 May 2019, john wrote:
>> The csd below all works; so I need an example of it being wrong
>
> Thank you for your efforts.  These cases are almost the same as the set I
> was preparing, which I said yesterday I'd have ready in a few days.  When
> I tried to run them immediately, none of them worked.  However, after
> deleting my entire local Csound repository and re-cloning it from Github,
> the latest version in the develop branch (which I *thought* was exactly
> the same revision I'd been testing) compiles these cases, so it looks
> like there was something wrong with my local copy, possibly related to
> confusion in the build system caused when I switched between branches, or
> the local hacking I need to do after every git operation to get it to
> compile without attempting to use Java.
>
> The case of a macro taking a parameter still doesn't work, but is not
> really important:
>
> #define F(X) #($X/2)#
>
> i2 0 1 "[$F(4)]"
> { [$F(4)]
> i1 2 3 4 5
> i1 4 5 6 7
> }
> s
>
> Unfortunately, my big file from 2013 still doesn't produce the same output
> now that it did in 2013 - there seems to be something causing some events
> (maybe programmatically-generated ones?) to all happen at once, so that
> the amplitude goes way out of range - but it will take me some time to
> figure out what the problem there actually is, and it seems unrelated to
> brace repeats.  At least now (with a minor change to avoid using macro
> parameters in repeat counts) it compiles!
>
> -- 
> Matthew Skala
> mskala@ansuz.sooke.bc.ca                 People before tribes.
> https://ansuz.sooke.bc.ca/
>
> Csound mailing list
> Csound@listserv.heanet.ie
> https://listserv.heanet.ie/cgi-bin/wa?A0=CSOUND
> Send bugs reports to
>        https://github.com/csound/csound/issues
> Discussions of bugs and features can be posted here
>

Csound mailing list
Csound@listserv.heanet.ie
https://listserv.heanet.ie/cgi-bin/wa?A0=CSOUND
Send bugs reports to
        https://github.com/csound/csound/issues
Discussions of bugs and features can be posted here

I have just commited changes that allow macris in [...] in r statements. 
acros outside [..]woill work in very restricted contexts but are best 
avoided, at least until I have another burst of energy

==John ff

Csound mailing list
Csound@listserv.heanet.ie
https://listserv.heanet.ie/cgi-bin/wa?A0=CSOUND
Send bugs reports to
        https://github.com/csound/csound/issues
Discussions of bugs and features can be posted here

...whoops i meant brace loops not r-loops

Csound mailing list
Csound@listserv.heanet.ie
https://listserv.heanet.ie/cgi-bin/wa?A0=CSOUND
Send bugs reports to
        https://github.com/csound/csound/issues
Discussions of bugs and features can be posted here