Development of Csound has now moved to version 7.0. This means that
Csound 6 is now in maintenance mode.
Version 7.0 is in the develop branch and a new csound6 branch has
been created to produce 6.x updates to fix bugs until we release 7.0.
==John ffitch
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
wonderful!!!!!
very much looking forward to csound7, and happy to try anything once it is in the test state.
thanks for your work on it -
joachim
It builds and you can test it. There's a new parser in place already with several new possibilities.
We'll try to keep it building and running throughout development, although it may get broken from time to time.
Prof. Victor Lazzarini
Maynooth University
Ireland
and how can csound6 and csound7 be used in parallel?
i'd like to test, but when i have a concert i would prefer to play with csound6 ...
Maybe use a different CMAKE_INSTALL_PREFIX?
Prof. Victor Lazzarini
Maynooth University
Ireland
Or perhaps use a different Docker container for each version…
Thanks for this, I intend to build and test as soon as I have some time.
I have two related questions/requests (I haven't kept up with all the
new features in Csound for some time, so please excuse me if I'm way off
here):
1. Is it/would it be possible for envelope opcodes (envelope and
lineexp) to accept an array of values as input?
2. Is it/would it be possible to use an array as a p-field in the score?
Would those be viable requests for Csound7?
I have two related questions/requests (I haven't kept up with all the
new features in Csound for some time, so please excuse me if I'm way off
here):1. Is it/would it be possible for envelope opcodes (envelope and
lineexp) to accept an array of values as input?
I don't see why this can't be done right now, it would be just another overload of an opcode. We can do it any time. For example, ftgen has one such overload. Provided the list of parameters is of the same type, we can create a version with an array.
2. Is it/would it be possible to use an array as a p-field in the score?
This is not possible because the numeric score is a completely separate element, has a different syntax etc. We would first need to think of what an array would be in the score, and introduce that. There are no big plans for the numeric score.
However, as in 1., the schedule etc opcode could be developed to have an array overload.
Would those be viable requests for Csound7?
--
ljc <ljc@internet.com.uy>Csound mailing list
Csound@listserv.heanet.ie
LISTSERV 16.5 - CSOUND List at LISTSERV.HEANET.IE
Send bugs reports to
Error during processing.
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
> 1. Is it/would it be possible for envelope opcodes (envelope and
> lineexp) to accept an array of values as input?I don't see why this can't be done right now, it would be just
another overload of an opcode. We can do it any time.
That would be great, thanks!
> 2. Is it/would it be possible to use an array as a p-field in the
> score?This is not possible because the numeric score is a completely
separate element, has a different syntax etc.
I see.
However, as in 1., the schedule etc opcode could be developed to have
an array overload.
Yes, I can imagine that could be useful in some situations, but I assume
it wouldn't solve the issue. Or it would? I mean, you still couldn't
use an array as one (or more) of the p-fields within the array passed
to sched*, right?
On an indirectly related note: I assume that the limitation of no more
than one string per scoreline still holds, and that there are no plans
to change that, am I right?
Thanks for your attention.
That limitation was removed on 6.0 or even before.
With schedule, I presume the idea would be that you have the following form
iArr[] fillarray 1,0,1,0dbfs,A4
schedule(iArr)
Prof. Victor Lazzarini
Maynooth University
Ireland
Csound mailing list Send bugs reports to Discussions of bugs and features can be posted here
That’s a good idea. Something like that is planned to be part of the language now that the new parser is there. This is much easier to maintain and extend.
Prof. Victor Lazzarini
Maynooth University
Ireland
That limitation was removed on 6.0 or even before.
Really? That's great, I think the manual page should be updated
accordingly:
https://csound.com/docs/manual/ScoreStrings.html
With schedule, I presume the idea would be that you have the
following formiArr[] fillarray 1,0,1,0dbfs,A4
schedule(iArr)
Exactly, what I mean is that still you can't have an array in a p-field.
BTW, any pointers on how to convert a string with sub-strings separated
by a delimiter (for example, a coma) into an array of values?
In your previous example, how could I convert the string
"1,0,1,0dbfs,A4" into the array [1,0,1,0dbfs,A4]?
(Again, sorry if this is something I should know, but I've been out of
touch with Csound for some time..)
Yes, a long time ago. If it still says so in the
manual, it's been wrong for maybe ten years.
Prof. Victor Lazzarini
Maynooth University
Ireland
very much agreed. this feature is perhaps the one which i miss most in daily work with csound.
The implementation would be much safer if the ARRAYDAT structure would gain some metadata regarding memory ownership, because this approach will fail if an array which was de-referenced from another is placed again at the left side of an operation which might cause reallocation. Such a change would even be backwards compatible, since at the moment it is always assumed that an array owns its memory. It would just make things safer for future implementations which can mark such wrong usages as errors.
Another use case for such a flag would be the possibility of accessing tables as if they were scalar arrays by creating an array as an alias to a table, or to create an array as a slice of another one (for example, to iterate over rows of a 2d array), as implemented here:
Csound mailing list Send bugs reports to Discussions of bugs and features can be posted here
yes, that all sounds good. The use of tables as arrays and vice-versa should be transparent. We did something towards that in csound 6 and I think it can be built on.
Good discussion to have, but I think we could do it in the dev list instead of here.
Btw all but maybe a couple of the open tickets are enhancement requests for csound 7. There’s about 80 of them!
Prof. Victor Lazzarini
Maynooth University
Ireland