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

There is no real attemot renaming, we're only adding aliases and deprecating old names. We can't break backwards compatibility.

I think the "2" opcodes can be overloaded if the input or output parameters are of different types that can be disambiguated. Some can and some can't.

Prof. Victor Lazzarini
Maynooth University
Ireland

On 4 Nov 2025, at 14:44, Eduardo Moguillansky <[email protected]> wrote:


*Warning*

This email originated from outside of Maynooth University's Mail System. Do not reply, click links or open attachments unless you recognise the sender and know the content is safe.

Many xxx2 or xxx3 have really different behaviours.

turnoff, turnoff2, turnoff3: these could be unified to turnoff, deprecating the argument to the original turnoff and adding a flag to turnoff2 to unschedule future events
follow, follow2: follow2 is a different opcode, using a different algorithm. Maybe it could be renamed to ampfollow or something similar
metro2: is a different opcode than metro, maybe it could also be renamed
changed2: this is the correct version of changed, which itself should be deprecated. But renaming to changed would break things

Each of these changes should probably be a PR of its own.



On Tue, Nov 4, 2025 at 1:23 PM Rory Walsh <[email protected]<mailto:[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]<mailto:[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]>
> <mailto:[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]>
>     <mailto:[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]>
>     <mailto:[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]>
>     <mailto:[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...
>