[Csnd] Csound 7 - a few comments

The Csound Mailinglist
1

Hello Csounders and developers,

I finally had a bit of time to test and study the new Csound 7 features and improvements. First of all, thank you to all developers and contributers who worked to keep our beloved ecosystem alive !

And of course, some new features and improvements were expected, and it’s great we can now fully use the Csound 6 functional syntax (for opcodes with several outputs). Also this message might list a few inconsistencies I have noticed, but I want to assure you I really enjoy the work that has been done. And of course, some of my thoughts may bring back some discussions I missed and be redundant.

My general concern is the introduction of several syntactical exceptions that would possibly deteriorate language consistency, while making it more complex/difficult to learn and read. Another general consideration : some of these exceptions come from the new type system : types in Csound can be data types specifications (Strings, Spectral representation…) or, initially, rate specifications (i k a). I tend to think than mixing those as the same thing can increase complexity of the langage and lead a lot of new users to be confused.

  • It is excellent that we now have a proper for loop, of which I enjoy the design, very flexible. One small question about this : why isn’t it possible to explicit the loop variable type in the loop like “for count:k in [0,1,2]” ?

  • I personnaly have nothing in favor neither against the introduction of boolean type. Though, it doesn’t come without questions : it is the only type where uppercase and lowercase determines if it is init time or performance time. It seems this decision is not even the same that the Complex type where brackets are used to specify if it is audio or control.

  • confusing, might let people think that strings with lowercase s (I know, it doesn’t exist) are i-rate while S is k-rate
  • Might have been “test:bi” or “test:bk” (as two separate types bi and bk)
  • The Complex type comes with a similar question and a few others.
  • It appears that the declaration “sig:Complex” works with control signals, while “sig:Complex[]” is for audio signals. I can’t remember of anywhere else where this kind of syntax is used in Csound ?
  • As mentionned before, the example of the manual shows that it is legal to define Complex numbers with an identical syntax as Faust parallel composition “sig:Complex[] = oscili(0.1, 100), oscili(0.1, 200)”. I personnaly enjoy this syntax. Though, it is not legal anywhere else. Could it be interesting to allow it for multiple declarations ? My opinion is that it would fit nicely the new feature allowing to use functional syntax with opcodes with multiple outputs. Since it is now legal to write “sig1:a, sig2:a = pan2(input, pan)”, why wouldn’t it be legal to write “sig1:a, sig2:a = oscili(0.1, 100), oscili(0.1, 110)” ?
  • Similarly to this last thought, enabling array definition when an opcode has multiple outputs of same type could be very handy : “sigs:a[] = hilbert(input_sig)”

  • Struct : they do not seem to work with audio signals (segfault). I guess it’s a but ? Though, I really appreciate this new feature ! Will be great with new UDO syntax.

  • Global syntax : I find it a bit long, and also introduces a new exceptional symbol : maxamp@global:i = 0dbfs / 5

  • An option would have been to combine new type syntax with old fashion global declaration
  • maxamp:gi = 0.2
  • Or to use only the @ symbol as a prefix for global declaration, in a similar way Ruby uses @ to declare member variables

  • @maxamp:i = 0.2

  • UDO new syntax : I like it. A few thoughts though :

  • The void keyword is new here, doesn’t even seem necessary (can be replaced with empty parenthesis), and has no other implication in the language (that I know of). Are we sure we need void at this point ?
  • For a UDO with one output, it seems legal to write output type with or without parenthesis. Though, if no output, we need to choose between empty parenthesis and void explicitely without parenthesis (doesn’t work if between parenthesis). It looks like a detail, but still it is another exception that might make it harder to learn and increases the potential errors when writing code.
  • Simpler void UDO syntax could be “opcode dosomething(arg:i) … endop”, assuming that without output declared, there is no output.

  • References to opcodes seems relevant to me for handling parallel signals. Though, I find it a bit verbose. A quick look at Faust syntax to handle parallell/sequential situations is inspiring. Something like “run( reson, lenarray(freq), src, freq, freq/7, 2)” that would handle the reference creation could be interesting for example. Though here I’m not sure if I miss some use cases.

  • More type name concerns

  • Opcode type : isn’t it dangerous that it is the same word than the reserved word opcode ? I mean, I know the parser won’t make mistakes. But conceptually, isn’t it another difficult thing that can confuse users ?
  • Instr type : same
  • Also, the Instr type represents an instance, not an instrument. Might be “Inst” type ? Or “Voice” ?

