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

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...
> >> >
>