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

Fine with me.
Prof. Victor Lazzarini
Maynooth University

Ireland

On 4 Nov 2025, at 16:25, Rory Walsh <[email protected]> wrote:


Touche. Ok, so the argument against OSC becoming 'osc' is that users might consfure them for oscillators, I'd say we could get away with it? All oscillators in Csound use 'oscil...' so that should be fine. There is but one pesky opcode called oscbnk. I'd rather create an alias for this called oscilbank and go with lower case osc for the OSC opcodes.

On Tue, 4 Nov 2025 at 16:20, vlz <[email protected] > wrote:

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

>> >