Finally, I’d like to mention that my tests were made with freshly built Csound 7 on Linux Mint here.
Thanks to all who worked hard to make this happen !

Best,

Johann PHILIPPE

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

2

I agree on the boolean type - uppercase/lowercase thing. I also find that a little odd.

3

Just a few clarifications

  • The Complex type comes with a similar question and a few others.
  • It appears that the declaration “sig:Complex” works with control signals, while “sig:Complex” is for audio signals. I can’t remember of anywhere else where this kind of syntax is used in Csound ?

That’s a misunderstanding. Complex is a scalar
and Complex is a vector. An a-type is also a vector but it is real-valued. A k is likewise a vector. Either can carry an audio signal. A Complex can carry an analytic signal.

Since it is now legal to write “sig1:a, sig2:a = pan2(input, pan)”, why wouldn’t it be legal to write “sig1:a, sig2:a = oscili(0.1, 100), oscili(0.1, 110)” ?

You can do that actually. For some reason, we had this for i and k but forgot about a. It’s now in a PR.

  • Similarly to this last thought, enabling array definition when an opcode has multiple outputs of same type could be very handy : “sigs:a = hilbert(input_sig)”

Some opcodes have this implemented like diskin. It’s just about making overloads of opcodes that handle it. We are happy to take PRs for that kind.

  • References to opcodes seems relevant to me for handling parallel signals. Though, I find it a bit verbose. A quick look at Faust syntax to handle parallell/sequential situations is inspiring. Something like “run( reson, lenarray(freq), src, freq, freq/7, 2)” that would handle the reference creation could be interesting for example. Though here I’m not sure if I miss some use cases.

There is an opcode definition type and opcode object type. The first can hold the definition of the opcode for which there might be loads of overloads - the second is the actual instantiated object of one of the overloads, which needs to be created from a definition. We don’t conflate the two.

best,

Victor

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

4

Those types were always there before, Steven and Hlodver just exposed them to users. You don’t need to use them explicitly if you find them confusing.

best

Prof. Victor Lazzarini
Maynooth University
Ireland

5

I like the idea of booleans, but could aliases be used for them to keep them inline with the more modern syntax? ki, bi perhaps?

6

bi, bk, didn’t get my coffee in this morning…

7

I actually prefer capitalising the first letter for long type names - Bool and Boolk, as done with other standard types, but yes that's more like it.

Prof. Victor Lazzarini
Maynooth University
Ireland

8

@Victor Lazzarini

Thanks for the clarifications. I’ll go throught it all, and also the questions you didn’t answer.

  • First about Complex : Great improvement to have complex maths in the language/engine natively. I understand what happens here, I guess you misunderstood my call. I mean, obviously, a k array of size ksmps is a vector, equivalent to an audio signal of type ‘a’. Very convenient.
    Though, it doesn’t answer to my call at all.
    It is important to understand I’m talking about semantics here. Any type made to an array can’t be a vector. We have the exact same inconsistency with the boolean : how to explain syntactically that the some types can be vectors (k), some other don’t ? And how to explicit that in a consistent way in the language ?
    ===> We have a major grammatical question here : how to merge historical types (i, k ,a) referring to stream timing with data structure types ? It is not the same thing at all. It is about to create a very big grammatical trouble. I am Csounder since almost 9 years, I want to promote it to all the communities I have access to. How can I promote such things ? It has to be thought as a language, not as a feature. Good languages do not admit many exceptions. What are we doing to merge data types with time types ? Semantically ? Grammatically ?

  • Second answer about parallel signals for multiple declaration/definition : very interesting to have this. Thanks.

  • Third answer about array type inference “sigs:a = hilbert(input_sig)” : I think you didn’t understand what I meant. Opcode overloads is not what I meant, although I know Csound enough to be aware of those overloads. I was talking about a language feature. I guess it would be a modification to both parser and engine to enable it natively : the language could assume that opcodes with several outputs with same type can be routed immediatly to an array of the proper type.

  • Answer about Opcodes (with a capital O) : it is very partial answer. I think it a big mislead to have a type called Opcode while it is actually a reference to an opcode (not an opcode at all finally, juste an OpcodeRef) and while there is a primitive called opcode : which is at the center of the language/engine. It is very dangerous semantically. Would you like to call Int (capital I) a reference to an int (lowercase i) ? Worst for Instr : which is actually an instance of an instrument, so here we have two problems : it is the same name as a primitive / reserved word, and it is not the correct name at all (it is an instance, not an instrument at all). Can we fix these names/type names easily ? I guess it woudn’t be too difficult ? Let’s do it immediatly if you are ok, I can do a PR for that.

