Re: [Csnd-dev] language cleanup...

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 <[email protected]> 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 <[email protected]> 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, <[email protected]
>> > <mailto:[email protected]>> 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 <[email protected]
>> >     <mailto:[email protected]>> 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 <[email protected]
>> >     <mailto:[email protected]>> 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 <[email protected]
>> >     <mailto:[email protected]>> 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...
>> >