I generally prefer snake_case myself these days for Csound coding.
Perhaps it's because my brain switches somewhat to C conventions when
I get to time with Csound. Some of the coding in Csound for snake_case
has to do with the lack of namespaces and import system, so families
of code are denoted with things like zdf_ladder, zdf_2pole, etc. which
might be implemented as zdf::ladder or zdf::2pole in other languages.

On Fri, Oct 31, 2025 at 9:36 AM Rory Walsh  wrote:
>
> I agree that they are more readable, but I think switching to lowerCamelCase or snake_case would be a huge undertaking. I'm interested to hear what others think.
>
> On Fri, 31 Oct 2025 at 11:30, Dave Seidel  wrote:
>>
>> As a user, more consistency in naming would be very nice. I don't have a strong preference for any particular form, having had to adapt to all of them at one time or another over the course of my erstwhile career, but I guess I have somewhat of a reference for either lowerCamelCase or snake_case, as both offer better readability (IMO) than flatcase.
>>
>> - Dave
>>
>> On Fri, Oct 31, 2025 at 5:47 AM Rory Walsh  wrote:
>>>
>>> It would be nice to iron out some inconsistencies in the language before releasing Csound 7. One of these is the scattershot approach to opcode names. Right now we have lowerCamelCase, snake_case, snake+camel case, and the traditional flatcase. It would be nice to choose one, create aliases for all existing opcodes (if this is doable that is), and mark the others as deprecated.
>>>
>>> Another thing that came up yesterday in a different discussion is the number of version 2 opcodes, diskin2, flooper2, etc. We can now easily overload opcodes, which gives us the option of removing the version 2 variants and overloading the originals instead, although we’d need to audit the opcodes first to see if they all have different parameter signatures.
>>>
>>> Something else that was mentioned was the use of uppercase for booleans. bi, bk, booli, boolk, etc., all seem like better fits. Another long-standing inconsistency is the uppercase S for strings. If I’m not mistaken, we could finally change this to :s and keep it in line with other variable types.
>>>
>>> Consistency has a real impact on usability and teaching, making code easier to read and maintain. I think it would be great to try to address this now. I don't mind doing most of the donkey work. We just need to come to some kind of agreement.
>>>
>>> Rory.
>>>
>>>
>>> p.s. I'm posting this to the dev-list, but I think this is something the end-users might also like to have some input on...

i totally agree with rory about the importance of such a cleanup.
as to lowercase or snake_case, i'd say:
- in most cases we can keep lowercase
- if the readability is hurted, underscores can be added.

for instance: ampdb, mtof, bformenc, butbp, pvsynth are good.
osclisten even is ok, i think.

just to note that for the german keyboard the underscore is not as 
elegant as for the english one.

On 31/10/2025 16:46, Steven Yi wrote:
> I generally prefer snake_case myself these days for Csound coding.
> Perhaps it's because my brain switches somewhat to C conventions when
> I get to time with Csound. Some of the coding in Csound for snake_case
> has to do with the lack of namespaces and import system, so families
> of code are denoted with things like zdf_ladder, zdf_2pole, etc. which
> might be implemented as zdf::ladder or zdf::2pole in other languages.
> 
> On Fri, Oct 31, 2025 at 9:36 AM Rory Walsh  wrote:
>>
>> I agree that they are more readable, but I think switching to lowerCamelCase or snake_case would be a huge undertaking. I'm interested to hear what others think.
>>
>> On Fri, 31 Oct 2025 at 11:30, Dave Seidel  wrote:
>>>
>>> As a user, more consistency in naming would be very nice. I don't have a strong preference for any particular form, having had to adapt to all of them at one time or another over the course of my erstwhile career, but I guess I have somewhat of a reference for either lowerCamelCase or snake_case, as both offer better readability (IMO) than flatcase.
>>>
>>> - Dave
>>>
>>> On Fri, Oct 31, 2025 at 5:47 AM Rory Walsh  wrote:
>>>>
>>>> It would be nice to iron out some inconsistencies in the language before releasing Csound 7. One of these is the scattershot approach to opcode names. Right now we have lowerCamelCase, snake_case, snake+camel case, and the traditional flatcase. It would be nice to choose one, create aliases for all existing opcodes (if this is doable that is), and mark the others as deprecated.
>>>>
>>>> Another thing that came up yesterday in a different discussion is the number of version 2 opcodes, diskin2, flooper2, etc. We can now easily overload opcodes, which gives us the option of removing the version 2 variants and overloading the originals instead, although we’d need to audit the opcodes first to see if they all have different parameter signatures.
>>>>
>>>> Something else that was mentioned was the use of uppercase for booleans. bi, bk, booli, boolk, etc., all seem like better fits. Another long-standing inconsistency is the uppercase S for strings. If I’m not mistaken, we could finally change this to :s and keep it in line with other variable types.
>>>>
>>>> Consistency has a real impact on usability and teaching, making code easier to read and maintain. I think it would be great to try to address this now. I don't mind doing most of the donkey work. We just need to come to some kind of agreement.
>>>>
>>>> Rory.
>>>>
>>>>
>>>> p.s. I'm posting this to the dev-list, but I think this is something the end-users might also like to have some input on...

plus one for what you say about tipping the hat ... =)

