Re: [Csnd-dev] language cleanup...
joachim heintz <[email protected]> Tue, 4 Nov 2025 21:02:06 +0100
| Newsgroups | gmane.comp.audio.csound.devel |
|---|---|
| Message-ID | <[email protected]> |
i think this is a very good solution. On 04/11/2025 17:34, vlz wrote: > 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] >> <mailto:[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] >>> <mailto:[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 <000010b17ddd988e- >>> [email protected] <mailto:000010b17ddd988e-dmarc- >>> [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] >>>> <mailto:[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] >>>> <mailto:[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] <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... >>>> >> > >>>>