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

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

>> >