On 31/10/2025 23:53, Rory Walsh wrote:
> We also have shedkwhen and ftsamplebank, which are also ok, I think. I 
> think if we introduce snake case, or any other convention, we need to go 
> all in. Snake case should add an underscore between each word. Following 
> such a scheme would lead to hundreds of opcodes being renamed, e.g., 
> ft_len, butter_lp, moog_ladder, pd_half, etc. I'm not against it, but I 
> think it must be a complete buy in. Otherwise we end up with a slightly 
> better system, but one that retains some strange inconsistencies.
> 
> I have to tip my hat to the core developers at this stage. This 
> conversation wouldn't be happening if they hadn't spent so much time 
> cleaning up the core system and updating/rewriting the parser. It's a 
> great place we are in now! ☺️
> 
> On Fri 31 Oct 2025, 17:17 joachim heintz,  > wrote:
> 
>     i totally agree with rory about the importance of such a cleanup.
>     as to lowercase or snake_case, i'd say:
>     - in most cases we can keep lowercase
>     - if the readability is hurted, underscores can be added.
> 
>     for instance: ampdb, mtof, bformenc, butbp, pvsynth are good.
>     osclisten even is ok, i think.
> 
>     just to note that for the german keyboard the underscore is not as
>     elegant as for the english one.
> 
>     On 31/10/2025 16:46, Steven Yi wrote:
>      > I generally prefer snake_case myself these days for Csound coding.
>      > Perhaps it's because my brain switches somewhat to C conventions when
>      > I get to time with Csound. Some of the coding in Csound for
>     snake_case
>      > has to do with the lack of namespaces and import system, so families
>      > of code are denoted with things like zdf_ladder, zdf_2pole, etc.
>     which
>      > might be implemented as zdf::ladder or zdf::2pole in other languages.
>      >
>      > On Fri, Oct 31, 2025 at 9:36 AM Rory Walsh      > wrote:
>      >>
>      >> I agree that they are more readable, but I think switching to
>     lowerCamelCase or snake_case would be a huge undertaking. I'm
>     interested to hear what others think.
>      >>
>      >> On Fri, 31 Oct 2025 at 11:30, Dave Seidel      > wrote:
>      >>>
>      >>> As a user, more consistency in naming would be very nice. I
>     don't have a strong preference for any particular form, having had
>     to adapt to all of them at one time or another over the course of my
>     erstwhile career, but I guess I have somewhat of a reference for
>     either lowerCamelCase or snake_case, as both offer better
>     readability (IMO) than flatcase.
>      >>>
>      >>> - Dave
>      >>>
>      >>> On Fri, Oct 31, 2025 at 5:47 AM Rory Walsh      > wrote:
>      >>>>
>      >>>> It would be nice to iron out some inconsistencies in the
>     language before releasing Csound 7. One of these is the scattershot
>     approach to opcode names. Right now we have lowerCamelCase,
>     snake_case, snake+camel case, and the traditional flatcase. It would
>     be nice to choose one, create aliases for all existing opcodes (if
>     this is doable that is), and mark the others as deprecated.
>      >>>>
>      >>>> Another thing that came up yesterday in a different discussion
>     is the number of version 2 opcodes, diskin2, flooper2, etc. We can
>     now easily overload opcodes, which gives us the option of removing
>     the version 2 variants and overloading the originals instead,
>     although we’d need to audit the opcodes first to see if they all
>     have different parameter signatures.
>      >>>>
>      >>>> Something else that was mentioned was the use of uppercase for
>     booleans. bi, bk, booli, boolk, etc., all seem like better fits.
>     Another long-standing inconsistency is the uppercase S for strings.
>     If I’m not mistaken, we could finally change this to :s and keep it
>     in line with other variable types.
>      >>>>
>      >>>> Consistency has a real impact on usability and teaching,
>     making code easier to read and maintain. I think it would be great
>     to try to address this now. I don't mind doing most of the donkey
>     work. We just need to come to some kind of agreement.
>      >>>>
>      >>>> Rory.
>      >>>>
>      >>>>
>      >>>> p.s. I'm posting this to the dev-list, but I think this is
>     something the end-users might also like to have some input on...
> 

I'm wary of ZDF1pole, as I'd rather see capitalized identifiers for
data types and lower-case ones for opcodes.

On Tue, Nov 4, 2025 at 7:23 AM Rory Walsh  wrote:
>
> Below is a list of opcode names that are not strictly flatten case. I propose the following:
>
> - the ATS, K35, OSC one remain.
> - the zdf opcodes join the aforementioned ones can also use uppercase, e.g, ZDF1pole
> - all other opcodes become flattened case, e.g. arduinoreadf, serialwritei, turnoff2_i
>
> Does this sound Ok? If so I will start creating aliases. I can also make a PR for the manual so we can reduce people's exposure to the old inconsistencies.
>
> ATSadd
>
> ATSaddnz
>
> ATSbufread
>
> ATScross
>
> ATSinfo
>
> ATSinterpread
>
> ATSpartialtap
>
> ATSread
>
> ATSreadnz
>
> ATSsinnoi
>
> K35_hpf
>
> K35_lpf
>
> MixerClear
>
> MixerGetLevel
>
> MixerReceive
>
> MixerSend
>
> MixerSetLevel
>
> MixerSetLevel_i
>
> OSCbundle
>
> OSCcount
>
> OSCinit
>
> OSCinitM
>
> OSClisten
>
> OSCraw
>
> OSCsend
>
> OSCsend_lo
>
> S
>
> arduinoRead
>
> arduinoReadF
>
> arduinoStart
>
> arduinoStop
>
> chn_S
>
> chn_a
>
> chn_k
>
> cntCreate
>
> cntCycles
>
> cntDelete
>
> cntDelete_i
>
> cntRead
>
> cntReset
>
> cntState
>
> count_i
>
> diode_ladder
>
> event_i
>
> genarray_i
>
> loop_ge
>
> loop_gt
>
> loop_le
>
> loop_lt
>
> maparray_i
>
> max_k
>
> midiout_i
>
> nchnls_hw
>
> print_type
>
> printf_i
>
> sc_lag
>
> sc_lagud
>
> sc_phasor
>
> sc_trig
>
> scoreline_i
>
> serialBegin
>
> serialEnd
>
> serialFlush
>
> serialPrint
>
> serialRead
>
> serialWrite
>
> serialWrite_i
>
> slicearray_i
>
> sliderKawai
>
> system_i
>
> tab_i
>
> tabw_i
>
> trigExpseg
>
> trigLinseg
>
> trim_i
>
> turnoff2_i
>
> vadd_i
>
> vaddv_i
>
> vcopy_i
>
> vdel_k
>
> vdivv_i
>
> vexp_i
>
> vexpv_i
>
> vmult_i
>
> vmultv_i
>
> vpow_i
>
> vpowv_i
>
> vsubv_i
>
> zdf_1pole
>
> zdf_1pole_mode
>
> zdf_2pole
>
> zdf_2pole_mode
>
> zdf_ladder
>
>
> On Sun, 2 Nov 2025 at 11:29, joachim heintz  wrote:
>>
>> plus one for what you say about tipping the hat ... =)
>>
>> On 31/10/2025 23:53, Rory Walsh wrote:
>> > We also have shedkwhen and ftsamplebank, which are also ok, I think. I
>> > think if we introduce snake case, or any other convention, we need to go
>> > all in. Snake case should add an underscore between each word. Following
>> > such a scheme would lead to hundreds of opcodes being renamed, e.g.,
>> > ft_len, butter_lp, moog_ladder, pd_half, etc. I'm not against it, but I
>> > think it must be a complete buy in. Otherwise we end up with a slightly
>> > better system, but one that retains some strange inconsistencies.
>> >
>> > I have to tip my hat to the core developers at this stage. This
>> > conversation wouldn't be happening if they hadn't spent so much time
>> > cleaning up the core system and updating/rewriting the parser. It's a
>> > great place we are in now! ☺️
>> >
>> > On Fri 31 Oct 2025, 17:17 joachim heintz, > > > wrote:
>> >
>> >     i totally agree with rory about the importance of such a cleanup.
>> >     as to lowercase or snake_case, i'd say:
>> >     - in most cases we can keep lowercase
>> >     - if the readability is hurted, underscores can be added.
>> >
>> >     for instance: ampdb, mtof, bformenc, butbp, pvsynth are good.
>> >     osclisten even is ok, i think.
>> >
>> >     just to note that for the german keyboard the underscore is not as
>> >     elegant as for the english one.
>> >
>> >     On 31/10/2025 16:46, Steven Yi wrote:
>> >      > I generally prefer snake_case myself these days for Csound coding.
>> >      > Perhaps it's because my brain switches somewhat to C conventions when
>> >      > I get to time with Csound. Some of the coding in Csound for
>> >     snake_case
>> >      > has to do with the lack of namespaces and import system, so families
>> >      > of code are denoted with things like zdf_ladder, zdf_2pole, etc.
>> >     which
>> >      > might be implemented as zdf::ladder or zdf::2pole in other languages.
>> >      >
>> >      > On Fri, Oct 31, 2025 at 9:36 AM Rory Walsh > >     > wrote:
>> >      >>
>> >      >> I agree that they are more readable, but I think switching to
>> >     lowerCamelCase or snake_case would be a huge undertaking. I'm
>> >     interested to hear what others think.
>> >      >>
>> >      >> On Fri, 31 Oct 2025 at 11:30, Dave Seidel > >     > wrote:
>> >      >>>
>> >      >>> As a user, more consistency in naming would be very nice. I
>> >     don't have a strong preference for any particular form, having had
>> >     to adapt to all of them at one time or another over the course of my
>> >     erstwhile career, but I guess I have somewhat of a reference for
>> >     either lowerCamelCase or snake_case, as both offer better
>> >     readability (IMO) than flatcase.
>> >      >>>
>> >      >>> - Dave
>> >      >>>
>> >      >>> On Fri, Oct 31, 2025 at 5:47 AM Rory Walsh > >     > wrote:
>> >      >>>>
>> >      >>>> It would be nice to iron out some inconsistencies in the
>> >     language before releasing Csound 7. One of these is the scattershot
>> >     approach to opcode names. Right now we have lowerCamelCase,
>> >     snake_case, snake+camel case, and the traditional flatcase. It would
>> >     be nice to choose one, create aliases for all existing opcodes (if
>> >     this is doable that is), and mark the others as deprecated.
>> >      >>>>
>> >      >>>> Another thing that came up yesterday in a different discussion
>> >     is the number of version 2 opcodes, diskin2, flooper2, etc. We can
>> >     now easily overload opcodes, which gives us the option of removing
>> >     the version 2 variants and overloading the originals instead,
>> >     although we’d need to audit the opcodes first to see if they all
>> >     have different parameter signatures.
>> >      >>>>
>> >      >>>> Something else that was mentioned was the use of uppercase for
>> >     booleans. bi, bk, booli, boolk, etc., all seem like better fits.
>> >     Another long-standing inconsistency is the uppercase S for strings.
>> >     If I’m not mistaken, we could finally change this to :s and keep it
>> >     in line with other variable types.
>> >      >>>>
>> >      >>>> Consistency has a real impact on usability and teaching,
>> >     making code easier to read and maintain. I think it would be great
>> >     to try to address this now. I don't mind doing most of the donkey
>> >     work. We just need to come to some kind of agreement.
>> >      >>>>
>> >      >>>> Rory.
>> >      >>>>
>> >      >>>>
>> >      >>>> p.s. I'm posting this to the dev-list, but I think this is
>> >     something the end-users might also like to have some input on...
>> >



