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

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