[Csnd] Csound 7 - a few comments

[Csnd] Csound 7 - a few comments

Date	2025-10-05 15:04
From	Johann Philippe <000002c2c0737523-dmarc-request@LISTSERV.HEANET.IE>
Subject	[Csnd] Csound 7 - a few comments
	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

Date	2025-10-05 15:21
From	Rory Walsh
Subject	Re: [Csnd] Csound 7 - a few comments
	I agree on the boolean type - uppercase/lowercase thing. I also find that a little odd. On Sun, 5 Oct 2025 at 15:07, Johann Philippe <000002c2c0737523-dmarc-request@listserv.heanet.ie> wrote: 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

Date	2025-10-05 20:32
From	Victor Lazzarini <000010b17ddd988e-dmarc-request@LISTSERV.HEANET.IE>
Subject	Re: [Csnd] Csound 7 - a few comments
	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

Date	2025-10-05 20:36
From	Victor Lazzarini <000010b17ddd988e-dmarc-request@LISTSERV.HEANET.IE>
Subject	Re: [Csnd] Csound 7 - a few comments
	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 On 5 Oct 2025, at 15:23, Rory Walsh <rorywalsh@ear.ie> wrote: I agree on the boolean type - uppercase/lowercase thing. I also find that a little odd. On Sun, 5 Oct 2025 at 15:07, Johann Philippe <000002c2c0737523-dmarc-request@listserv.heanet.ie> wrote: 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

Date	2025-10-06 10:25
From	Rory Walsh
Subject	Re: [Csnd] Csound 7 - a few comments
	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? On Sun, 5 Oct 2025 at 20:36, Victor Lazzarini <000010b17ddd988e-dmarc-request@listserv.heanet.ie> wrote: 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 On 5 Oct 2025, at 15:23, Rory Walsh <rorywalsh@ear.ie> wrote: I agree on the boolean type - uppercase/lowercase thing. I also find that a little odd. On Sun, 5 Oct 2025 at 15:07, Johann Philippe <000002c2c0737523-dmarc-request@listserv.heanet.ie> wrote: 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

Date	2025-10-06 11:03
From	vlz
Subject	Re: [Csnd] Csound 7 - a few comments
	ki? Prof. Victor Lazzarini Maynooth University Ireland On 6 Oct 2025, at 10:25, Rory Walsh <rorywalsh@ear.ie> wrote: 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? On Sun, 5 Oct 2025 at 20:36, Victor Lazzarini <000010b17ddd988e-dmarc-request@listserv.heanet.ie> wrote: 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 On 5 Oct 2025, at 15:23, Rory Walsh <rorywalsh@ear.ie> wrote: I agree on the boolean type - uppercase/lowercase thing. I also find that a little odd. On Sun, 5 Oct 2025 at 15:07, Johann Philippe <000002c2c0737523-dmarc-request@listserv.heanet.ie> wrote: 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

Date	2025-10-06 11:11
From	Rory Walsh
Subject	Re: [Csnd] Csound 7 - a few comments
	bi, bk, didn't get my coffee in this morning... On Mon, 6 Oct 2025 at 11:08, vlz <viclazzarini@gmail.com> wrote: ki? Prof. Victor Lazzarini Maynooth University Ireland On 6 Oct 2025, at 10:25, Rory Walsh <rorywalsh@ear.ie> wrote: 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? On Sun, 5 Oct 2025 at 20:36, Victor Lazzarini <000010b17ddd988e-dmarc-request@listserv.heanet.ie> wrote: 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 On 5 Oct 2025, at 15:23, Rory Walsh <rorywalsh@ear.ie> wrote: I agree on the boolean type - uppercase/lowercase thing. I also find that a little odd. On Sun, 5 Oct 2025 at 15:07, Johann Philippe <000002c2c0737523-dmarc-request@listserv.heanet.ie> wrote: 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