So I will change OSC to osc and ATS to ats and ZDF1pole becomes zdf1pole?

On Tue, 4 Nov 2025 at 14:12, Steven Yi <stevenyi@gmail.com> wrote:

I'm wary of ZDF1pole, as I'd rather see capitalized identifiers for
data types and lower-case ones for opcodes.

On Tue, Nov 4, 2025 at 7:23 AM Rory Walsh <rorywalsh@ear.ie> wrote:
>
> Below is a list of opcode names that are not strictly flatten case. I propose the following:
>
> - the ATS, K35, OSC one remain.
> - the zdf opcodes join the aforementioned ones can also use uppercase, e.g, ZDF1pole
> - all other opcodes become flattened case, e.g. arduinoreadf, serialwritei, turnoff2_i
>
> Does this sound Ok? If so I will start creating aliases. I can also make a PR for the manual so we can reduce people's exposure to the old inconsistencies.
>
> ATSadd
>
> ATSaddnz
>
> ATSbufread
>
> ATScross
>
> ATSinfo
>
> ATSinterpread
>
> ATSpartialtap
>
> ATSread
>
> ATSreadnz
>
> ATSsinnoi
>
> K35_hpf
>
> K35_lpf
>
> MixerClear
>
> MixerGetLevel
>
> MixerReceive
>
> MixerSend
>
> MixerSetLevel
>
> MixerSetLevel_i
>
> OSCbundle
>
> OSCcount
>
> OSCinit
>
> OSCinitM
>
> OSClisten
>
> OSCraw
>
> OSCsend
>
> OSCsend_lo
>
> S
>
> arduinoRead
>
> arduinoReadF
>
> arduinoStart
>
> arduinoStop
>
> chn_S
>
> chn_a
>
> chn_k
>
> cntCreate
>
> cntCycles
>
> cntDelete
>
> cntDelete_i
>
> cntRead
>
> cntReset
>
> cntState
>
> count_i
>
> diode_ladder
>
> event_i
>
> genarray_i
>
> loop_ge
>
> loop_gt
>
> loop_le
>
> loop_lt
>
> maparray_i
>
> max_k
>
> midiout_i
>
> nchnls_hw
>
> print_type
>
> printf_i
>
> sc_lag
>
> sc_lagud
>
> sc_phasor
>
> sc_trig
>
> scoreline_i
>
> serialBegin
>
> serialEnd
>
> serialFlush
>
> serialPrint
>
> serialRead
>
> serialWrite
>
> serialWrite_i
>
> slicearray_i
>
> sliderKawai
>
> system_i
>
> tab_i
>
> tabw_i
>
> trigExpseg
>
> trigLinseg
>
> trim_i
>
> turnoff2_i
>
> vadd_i
>
> vaddv_i
>
> vcopy_i
>
> vdel_k
>
> vdivv_i
>
> vexp_i
>
> vexpv_i
>
> vmult_i
>
> vmultv_i
>
> vpow_i
>
> vpowv_i
>
> vsubv_i
>
> zdf_1pole
>
> zdf_1pole_mode
>
> zdf_2pole
>
> zdf_2pole_mode
>
> zdf_ladder
>
>
> On Sun, 2 Nov 2025 at 11:29, joachim heintz <jh@joachimheintz.de> wrote:
>>
>> plus one for what you say about tipping the hat ... =)
>>
>> On 31/10/2025 23:53, Rory Walsh wrote:
>> > We also have shedkwhen and ftsamplebank, which are also ok, I think. I
>> > think if we introduce snake case, or any other convention, we need to go
>> > all in. Snake case should add an underscore between each word. Following
>> > such a scheme would lead to hundreds of opcodes being renamed, e.g.,
>> > ft_len, butter_lp, moog_ladder, pd_half, etc. I'm not against it, but I
>> > think it must be a complete buy in. Otherwise we end up with a slightly
>> > better system, but one that retains some strange inconsistencies.
>> >
>> > I have to tip my hat to the core developers at this stage. This
>> > conversation wouldn't be happening if they hadn't spent so much time
>> > cleaning up the core system and updating/rewriting the parser. It's a
>> > great place we are in now! ☺️
>> >
>> > On Fri 31 Oct 2025, 17:17 joachim heintz, <jh@joachimheintz.de
>> > <mailto:jh@joachimheintz.de>> wrote:
>> >
>> >     i totally agree with rory about the importance of such a cleanup.
>> >     as to lowercase or snake_case, i'd say:
>> >     - in most cases we can keep lowercase
>> >     - if the readability is hurted, underscores can be added.
>> >
>> >     for instance: ampdb, mtof, bformenc, butbp, pvsynth are good.
>> >     osclisten even is ok, i think.
>> >
>> >     just to note that for the german keyboard the underscore is not as
>> >     elegant as for the english one.
>> >
>> >     On 31/10/2025 16:46, Steven Yi wrote:
>> >      > I generally prefer snake_case myself these days for Csound coding.
>> >      > Perhaps it's because my brain switches somewhat to C conventions when
>> >      > I get to time with Csound. Some of the coding in Csound for
>> >     snake_case
>> >      > has to do with the lack of namespaces and import system, so families
>> >      > of code are denoted with things like zdf_ladder, zdf_2pole, etc.
>> >     which
>> >      > might be implemented as zdf::ladder or zdf::2pole in other languages.
>> >      >
>> >      > On Fri, Oct 31, 2025 at 9:36 AM Rory Walsh <rorywalsh@ear.ie
>> >     <mailto:rorywalsh@ear.ie>> wrote:
>> >      >>
>> >      >> I agree that they are more readable, but I think switching to
>> >     lowerCamelCase or snake_case would be a huge undertaking. I'm
>> >     interested to hear what others think.
>> >      >>
>> >      >> On Fri, 31 Oct 2025 at 11:30, Dave Seidel <dave.seidel@gmail.com
>> >     <mailto:dave.seidel@gmail.com>> wrote:
>> >      >>>
>> >      >>> As a user, more consistency in naming would be very nice. I
>> >     don't have a strong preference for any particular form, having had
>> >     to adapt to all of them at one time or another over the course of my
>> >     erstwhile career, but I guess I have somewhat of a reference for
>> >     either lowerCamelCase or snake_case, as both offer better
>> >     readability (IMO) than flatcase.
>> >      >>>
>> >      >>> - Dave
>> >      >>>
>> >      >>> On Fri, Oct 31, 2025 at 5:47 AM Rory Walsh <rorywalsh@ear.ie
>> >     <mailto:rorywalsh@ear.ie>> wrote:
>> >      >>>>
>> >      >>>> It would be nice to iron out some inconsistencies in the
>> >     language before releasing Csound 7. One of these is the scattershot
>> >     approach to opcode names. Right now we have lowerCamelCase,
>> >     snake_case, snake+camel case, and the traditional flatcase. It would
>> >     be nice to choose one, create aliases for all existing opcodes (if
>> >     this is doable that is), and mark the others as deprecated.
>> >      >>>>
>> >      >>>> Another thing that came up yesterday in a different discussion
>> >     is the number of version 2 opcodes, diskin2, flooper2, etc. We can
>> >     now easily overload opcodes, which gives us the option of removing
>> >     the version 2 variants and overloading the originals instead,
>> >     although we’d need to audit the opcodes first to see if they all
>> >     have different parameter signatures.
>> >      >>>>
>> >      >>>> Something else that was mentioned was the use of uppercase for
>> >     booleans. bi, bk, booli, boolk, etc., all seem like better fits.
>> >     Another long-standing inconsistency is the uppercase S for strings.
>> >     If I’m not mistaken, we could finally change this to :s and keep it
>> >     in line with other variable types.
>> >      >>>>
>> >      >>>> Consistency has a real impact on usability and teaching,
>> >     making code easier to read and maintain. I think it would be great
>> >     to try to address this now. I don't mind doing most of the donkey
>> >     work. We just need to come to some kind of agreement.
>> >      >>>>
>> >      >>>> Rory.
>> >      >>>>
>> >      >>>>
>> >      >>>> p.s. I'm posting this to the dev-list, but I think this is
>> >     something the end-users might also like to have some input on...
>> >