And finally, about the questions without answers :

  • struct : not working with audio signals (at least on Linux) ? Can someone confirm ? (I admit I didn’t make tests since last time) > A bug ?
  • Void ? Is that a joke ? A feature ?
  • Global : why not a “global@myglobal:i:isglobal#GLOB = 1:global:i:isglobal#VERYGLOBAL” ? (Sorry, really joking on this one, I’m desperate that there is no answer on this)
  • UDO : with no output, what about not declaring output ? “opcode dosomething(arg:i) … endop” ? Would be amazing
  • Also about booleans : as I said, not in favor or against. I still don’t see any use case of it. Can’t we already do conditional things ? Are we in a C context where boolean can be optimization things ? Why are we adding this ?

In general, I think it would be time for all Csounders to talk about this. If we are at Beta stage (I guess it is more of an advanced Alpha), then it is time to talk !

Please, when I take time to write something about my feelings on the language, be aware that it is because I care about the future of it. And I still enjoy the work that has been done, much more than the last answer to my questions.

Thanks for reading

Best regards
Johann Philippe

bi and bk seem odd to me; bool and boolk seem better in-line with
other programming languages.

bi, bk, didn’t get my coffee in this morning…

ki?
Prof. Victor Lazzarini
Maynooth University
Ireland

I like the idea of booleans, but could aliases be used for them to keep them inline with the more modern syntax? ki, bi perhaps?

Those types were always there before, Steven and Hlodver just exposed them to users. You don’t need to use them explicitly if you find them confusing.

best
Prof. Victor Lazzarini
Maynooth University
Ireland

I agree on the boolean type - uppercase/lowercase thing. I also find that a little odd.

Hello Csounders and developers,

I finally had a bit of time to test and study the new Csound 7 features and improvements. First of all, thank you to all developers and contributers who worked to keep our beloved ecosystem alive !

And of course, some new features and improvements were expected, and it’s great we can now fully use the Csound 6 functional syntax (for opcodes with several outputs). Also this message might list a few inconsistencies I have noticed, but I want to assure you I really enjoy the work that has been done. And of course, some of my thoughts may bring back some discussions I missed and be redundant.

My general concern is the introduction of several syntactical exceptions that would possibly deteriorate language consistency, while making it more complex/difficult to learn and read. Another general consideration : some of these exceptions come from the new type system : types in Csound can be data types specifications (Strings, Spectral representation…) or, initially, rate specifications (i k a). I tend to think than mixing those as the same thing can increase complexity of the langage and lead a lot of new users to be confused.

  • It is excellent that we now have a proper for loop, of which I enjoy the design, very flexible. One small question about this : why isn’t it possible to explicit the loop variable type in the loop like “for count:k in [0,1,2]” ?

  • I personnaly have nothing in favor neither against the introduction of boolean type. Though, it doesn’t come without questions : it is the only type where uppercase and lowercase determines if it is init time or performance time. It seems this decision is not even the same that the Complex type where brackets are used to specify if it is audio or control.

  • confusing, might let people think that strings with lowercase s (I know, it doesn’t exist) are i-rate while S is k-rate
  • Might have been “test:bi” or “test:bk” (as two separate types bi and bk)
  • The Complex type comes with a similar question and a few others.
  • It appears that the declaration “sig:Complex” works with control signals, while “sig:Complex” is for audio signals. I can’t remember of anywhere else where this kind of syntax is used in Csound ?
  • As mentionned before, the example of the manual shows that it is legal to define Complex numbers with an identical syntax as Faust parallel composition “sig:Complex = oscili(0.1, 100), oscili(0.1, 200)”. I personnaly enjoy this syntax. Though, it is not legal anywhere else. Could it be interesting to allow it for multiple declarations ? My opinion is that it would fit nicely the new feature allowing to use functional syntax with opcodes with multiple outputs. Since it is now legal to write “sig1:a, sig2:a = pan2(input, pan)”, why wouldn’t it be legal to write “sig1:a, sig2:a = oscili(0.1, 100), oscili(0.1, 110)” ?
  • Similarly to this last thought, enabling array definition when an opcode has multiple outputs of same type could be very handy : “sigs:a = hilbert(input_sig)”

  • Struct : they do not seem to work with audio signals (segfault). I guess it’s a but ? Though, I really appreciate this new feature ! Will be great with new UDO syntax.

  • Global syntax : I find it a bit long, and also introduces a new exceptional symbol : maxamp@global:i = 0dbfs / 5

  • An option would have been to combine new type syntax with old fashion global declaration
  • maxamp:gi = 0.2
  • Or to use only the @ symbol as a prefix for global declaration, in a similar way Ruby uses @ to declare member variables

  • @maxamp:i = 0.2

  • UDO new syntax : I like it. A few thoughts though :

  • The void keyword is new here, doesn’t even seem necessary (can be replaced with empty parenthesis), and has no other implication in the language (that I know of). Are we sure we need void at this point ?
  • For a UDO with one output, it seems legal to write output type with or without parenthesis. Though, if no output, we need to choose between empty parenthesis and void explicitely without parenthesis (doesn’t work if between parenthesis). It looks like a detail, but still it is another exception that might make it harder to learn and increases the potential errors when writing code.
  • Simpler void UDO syntax could be “opcode dosomething(arg:i) … endop”, assuming that without output declared, there is no output.

  • References to opcodes seems relevant to me for handling parallel signals. Though, I find it a bit verbose. A quick look at Faust syntax to handle parallell/sequential situations is inspiring. Something like “run( reson, lenarray(freq), src, freq, freq/7, 2)” that would handle the reference creation could be interesting for example. Though here I’m not sure if I miss some use cases.

  • More type name concerns

  • Opcode type : isn’t it dangerous that it is the same word than the reserved word opcode ? I mean, I know the parser won’t make mistakes. But conceptually, isn’t it another difficult thing that can confuse users ?
  • Instr type : same
  • Also, the Instr type represents an instance, not an instrument. Might be “Inst” type ? Or “Voice” ?