Date	2025-10-09 16:25
From	Steven Yi
Subject	Re: [Csnd] Csound 7 - a few comments
	bi and bk seem odd to me; bool and boolk seem better in-line with other programming languages. On Mon, Oct 6, 2025 at 6:12 AM Rory Walsh wrote: > > bi, bk, didn't get my coffee in this morning... > > On Mon, 6 Oct 2025 at 11:08, vlz wrote: >> >> ki? >> Prof. Victor Lazzarini >> Maynooth University >> Ireland >> >> On 6 Oct 2025, at 10:25, Rory Walsh wrote: >> >> >> 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? >> >> On Sun, 5 Oct 2025 at 20:36, Victor Lazzarini <000010b17ddd988e-dmarc-request@listserv.heanet.ie> wrote: >>> >>> 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 >>> >>> On 5 Oct 2025, at 15:23, Rory Walsh wrote: >>> >>> >>> I agree on the boolean type - uppercase/lowercase thing. I also find that a little odd. >>> >>> On Sun, 5 Oct 2025 at 15:07, Johann Philippe <000002c2c0737523-dmarc-request@listserv.heanet.ie> wrote: >>>> >>>> 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

Date	2025-10-09 16:51
From	Victor Lazzarini <000010b17ddd988e-dmarc-request@LISTSERV.HEANET.IE>
Subject	Re: [Csnd] [EXTERNAL] Re: [Csnd] Csound 7 - a few comments
	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 > On 9 Oct 2025, at 16:25, Steven Yi wrote: > > Warning > > This email originated from outside of Maynooth University's Mail System. Do not reply, click links or open attachments unless you recognise the sender and know the content is safe. > > bi and bk seem odd to me; bool and boolk seem better in-line with > other programming languages. > >> On Mon, Oct 6, 2025 at 6:12 AM Rory Walsh wrote: >> >> bi, bk, didn't get my coffee in this morning... >> >>> On Mon, 6 Oct 2025 at 11:08, vlz wrote: >>> >>> ki? >>> Prof. Victor Lazzarini >>> Maynooth University >>> Ireland >>> >>>> On 6 Oct 2025, at 10:25, Rory Walsh wrote: >>> >>> >>> 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? >>> >>> On Sun, 5 Oct 2025 at 20:36, Victor Lazzarini <000010b17ddd988e-dmarc-request@listserv.heanet.ie> wrote: >>>> >>>> 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 >>>> >>>> On 5 Oct 2025, at 15:23, Rory Walsh wrote: >>>> >>>> >>>> I agree on the boolean type - uppercase/lowercase thing. I also find that a little odd. >>>> >>>> On Sun, 5 Oct 2025 at 15:07, Johann Philippe <000002c2c0737523-dmarc-request@listserv.heanet.ie> wrote: >>>>> >>>>> 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

Date	2025-10-10 17:37
From	Johann Philippe <000002c2c0737523-dmarc-request@LISTSERV.HEANET.IE>
Subject	Re: [Csnd] Csound 7 - a few comments
	@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 Le jeudi 9 octobre 2025 à 17:25:41 UTC+2, Steven Yi <stevenyi@gmail.com> a écrit : bi and bk seem odd to me; bool and boolk seem better in-line with other programming languages. On Mon, Oct 6, 2025 at 6:12 AM Rory Walsh <rorywalsh@ear.ie> wrote: > > bi, bk, didn't get my coffee in this morning... > > On Mon, 6 Oct 2025 at 11:08, vlz <viclazzarini@gmail.com> wrote: >> >> ki? >> Prof. Victor Lazzarini >> Maynooth University >> Ireland >> >> On 6 Oct 2025, at 10:25, Rory Walsh <rorywalsh@ear.ie> wrote: >> >> >> 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? >> >> On Sun, 5 Oct 2025 at 20:36, Victor Lazzarini <000010b17ddd988e-dmarc-request@listserv.heanet.ie> wrote: >>> >>> 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 >>> >>> On 5 Oct 2025, at 15:23, Rory Walsh <rorywalsh@ear.ie> wrote: >>> >>> >>> I agree on the boolean type - uppercase/lowercase thing. I also find that a little odd. >>> >>> On Sun, 5 Oct 2025 at 15:07, Johann Philippe <000002c2c0737523-dmarc-request@listserv.heanet.ie> wrote: >>>> >>>> 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