That's a good point. I'm leaning towards uppercase for acronyms and lowercase for everything else. Only a dozen or so opcodes will end up with uppercase chars, but at least it will be consistent and obvious why. 

On Tue, 4 Nov 2025 at 15:14, Victor Lazzarini <000010b17ddd988e-dmarc-request@listserv.heanet.ie> wrote:

The problem with OSC is that it'll mix up with oscillators, but the others seem ok to change.

Prof. Victor Lazzarini

Maynooth University

Ireland

On 4 Nov 2025, at 14:26, Rory Walsh <rorywalsh@ear.ie> wrote:



So I will change OSC to osc and ATS to ats and ZDF1pole becomes zdf1pole?

On Tue, 4 Nov 2025 at 14:12, Steven Yi <stevenyi@gmail.com> wrote:

I'm wary of ZDF1pole, as I'd rather see capitalized identifiers for
data types and lower-case ones for opcodes.

On Tue, Nov 4, 2025 at 7:23 AM Rory Walsh <rorywalsh@ear.ie> wrote:
>
> Below is a list of opcode names that are not strictly flatten case. I propose the following:
>
> - the ATS, K35, OSC one remain.
> - the zdf opcodes join the aforementioned ones can also use uppercase, e.g, ZDF1pole
> - all other opcodes become flattened case, e.g. arduinoreadf, serialwritei, turnoff2_i
>
> Does this sound Ok? If so I will start creating aliases. I can also make a PR for the manual so we can reduce people's exposure to the old inconsistencies.
>
> ATSadd
>
> ATSaddnz
>
> ATSbufread
>
> ATScross
>
> ATSinfo
>
> ATSinterpread
>
> ATSpartialtap
>
> ATSread
>
> ATSreadnz
>
> ATSsinnoi
>
> K35_hpf
>
> K35_lpf
>
> MixerClear
>
> MixerGetLevel
>
> MixerReceive
>
> MixerSend
>
> MixerSetLevel
>
> MixerSetLevel_i
>
> OSCbundle
>
> OSCcount
>
> OSCinit
>
> OSCinitM
>
> OSClisten
>
> OSCraw
>
> OSCsend
>
> OSCsend_lo
>
> S
>
> arduinoRead
>
> arduinoReadF
>
> arduinoStart
>
> arduinoStop
>
> chn_S
>
> chn_a
>
> chn_k
>
> cntCreate
>
> cntCycles
>
> cntDelete
>
> cntDelete_i
>
> cntRead
>
> cntReset
>
> cntState
>
> count_i
>
> diode_ladder
>
> event_i
>
> genarray_i
>
> loop_ge
>
> loop_gt
>
> loop_le
>
> loop_lt
>
> maparray_i
>
> max_k
>
> midiout_i
>
> nchnls_hw
>
> print_type
>
> printf_i
>
> sc_lag
>
> sc_lagud
>
> sc_phasor
>
> sc_trig
>
> scoreline_i
>
> serialBegin
>
> serialEnd
>
> serialFlush
>
> serialPrint
>
> serialRead
>
> serialWrite
>
> serialWrite_i
>
> slicearray_i
>
> sliderKawai
>
> system_i
>
> tab_i
>
> tabw_i
>
> trigExpseg
>
> trigLinseg
>
> trim_i
>
> turnoff2_i
>
> vadd_i
>
> vaddv_i
>
> vcopy_i
>
> vdel_k
>
> vdivv_i
>
> vexp_i
>
> vexpv_i
>
> vmult_i
>
> vmultv_i
>
> vpow_i
>
> vpowv_i
>
> vsubv_i
>
> zdf_1pole
>
> zdf_1pole_mode
>
> zdf_2pole
>
> zdf_2pole_mode
>
> zdf_ladder
>
>
> On Sun, 2 Nov 2025 at 11:29, joachim heintz <jh@joachimheintz.de> wrote:
>>
>> plus one for what you say about tipping the hat ... =)
>>
>> On 31/10/2025 23:53, Rory Walsh wrote:
>> > We also have shedkwhen and ftsamplebank, which are also ok, I think. I
>> > think if we introduce snake case, or any other convention, we need to go
>> > all in. Snake case should add an underscore between each word. Following
>> > such a scheme would lead to hundreds of opcodes being renamed, e.g.,
>> > ft_len, butter_lp, moog_ladder, pd_half, etc. I'm not against it, but I
>> > think it must be a complete buy in. Otherwise we end up with a slightly
>> > better system, but one that retains some strange inconsistencies.
>> >
>> > I have to tip my hat to the core developers at this stage. This
>> > conversation wouldn't be happening if they hadn't spent so much time
>> > cleaning up the core system and updating/rewriting the parser. It's a
>> > great place we are in now! ☺️
>> >
>> > On Fri 31 Oct 2025, 17:17 joachim heintz, <jh@joachimheintz.de
>> > <mailto:jh@joachimheintz.de>> wrote:
>> >
>> >     i totally agree with rory about the importance of such a cleanup.
>> >     as to lowercase or snake_case, i'd say:
>> >     - in most cases we can keep lowercase
>> >     - if the readability is hurted, underscores can be added.
>> >
>> >     for instance: ampdb, mtof, bformenc, butbp, pvsynth are good.
>> >     osclisten even is ok, i think.
>> >
>> >     just to note that for the german keyboard the underscore is not as
>> >     elegant as for the english one.
>> >
>> >     On 31/10/2025 16:46, Steven Yi wrote:
>> >      > I generally prefer snake_case myself these days for Csound coding.
>> >      > Perhaps it's because my brain switches somewhat to C conventions when
>> >      > I get to time with Csound. Some of the coding in Csound for
>> >     snake_case
>> >      > has to do with the lack of namespaces and import system, so families
>> >      > of code are denoted with things like zdf_ladder, zdf_2pole, etc.
>> >     which
>> >      > might be implemented as zdf::ladder or zdf::2pole in other languages.
>> >      >
>> >      > On Fri, Oct 31, 2025 at 9:36 AM Rory Walsh <rorywalsh@ear.ie
>> >     <mailto:rorywalsh@ear.ie>> wrote:
>> >      >>
>> >      >> I agree that they are more readable, but I think switching to
>> >     lowerCamelCase or snake_case would be a huge undertaking. I'm
>> >     interested to hear what others think.
>> >      >>
>> >      >> On Fri, 31 Oct 2025 at 11:30, Dave Seidel <dave.seidel@gmail.com
>> >     <mailto:dave.seidel@gmail.com>> wrote:
>> >      >>>
>> >      >>> As a user, more consistency in naming would be very nice. I
>> >     don't have a strong preference for any particular form, having had
>> >     to adapt to all of them at one time or another over the course of my
>> >     erstwhile career, but I guess I have somewhat of a reference for
>> >     either lowerCamelCase or snake_case, as both offer better
>> >     readability (IMO) than flatcase.
>> >      >>>
>> >      >>> - Dave
>> >      >>>
>> >      >>> On Fri, Oct 31, 2025 at 5:47 AM Rory Walsh <rorywalsh@ear.ie
>> >     <mailto:rorywalsh@ear.ie>> wrote:
>> >      >>>>
>> >      >>>> It would be nice to iron out some inconsistencies in the
>> >     language before releasing Csound 7. One of these is the scattershot
>> >     approach to opcode names. Right now we have lowerCamelCase,
>> >     snake_case, snake+camel case, and the traditional flatcase. It would
>> >     be nice to choose one, create aliases for all existing opcodes (if
>> >     this is doable that is), and mark the others as deprecated.
>> >      >>>>
>> >      >>>> Another thing that came up yesterday in a different discussion
>> >     is the number of version 2 opcodes, diskin2, flooper2, etc. We can
>> >     now easily overload opcodes, which gives us the option of removing
>> >     the version 2 variants and overloading the originals instead,
>> >     although we’d need to audit the opcodes first to see if they all
>> >     have different parameter signatures.
>> >      >>>>
>> >      >>>> Something else that was mentioned was the use of uppercase for
>> >     booleans. bi, bk, booli, boolk, etc., all seem like better fits.
>> >     Another long-standing inconsistency is the uppercase S for strings.
>> >     If I’m not mistaken, we could finally change this to :s and keep it
>> >     in line with other variable types.
>> >      >>>>
>> >      >>>> Consistency has a real impact on usability and teaching,
>> >     making code easier to read and maintain. I think it would be great
>> >     to try to address this now. I don't mind doing most of the donkey
>> >     work. We just need to come to some kind of agreement.
>> >      >>>>
>> >      >>>> Rory.
>> >      >>>>
>> >      >>>>
>> >      >>>> p.s. I'm posting this to the dev-list, but I think this is
>> >     something the end-users might also like to have some input on...
>> >