Finally, I’d like to mention that my tests were made with freshly built Csound 7 on Linux Mint here.
Thanks to all who worked hard to make this happen !

Best,

Johann PHILIPPE

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

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

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

9

Dear all,

I fully agree with Johann here - both on the substance and on the spirit of his message. I feel that csound need to gain in clarity for pedagogy, and long-term maintainability (global variables, UDO void, …).

I understand Victor’s position regarding the upcoming 7 release, but at the same time, it would be valuable if developers could at least acknowledge and document these ideas, so they can be discussed and refined after 7.0 is out.

In short, we acknowledge some open discussion, but it’s too late to change things now. So yes, let’s freeze the code, but not the conversation.
Let’s keep gathering inputs; it can only be beneficial.
For exemple, great news for bool and boolk - I just discovered cs7 new uppercase and lowercase feature about boolean and personally I prefer by far this bi, bk or bool and boolk idea.

These observations and discussions are a treasure even if it’s too late. As a trusted user, I feel we should care more about these feedbacks rather than close it too quickly. Are they more an issue here? Only Victor takes the time to answer. Thank you for that.
Should we open a real thread on the forum about CS7, maybe?

jacopo (cooooordelia)

10

I don’t want to be hostile against void, as I see it is very relevant in C where it is fundamental to the language : explicit typing of functions without output, generic pointers. The C language has this in its DNA : all functions are explicitly typed, with only one output per function.
In Csound the context is a bit different : not limited to 1 output, so it can be a list of outputs, no use of opaque pointers… I would rather not indicate any type for an UDO that has no output. It seems as explicit as void to me, but shorter.
Perheaps at some point the compiler could make some kind of “void inference” for opcodes without explicit return type ? That might bring together our point of views.
It would allow three syntaxes “opcode myop(inarg:i):void”, “opcode op(inarg:i):()”, and “opcode op(inarg:i)”
Also, one question (maybe I didn’t see it) : will void used anywhere else in Csound 7 ?

About global, I actually just find it long (and weird to postfix global to variable name before the actual type).
There are be so many ways to make it shorter while keeping it as explicit as it is : “@var:i”, “var:gi”…

I also agree with Jacopo that it would be very interesting to discuss it further (Forum ?), discuss ideas for the future, and maybe to get some feedbacks about the design decisions. I know it’s been a long journey to make this version happen, so it would be fantastic to know a bit more about this journey. Thanks, again to all for this Csound 7 !

Best

Johann