Date	2025-10-10 17:55
From	vlz
Subject	Re: [Csnd] Csound 7 - a few comments
	- All types can be vectors - you can have arrays of any type. - i, k, a are just three of several standard types. There is no merging, they work in the same way as they always did. All types have either i or perf behaviour, or both. For each type, this is very clearly defined. - It is not possible to route different types into a single array output, because arrays are typed. - Opcode does not hold a reference to an opcode, it holds an opcode object. We have had this discussion a while ago and settled on the type names. We are not changing any of this at this stage. Others may comment, but I will say this: we are near releasing 7.0, and as far as I am concerned I am not prepared to go through major changes in the language or the engine now. We have had a long haul developing this version and now we are almost ready. The time for any changes of the kind you propose is passed now. The other questions might be answered more thoroughly by other developers as they fall in their areas. best Prof. Victor Lazzarini Maynooth University Ireland On 10 Oct 2025, at 17:37, Johann Philippe <000002c2c0737523-dmarc-request@listserv.heanet.ie> wrote: @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 Le jeudi 9 octobre 2025 à 17:25:41 UTC+2, Steven Yi <stevenyi@gmail.com> a écrit : bi and bk seem odd to me; bool and boolk seem better in-line with other programming languages. On Mon, Oct 6, 2025 at 6:12 AM Rory Walsh <rorywalsh@ear.ie> wrote: > > bi, bk, didn't get my coffee in this morning... > > On Mon, 6 Oct 2025 at 11:08, vlz <viclazzarini@gmail.com> wrote: >> >> ki? >> Prof. Victor Lazzarini >> Maynooth University >> Ireland >> >> On 6 Oct 2025, at 10:25, Rory Walsh <rorywalsh@ear.ie> wrote: >> >> >> 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? >> >> On Sun, 5 Oct 2025 at 20:36, Victor Lazzarini <000010b17ddd988e-dmarc-request@listserv.heanet.ie> wrote: >>> >>> 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 >>> >>> On 5 Oct 2025, at 15:23, Rory Walsh <rorywalsh@ear.ie> wrote: >>> >>> >>> I agree on the boolean type - uppercase/lowercase thing. I also find that a little odd. >>> >>> On Sun, 5 Oct 2025 at 15:07, Johann Philippe <000002c2c0737523-dmarc-request@listserv.heanet.ie> wrote: >>>> >>>> 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

Date	2025-10-11 11:40
From	SUBSCRIBE CSOUND Anonymous <00000c641a512f08-dmarc-request@LISTSERV.HEANET.IE>
Subject	[Csnd] [SPAM Warning!]Re: [Csnd] Csound 7 - a few comments
	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) On 10 Oct 2025, at 18:55, vlz <viclazzarini@GMAIL.COM> wrote: - All types can be vectors - you can have arrays of any type. - i, k, a are just three of several standard types. There is no merging, they work in the same way as they always did. All types have either i or perf behaviour, or both. For each type, this is very clearly defined. - It is not possible to route different types into a single array output, because arrays are typed. - Opcode does not hold a reference to an opcode, it holds an opcode object. We have had this discussion a while ago and settled on the type names. We are not changing any of this at this stage. Others may comment, but I will say this: we are near releasing 7.0, and as far as I am concerned I am not prepared to go through major changes in the language or the engine now. We have had a long haul developing this version and now we are almost ready. The time for any changes of the kind you propose is passed now. The other questions might be answered more thoroughly by other developers as they fall in their areas. best Prof. Victor Lazzarini Maynooth University Ireland On 10 Oct 2025, at 17:37, Johann Philippe <000002c2c0737523-dmarc-request@listserv.heanet.ie> wrote: @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 Le jeudi 9 octobre 2025 à 17:25:41 UTC+2, Steven Yi <stevenyi@gmail.com> a écrit : bi and bk seem odd to me; bool and boolk seem better in-line with other programming languages. On Mon, Oct 6, 2025 at 6:12 AM Rory Walsh <rorywalsh@ear.ie> wrote: > > bi, bk, didn't get my coffee in this morning... > > On Mon, 6 Oct 2025 at 11:08, vlz <viclazzarini@gmail.com> wrote: >> >> ki? >> Prof. Victor Lazzarini >> Maynooth University >> Ireland >> >> On 6 Oct 2025, at 10:25, Rory Walsh <rorywalsh@ear.ie> wrote: >> >> >> 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? >> >> On Sun, 5 Oct 2025 at 20:36, Victor Lazzarini <000010b17ddd988e-dmarc-request@listserv.heanet.ie> wrote: >>> >>> 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 >>> >>> On 5 Oct 2025, at 15:23, Rory Walsh <rorywalsh@ear.ie> wrote: >>> >>> >>> I agree on the boolean type - uppercase/lowercase thing. I also find that a little odd. >>> >>> On Sun, 5 Oct 2025 at 15:07, Johann Philippe <000002c2c0737523-dmarc-request@listserv.heanet.ie> wrote: >>>> >>>> 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