Touche. Ok, so the argument against OSC becoming 'osc' is that users might consfure them for oscillators, I'd say we could get away with it? All oscillators in Csound use 'oscil...' so that should be fine. There is but one pesky opcode called oscbnk. I'd rather create an alias for this called oscilbank and go with lower case osc for the OSC opcodes. 

On Tue, 4 Nov 2025 at 16:20, vlz <viclazzarini@gmail.com> wrote:

Trouble is then things like lpf18 and mvclpf etc which are also acronyms

Prof. Victor Lazzarini

Maynooth University

Ireland

On 4 Nov 2025, at 15:46, Rory Walsh <rorywalsh@ear.ie> wrote:



That's a good point. I'm leaning towards uppercase for acronyms and lowercase for everything else. Only a dozen or so opcodes will end up with uppercase chars, but at least it will be consistent and obvious why. 

On Tue, 4 Nov 2025 at 15:14, Victor Lazzarini <000010b17ddd988e-dmarc-request@listserv.heanet.ie> wrote:

The problem with OSC is that it'll mix up with oscillators, but the others seem ok to change.

Prof. Victor Lazzarini

Maynooth University

Ireland

On 4 Nov 2025, at 14:26, Rory Walsh <rorywalsh@ear.ie> wrote:



So I will change OSC to osc and ATS to ats and ZDF1pole becomes zdf1pole?

On Tue, 4 Nov 2025 at 14:12, Steven Yi <stevenyi@gmail.com> wrote:

I'm wary of ZDF1pole, as I'd rather see capitalized identifiers for
data types and lower-case ones for opcodes.

