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

Not many, when you look at it.

Did you look at the xxx2 xxx3 to see if we can overload or will that be better in a second pass?
Prof. Victor Lazzarini
Maynooth University

Ireland

On 4 Nov 2025, at 12:23, 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...

>