I don’t understand the hostility over void keyword. It’s a well known
keyword in other languages to express the absence of a return value
and works with the declaration of an explicit type.

Regarding @global, you can look at the PR that introduced it for background:

https://github.com/csound/csound/pull/2017

I don’t love the @global syntax myself. On the other hand, python has
a ‘global’ modifier necessary to update global var from a function
such as:

myVal = 0

def incr():
global myVal
myVal += 1

@Victor Lazzarini

Thanks for the clarifications. I’ll go throught it all, and also the questions you didn’t answer.

  • First about Complex : Great improvement to have complex maths in the language/engine natively. I understand what happens here, I guess you misunderstood my call. I mean, obviously, a k array of size ksmps is a vector, equivalent to an audio signal of type ‘a’. Very convenient.
    Though, it doesn’t answer to my call at all.
    It is important to understand I’m talking about semantics here. Any type made to an array can’t be a vector. We have the exact same inconsistency with the boolean : how to explain syntactically that the some types can be vectors (k), some other don’t ? And how to explicit that in a consistent way in the language ?
    ===> We have a major grammatical question here : how to merge historical types (i, k ,a) referring to stream timing with data structure types ? It is not the same thing at all. It is about to create a very big grammatical trouble. I am Csounder since almost 9 years, I want to promote it to all the communities I have access to. How can I promote such things ? It has to be thought as a language, not as a feature. Good languages do not admit many exceptions. What are we doing to merge data types with time types ? Semantically ? Grammatically ?

  • Second answer about parallel signals for multiple declaration/definition : very interesting to have this. Thanks.

  • Third answer about array type inference “sigs:a = hilbert(input_sig)” : I think you didn’t understand what I meant. Opcode overloads is not what I meant, although I know Csound enough to be aware of those overloads. I was talking about a language feature. I guess it would be a modification to both parser and engine to enable it natively : the language could assume that opcodes with several outputs with same type can be routed immediatly to an array of the proper type.

  • Answer about Opcodes (with a capital O) : it is very partial answer. I think it a big mislead to have a type called Opcode while it is actually a reference to an opcode (not an opcode at all finally, juste an OpcodeRef) and while there is a primitive called opcode : which is at the center of the language/engine. It is very dangerous semantically. Would you like to call Int (capital I) a reference to an int (lowercase i) ? Worst for Instr : which is actually an instance of an instrument, so here we have two problems : it is the same name as a primitive / reserved word, and it is not the correct name at all (it is an instance, not an instrument at all). Can we fix these names/type names easily ? I guess it woudn’t be too difficult ? Let’s do it immediatly if you are ok, I can do a PR for that.

And finally, about the questions without answers :

  • struct : not working with audio signals (at least on Linux) ? Can someone confirm ? (I admit I didn’t make tests since last time) > A bug ?
  • Void ? Is that a joke ? A feature ?
  • Global : why not a “global@myglobal:i:isglobal#GLOB = 1:global:i:isglobal#VERYGLOBAL” ? (Sorry, really joking on this one, I’m desperate that there is no answer on this)
  • UDO : with no output, what about not declaring output ? “opcode dosomething(arg:i) … endop” ? Would be amazing
  • Also about booleans : as I said, not in favor or against. I still don’t see any use case of it. Can’t we already do conditional things ? Are we in a C context where boolean can be optimization things ? Why are we adding this ?

In general, I think it would be time for all Csounders to talk about this. If we are at Beta stage (I guess it is more of an advanced Alpha), then it is time to talk !

Please, when I take time to write something about my feelings on the language, be aware that it is because I care about the future of it. And I still enjoy the work that has been done, much more than the last answer to my questions.

Thanks for reading

Best regards
Johann Philippe

bi and bk seem odd to me; bool and boolk seem better in-line with
other programming languages.

bi, bk, didn’t get my coffee in this morning…

ki?
Prof. Victor Lazzarini
Maynooth University
Ireland

I like the idea of booleans, but could aliases be used for them to keep them inline with the more modern syntax? ki, bi perhaps?

Those types were always there before, Steven and Hlodver just exposed them to users. You don’t need to use them explicitly if you find them confusing.

best
Prof. Victor Lazzarini
Maynooth University
Ireland

I agree on the boolean type - uppercase/lowercase thing. I also find that a little odd.

Hello Csounders and developers,

I finally had a bit of time to test and study the new Csound 7 features and improvements. First of all, thank you to all developers and contributers who worked to keep our beloved ecosystem alive !