On Tue, Nov 4, 2025 at 7:23 AM Rory Walsh <rorywalsh@ear.ie> wrote:
>
> Below is a list of opcode names that are not strictly flatten case. I propose the following:
>
> - the ATS, K35, OSC one remain.
> - the zdf opcodes join the aforementioned ones can also use uppercase, e.g, ZDF1pole
> - all other opcodes become flattened case, e.g. arduinoreadf, serialwritei, turnoff2_i
>
> Does this sound Ok? If so I will start creating aliases. I can also make a PR for the manual so we can reduce people's exposure to the old inconsistencies.
>
> ATSadd
>
> ATSaddnz
>
> ATSbufread
>
> ATScross
>
> ATSinfo
>
> ATSinterpread
>
> ATSpartialtap
>
> ATSread
>
> ATSreadnz
>
> ATSsinnoi
>
> K35_hpf
>
> K35_lpf
>
> MixerClear
>
> MixerGetLevel
>
> MixerReceive
>
> MixerSend
>
> MixerSetLevel
>
> MixerSetLevel_i
>
> OSCbundle
>
> OSCcount
>
> OSCinit
>
> OSCinitM
>
> OSClisten
>
> OSCraw
>
> OSCsend
>
> OSCsend_lo
>
> S
>
> arduinoRead
>
> arduinoReadF
>
> arduinoStart
>
> arduinoStop
>
> chn_S
>
> chn_a
>
> chn_k
>
> cntCreate
>
> cntCycles
>
> cntDelete
>
> cntDelete_i
>
> cntRead
>
> cntReset
>
> cntState
>
> count_i
>
> diode_ladder
>
> event_i
>
> genarray_i
>
> loop_ge
>
> loop_gt
>
> loop_le
>
> loop_lt
>
> maparray_i
>
> max_k
>
> midiout_i
>
> nchnls_hw
>
> print_type
>
> printf_i
>
> sc_lag
>
> sc_lagud
>
> sc_phasor
>
> sc_trig
>
> scoreline_i
>
> serialBegin
>
> serialEnd
>
> serialFlush
>
> serialPrint
>
> serialRead
>
> serialWrite
>
> serialWrite_i
>
> slicearray_i
>
> sliderKawai
>
> system_i
>
> tab_i
>
> tabw_i
>
> trigExpseg
>
> trigLinseg
>
> trim_i
>
> turnoff2_i
>
> vadd_i
>
> vaddv_i
>
> vcopy_i
>
> vdel_k
>
> vdivv_i
>
> vexp_i
>
> vexpv_i
>
> vmult_i
>
> vmultv_i
>
> vpow_i
>
> vpowv_i
>
> vsubv_i
>
> zdf_1pole
>
> zdf_1pole_mode
>
> zdf_2pole
>
> zdf_2pole_mode
>
> zdf_ladder
>
>
> On Sun, 2 Nov 2025 at 11:29, joachim heintz <jh@joachimheintz.de> wrote:
>>
>> plus one for what you say about tipping the hat ... =)
>>
>> On 31/10/2025 23:53, Rory Walsh wrote:
>> > We also have shedkwhen and ftsamplebank, which are also ok, I think. I
>> > think if we introduce snake case, or any other convention, we need to go
>> > all in. Snake case should add an underscore between each word. Following
>> > such a scheme would lead to hundreds of opcodes being renamed, e.g.,
>> > ft_len, butter_lp, moog_ladder, pd_half, etc. I'm not against it, but I
>> > think it must be a complete buy in. Otherwise we end up with a slightly
>> > better system, but one that retains some strange inconsistencies.
>> >
>> > I have to tip my hat to the core developers at this stage. This
>> > conversation wouldn't be happening if they hadn't spent so much time
>> > cleaning up the core system and updating/rewriting the parser. It's a
>> > great place we are in now! ☺️
>> >
>> > On Fri 31 Oct 2025, 17:17 joachim heintz, <jh@joachimheintz.de
>> > <mailto:jh@joachimheintz.de>> wrote:
>> >
>> >     i totally agree with rory about the importance of such a cleanup.
>> >     as to lowercase or snake_case, i'd say:
>> >     - in most cases we can keep lowercase
>> >     - if the readability is hurted, underscores can be added.
>> >
>> >     for instance: ampdb, mtof, bformenc, butbp, pvsynth are good.
>> >     osclisten even is ok, i think.
>> >
>> >     just to note that for the german keyboard the underscore is not as
>> >     elegant as for the english one.
>> >
>> >     On 31/10/2025 16:46, Steven Yi wrote:
>> >      > I generally prefer snake_case myself these days for Csound coding.
>> >      > Perhaps it's because my brain switches somewhat to C conventions when
>> >      > I get to time with Csound. Some of the coding in Csound for
>> >     snake_case
>> >      > has to do with the lack of namespaces and import system, so families
>> >      > of code are denoted with things like zdf_ladder, zdf_2pole, etc.
>> >     which
>> >      > might be implemented as zdf::ladder or zdf::2pole in other languages.
>> >      >
>> >      > On Fri, Oct 31, 2025 at 9:36 AM Rory Walsh <rorywalsh@ear.ie
>> >     <mailto:rorywalsh@ear.ie>> wrote:
>> >      >>
>> >      >> I agree that they are more readable, but I think switching to
>> >     lowerCamelCase or snake_case would be a huge undertaking. I'm
>> >     interested to hear what others think.
>> >      >>
>> >      >> On Fri, 31 Oct 2025 at 11:30, Dave Seidel <dave.seidel@gmail.com
>> >     <mailto:dave.seidel@gmail.com>> wrote:
>> >      >>>
>> >      >>> As a user, more consistency in naming would be very nice. I
>> >     don't have a strong preference for any particular form, having had
>> >     to adapt to all of them at one time or another over the course of my
>> >     erstwhile career, but I guess I have somewhat of a reference for
>> >     either lowerCamelCase or snake_case, as both offer better
>> >     readability (IMO) than flatcase.
>> >      >>>
>> >      >>> - Dave
>> >      >>>
>> >      >>> On Fri, Oct 31, 2025 at 5:47 AM Rory Walsh <rorywalsh@ear.ie
>> >     <mailto:rorywalsh@ear.ie>> wrote:
>> >      >>>>
>> >      >>>> It would be nice to iron out some inconsistencies in the
>> >     language before releasing Csound 7. One of these is the scattershot
>> >     approach to opcode names. Right now we have lowerCamelCase,
>> >     snake_case, snake+camel case, and the traditional flatcase. It would
>> >     be nice to choose one, create aliases for all existing opcodes (if
>> >     this is doable that is), and mark the others as deprecated.
>> >      >>>>
>> >      >>>> Another thing that came up yesterday in a different discussion
>> >     is the number of version 2 opcodes, diskin2, flooper2, etc. We can
>> >     now easily overload opcodes, which gives us the option of removing
>> >     the version 2 variants and overloading the originals instead,
>> >     although we’d need to audit the opcodes first to see if they all
>> >     have different parameter signatures.
>> >      >>>>
>> >      >>>> Something else that was mentioned was the use of uppercase for
>> >     booleans. bi, bk, booli, boolk, etc., all seem like better fits.
>> >     Another long-standing inconsistency is the uppercase S for strings.
>> >     If I’m not mistaken, we could finally change this to :s and keep it
>> >     in line with other variable types.
>> >      >>>>
>> >      >>>> Consistency has a real impact on usability and teaching,
>> >     making code easier to read and maintain. I think it would be great
>> >     to try to address this now. I don't mind doing most of the donkey
>> >     work. We just need to come to some kind of agreement.
>> >      >>>>
>> >      >>>> Rory.
>> >      >>>>
>> >      >>>>
>> >      >>>> p.s. I'm posting this to the dev-list, but I think this is
>> >     something the end-users might also like to have some input on...
>> >

i think this is a very good solution.

On 04/11/2025 17:34, vlz wrote:
> Fine with me.
> Prof. Victor Lazzarini
> Maynooth University
> Ireland
> 
>> On 4 Nov 2025, at 16:25, Rory Walsh  wrote:
>>
>> 
>> Touche. Ok, so the argument against OSC becoming 'osc' is that users 
>> might consfure them for oscillators, I'd say we could get away with 
>> it? All oscillators in Csound use 'oscil...' so that should be fine. 
>> There is but one pesky opcode called oscbnk. I'd rather create an 
>> alias for this called oscilbank and go with lower case osc for the OSC 
>> opcodes.
>>
>>
>> On Tue, 4 Nov 2025 at 16:20, vlz > > wrote:
>>
>>     Trouble is then things like lpf18 and mvclpf etc which are also
>>     acronyms
>>
>>     Prof. Victor Lazzarini
>>     Maynooth University
>>     Ireland
>>
>>>     On 4 Nov 2025, at 15:46, Rory Walsh >>     > wrote:
>>>
>>>     
>>>     That's a good point. I'm leaning towards uppercase for acronyms
>>>     and lowercase for everything else. Only a dozen or so opcodes
>>>     will end up with uppercase chars, but at least it will be
>>>     consistent and obvious why.
>>>
>>>     On Tue, 4 Nov 2025 at 15:14, Victor Lazzarini <000010b17ddd988e-
>>>     dmarc-request@listserv.heanet.ie >>     request@listserv.heanet.ie>> wrote:
>>>
>>>         The problem with OSC is that it'll mix up with oscillators,
>>>         but the others seem ok to change.
>>>
>>>         Prof. Victor Lazzarini
>>>         Maynooth University
>>>         Ireland
>>>
>>>>         On 4 Nov 2025, at 14:26, Rory Walsh >>>         > wrote:
>>>>
>>>>         
>>>>         So I will change OSC to osc and ATS to ats and ZDF1pole
>>>>         becomes zdf1pole?
>>>>
>>>>         On Tue, 4 Nov 2025 at 14:12, Steven Yi >>>         > wrote:
>>>>
>>>>             I'm wary of ZDF1pole, as I'd rather see capitalized
>>>>             identifiers for
>>>>             data types and lower-case ones for opcodes.
>>>>
>>>>             On Tue, Nov 4, 2025 at 7:23 AM Rory Walsh
>>>>             > wrote:
>>>>             >
>>>>             > Below is a list of opcode names that are not strictly
>>>>             flatten case. I propose the following:
>>>>             >
>>>>             > - the ATS, K35, OSC one remain.
>>>>             > - the zdf opcodes join the aforementioned ones can
>>>>             also use uppercase, e.g, ZDF1pole
>>>>             > - all other opcodes become flattened case, e.g.
>>>>             arduinoreadf, serialwritei, turnoff2_i
>>>>             >
>>>>             > Does this sound Ok? If so I will start creating
>>>>             aliases. I can also make a PR for the manual so we can
>>>>             reduce people's exposure to the old inconsistencies.
>>>>             >
>>>>             > ATSadd
>>>>             >
>>>>             > ATSaddnz
>>>>             >
>>>>             > ATSbufread
>>>>             >
>>>>             > ATScross
>>>>             >
>>>>             > ATSinfo
>>>>             >
>>>>             > ATSinterpread
>>>>             >
>>>>             > ATSpartialtap
>>>>             >
>>>>             > ATSread
>>>>             >
>>>>             > ATSreadnz
>>>>             >
>>>>             > ATSsinnoi
>>>>             >
>>>>             > K35_hpf
>>>>             >
>>>>             > K35_lpf
>>>>             >
>>>>             > MixerClear
>>>>             >
>>>>             > MixerGetLevel
>>>>             >
>>>>             > MixerReceive
>>>>             >
>>>>             > MixerSend
>>>>             >
>>>>             > MixerSetLevel
>>>>             >
>>>>             > MixerSetLevel_i
>>>>             >
>>>>             > OSCbundle
>>>>             >
>>>>             > OSCcount
>>>>             >
>>>>             > OSCinit
>>>>             >
>>>>             > OSCinitM
>>>>             >
>>>>             > OSClisten
>>>>             >
>>>>             > OSCraw
>>>>             >
>>>>             > OSCsend
>>>>             >
>>>>             > OSCsend_lo
>>>>             >
>>>>             > S
>>>>             >
>>>>             > arduinoRead
>>>>             >
>>>>             > arduinoReadF
>>>>             >
>>>>             > arduinoStart
>>>>             >
>>>>             > arduinoStop
>>>>             >
>>>>             > chn_S
>>>>             >
>>>>             > chn_a
>>>>             >
>>>>             > chn_k
>>>>             >
>>>>             > cntCreate
>>>>             >
>>>>             > cntCycles
>>>>             >
>>>>             > cntDelete
>>>>             >
>>>>             > cntDelete_i
>>>>             >
>>>>             > cntRead
>>>>             >
>>>>             > cntReset
>>>>             >
>>>>             > cntState
>>>>             >
>>>>             > count_i
>>>>             >
>>>>             > diode_ladder
>>>>             >
>>>>             > event_i
>>>>             >
>>>>             > genarray_i
>>>>             >
>>>>             > loop_ge
>>>>             >
>>>>             > loop_gt
>>>>             >
>>>>             > loop_le
>>>>             >
>>>>             > loop_lt
>>>>             >
>>>>             > maparray_i
>>>>             >
>>>>             > max_k
>>>>             >
>>>>             > midiout_i
>>>>             >
>>>>             > nchnls_hw
>>>>             >
>>>>             > print_type
>>>>             >
>>>>             > printf_i
>>>>             >
>>>>             > sc_lag
>>>>             >
>>>>             > sc_lagud
>>>>             >
>>>>             > sc_phasor
>>>>             >
>>>>             > sc_trig
>>>>             >
>>>>             > scoreline_i
>>>>             >
>>>>             > serialBegin
>>>>             >
>>>>             > serialEnd
>>>>             >
>>>>             > serialFlush
>>>>             >
>>>>             > serialPrint
>>>>             >
>>>>             > serialRead
>>>>             >
>>>>             > serialWrite
>>>>             >
>>>>             > serialWrite_i
>>>>             >
>>>>             > slicearray_i
>>>>             >
>>>>             > sliderKawai
>>>>             >
>>>>             > system_i
>>>>             >
>>>>             > tab_i
>>>>             >
>>>>             > tabw_i
>>>>             >
>>>>             > trigExpseg
>>>>             >
>>>>             > trigLinseg
>>>>             >
>>>>             > trim_i
>>>>             >
>>>>             > turnoff2_i
>>>>             >
>>>>             > vadd_i
>>>>             >
>>>>             > vaddv_i
>>>>             >
>>>>             > vcopy_i
>>>>             >
>>>>             > vdel_k
>>>>             >
>>>>             > vdivv_i
>>>>             >
>>>>             > vexp_i
>>>>             >
>>>>             > vexpv_i
>>>>             >
>>>>             > vmult_i
>>>>             >
>>>>             > vmultv_i
>>>>             >
>>>>             > vpow_i
>>>>             >
>>>>             > vpowv_i
>>>>             >
>>>>             > vsubv_i
>>>>             >
>>>>             > zdf_1pole
>>>>             >
>>>>             > zdf_1pole_mode
>>>>             >
>>>>             > zdf_2pole
>>>>             >
>>>>             > zdf_2pole_mode
>>>>             >
>>>>             > zdf_ladder
>>>>             >
>>>>             >
>>>>             > On Sun, 2 Nov 2025 at 11:29, joachim heintz
>>>>             > wrote:
>>>>             >>
>>>>             >> plus one for what you say about tipping the hat ... =)
>>>>             >>
>>>>             >> On 31/10/2025 23:53, Rory Walsh wrote:
>>>>             >> > We also have shedkwhen and ftsamplebank, which are
>>>>             also ok, I think. I
>>>>             >> > think if we introduce snake case, or any other
>>>>             convention, we need to go
>>>>             >> > all in. Snake case should add an underscore between
>>>>             each word. Following
>>>>             >> > such a scheme would lead to hundreds of opcodes
>>>>             being renamed, e.g.,
>>>>             >> > ft_len, butter_lp, moog_ladder, pd_half, etc. I'm
>>>>             not against it, but I
>>>>             >> > think it must be a complete buy in. Otherwise we
>>>>             end up with a slightly
>>>>             >> > better system, but one that retains some strange
>>>>             inconsistencies.
>>>>             >> >
>>>>             >> > I have to tip my hat to the core developers at this
>>>>             stage. This
>>>>             >> > conversation wouldn't be happening if they hadn't
>>>>             spent so much time
>>>>             >> > cleaning up the core system and updating/rewriting
>>>>             the parser. It's a
>>>>             >> > great place we are in now! ☺️
>>>>             >> >
>>>>             >> > On Fri 31 Oct 2025, 17:17 joachim heintz,
>>>>             
>>>>             >> > >>>             >> wrote:
>>>>             >> >
>>>>             >> >     i totally agree with rory about the importance
>>>>             of such a cleanup.
>>>>             >> >     as to lowercase or snake_case, i'd say:
>>>>             >> >     - in most cases we can keep lowercase
>>>>             >> >     - if the readability is hurted, underscores can
>>>>             be added.
>>>>             >> >
>>>>             >> >     for instance: ampdb, mtof, bformenc, butbp,
>>>>             pvsynth are good.
>>>>             >> >     osclisten even is ok, i think.
>>>>             >> >
>>>>             >> >     just to note that for the german keyboard the
>>>>             underscore is not as
>>>>             >> >     elegant as for the english one.
>>>>             >> >
>>>>             >> >     On 31/10/2025 16:46, Steven Yi wrote:
>>>>             >> >      > I generally prefer snake_case myself these
>>>>             days for Csound coding.
>>>>             >> >      > Perhaps it's because my brain switches
>>>>             somewhat to C conventions when
>>>>             >> >      > I get to time with Csound. Some of the
>>>>             coding in Csound for
>>>>             >> >     snake_case
>>>>             >> >      > has to do with the lack of namespaces and
>>>>             import system, so families
>>>>             >> >      > of code are denoted with things like
>>>>             zdf_ladder, zdf_2pole, etc.
>>>>             >> >     which
>>>>             >> >      > might be implemented as zdf::ladder or
>>>>             zdf::2pole in other languages.
>>>>             >> >      >
>>>>             >> >      > On Fri, Oct 31, 2025 at 9:36 AM Rory Walsh
>>>>             
>>>>             >> >     >>>             >> wrote:
>>>>             >> >      >>
>>>>             >> >      >> I agree that they are more readable, but I
>>>>             think switching to
>>>>             >> >     lowerCamelCase or snake_case would be a huge
>>>>             undertaking. I'm
>>>>             >> >     interested to hear what others think.
>>>>             >> >      >>
>>>>             >> >      >> On Fri, 31 Oct 2025 at 11:30, Dave Seidel
>>>>             
>>>>             >> >     >>>             >> wrote:
>>>>             >> >      >>>
>>>>             >> >      >>> As a user, more consistency in naming
>>>>             would be very nice. I
>>>>             >> >     don't have a strong preference for any
>>>>             particular form, having had
>>>>             >> >     to adapt to all of them at one time or another
>>>>             over the course of my
>>>>             >> >     erstwhile career, but I guess I have somewhat
>>>>             of a reference for
>>>>             >> >     either lowerCamelCase or snake_case, as both
>>>>             offer better
>>>>             >> >     readability (IMO) than flatcase.
>>>>             >> >      >>>
>>>>             >> >      >>> - Dave
>>>>             >> >      >>>
>>>>             >> >      >>> On Fri, Oct 31, 2025 at 5:47 AM Rory Walsh
>>>>             
>>>>             >> >     >>>             >> wrote:
>>>>             >> >      >>>>
>>>>             >> >      >>>> It would be nice to iron out some
>>>>             inconsistencies in the
>>>>             >> >     language before releasing Csound 7. One of
>>>>             these is the scattershot
>>>>             >> >     approach to opcode names. Right now we have
>>>>             lowerCamelCase,
>>>>             >> >     snake_case, snake+camel case, and the
>>>>             traditional flatcase. It would
>>>>             >> >     be nice to choose one, create aliases for all
>>>>             existing opcodes (if
>>>>             >> >     this is doable that is), and mark the others as
>>>>             deprecated.
>>>>             >> >      >>>>
>>>>             >> >      >>>> Another thing that came up yesterday in a
>>>>             different discussion
>>>>             >> >     is the number of version 2 opcodes, diskin2,
>>>>             flooper2, etc. We can
>>>>             >> >     now easily overload opcodes, which gives us the
>>>>             option of removing
>>>>             >> >     the version 2 variants and overloading the
>>>>             originals instead,
>>>>             >> >     although we’d need to audit the opcodes first
>>>>             to see if they all
>>>>             >> >     have different parameter signatures.
>>>>             >> >      >>>>
>>>>             >> >      >>>> Something else that was mentioned was the
>>>>             use of uppercase for
>>>>             >> >     booleans. bi, bk, booli, boolk, etc., all seem
>>>>             like better fits.
>>>>             >> >     Another long-standing inconsistency is the
>>>>             uppercase S for strings.
>>>>             >> >     If I’m not mistaken, we could finally change
>>>>             this to :s and keep it
>>>>             >> >     in line with other variable types.
>>>>             >> >      >>>>
>>>>             >> >      >>>> Consistency has a real impact on
>>>>             usability and teaching,
>>>>             >> >     making code easier to read and maintain. I
>>>>             think it would be great
>>>>             >> >     to try to address this now. I don't mind doing
>>>>             most of the donkey
>>>>             >> >     work. We just need to come to some kind of
>>>>             agreement.
>>>>             >> >      >>>>
>>>>             >> >      >>>> Rory.
>>>>             >> >      >>>>
>>>>             >> >      >>>>
>>>>             >> >      >>>> p.s. I'm posting this to the dev-list,
>>>>             but I think this is
>>>>             >> >     something the end-users might also like to have
>>>>             some input on...
>>>>             >> >
>>>>