And of course, some new features and improvements were expected, and it’s great we can now fully use the Csound 6 functional syntax (for opcodes with several outputs). Also this message might list a few inconsistencies I have noticed, but I want to assure you I really enjoy the work that has been done. And of course, some of my thoughts may bring back some discussions I missed and be redundant.

My general concern is the introduction of several syntactical exceptions that would possibly deteriorate language consistency, while making it more complex/difficult to learn and read. Another general consideration : some of these exceptions come from the new type system : types in Csound can be data types specifications (Strings, Spectral representation…) or, initially, rate specifications (i k a). I tend to think than mixing those as the same thing can increase complexity of the langage and lead a lot of new users to be confused.

  • It is excellent that we now have a proper for loop, of which I enjoy the design, very flexible. One small question about this : why isn’t it possible to explicit the loop variable type in the loop like “for count:k in [0,1,2]” ?

  • I personnaly have nothing in favor neither against the introduction of boolean type. Though, it doesn’t come without questions : it is the only type where uppercase and lowercase determines if it is init time or performance time. It seems this decision is not even the same that the Complex type where brackets are used to specify if it is audio or control.

  • confusing, might let people think that strings with lowercase s (I know, it doesn’t exist) are i-rate while S is k-rate
  • Might have been “test:bi” or “test:bk” (as two separate types bi and bk)
  • The Complex type comes with a similar question and a few others.
  • It appears that the declaration “sig:Complex” works with control signals, while “sig:Complex” is for audio signals. I can’t remember of anywhere else where this kind of syntax is used in Csound ?
  • As mentionned before, the example of the manual shows that it is legal to define Complex numbers with an identical syntax as Faust parallel composition “sig:Complex = oscili(0.1, 100), oscili(0.1, 200)”. I personnaly enjoy this syntax. Though, it is not legal anywhere else. Could it be interesting to allow it for multiple declarations ? My opinion is that it would fit nicely the new feature allowing to use functional syntax with opcodes with multiple outputs. Since it is now legal to write “sig1:a, sig2:a = pan2(input, pan)”, why wouldn’t it be legal to write “sig1:a, sig2:a = oscili(0.1, 100), oscili(0.1, 110)” ?
  • Similarly to this last thought, enabling array definition when an opcode has multiple outputs of same type could be very handy : “sigs:a = hilbert(input_sig)”

  • Struct : they do not seem to work with audio signals (segfault). I guess it’s a but ? Though, I really appreciate this new feature ! Will be great with new UDO syntax.

  • Global syntax : I find it a bit long, and also introduces a new exceptional symbol : maxamp@global:i = 0dbfs / 5

  • An option would have been to combine new type syntax with old fashion global declaration
  • maxamp:gi = 0.2
  • Or to use only the @ symbol as a prefix for global declaration, in a similar way Ruby uses @ to declare member variables

  • @maxamp:i = 0.2

  • UDO new syntax : I like it. A few thoughts though :

  • The void keyword is new here, doesn’t even seem necessary (can be replaced with empty parenthesis), and has no other implication in the language (that I know of). Are we sure we need void at this point ?
  • For a UDO with one output, it seems legal to write output type with or without parenthesis. Though, if no output, we need to choose between empty parenthesis and void explicitely without parenthesis (doesn’t work if between parenthesis). It looks like a detail, but still it is another exception that might make it harder to learn and increases the potential errors when writing code.
  • Simpler void UDO syntax could be “opcode dosomething(arg:i) … endop”, assuming that without output declared, there is no output.

  • References to opcodes seems relevant to me for handling parallel signals. Though, I find it a bit verbose. A quick look at Faust syntax to handle parallell/sequential situations is inspiring. Something like “run( reson, lenarray(freq), src, freq, freq/7, 2)” that would handle the reference creation could be interesting for example. Though here I’m not sure if I miss some use cases.

  • More type name concerns

  • Opcode type : isn’t it dangerous that it is the same word than the reserved word opcode ? I mean, I know the parser won’t make mistakes. But conceptually, isn’t it another difficult thing that can confuse users ?
  • Instr type : same
  • Also, the Instr type represents an instance, not an instrument. Might be “Inst” type ? Or “Voice” ?

Finally, I’d like to mention that my tests were made with freshly built Csound 7 on Linux Mint here.
Thanks to all who worked hard to make this happen !

Best,

Johann PHILIPPE

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

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

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

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