| I use this practice myself in my own code. Makes things a lot more readable.
Agreed,... way out side the normal conventions of what is normally done. A quick glance at it
and I found it confusing. So "inside baseball" as to be way outside. I tend to agree with Michael
about coding standards, makes more sense in an open source software like this.
-PBS
===================================================
--- dave.seidel@GMAIL.COM wrote: From: Dave Seidel < dave.seidel@GMAIL.COM> To: CSOUND@LISTSERV.HEANET.IESubject: Re: [Csnd] Best practices for Csound code Date: Mon, 7 Oct 2019 15:14:49 -0400 Yes, you got what I meant.
A long variable name that one can understand is usable, an
abbreviation that one must figure out just gets in the way and slows
things down.
Coding standards for organizations that must produce complex software,
such as Google, MISRA, Lockheed Martin, etc. etc. etc say exactly what
I am saying.
In general, programmers always seem to assume everybody knows the same
abbreviations they do. This, in fact, is rarely the case. As Google
says, "If an abbreviation is in Wikipedia, it's probably OK."
Otherwise, no.
Best,
Mike
-----------------------------------------------------
Michael Gogins
Irreducible Productions
http://michaelgogins.tumblr.com
Michael dot Gogins at gmail dot com
-----------------------------------------------------
Michael Gogins
Irreducible Productions
http://michaelgogins.tumblr.com
Michael dot Gogins at gmail dot com
On Mon, Oct 7, 2019 at 2:54 PM joachim heintz <jh@joachimheintz.de> wrote:
>
> but would this not lead to extreme long variable names?
>
> kRandomElement instead of kRndEl
> aFrequencyModulation instead of aFreqMod (or in this case aFM)
>
> or didn't i get what you meant?
>
>
>
> On 07/10/19 18:13, Michael Gogins wrote:
> > The same principle applies. SIAout. spell_it_all_out.
> >
> > Best,
> > Mike
> >
> > -----------------------------------------------------
> > Michael Gogins
> > Irreducible Productions
> > http://michaelgogins.tumblr.com
> > Michael dot Gogins at gmail dot com
> >
> >
> > On Mon, Oct 7, 2019 at 11:21 AM Dave Seidel <dave.seidel@gmail.com
> > <mailto:dave.seidel@gmail.com>> wrote:
> >
> > whoops "acronyms" not "abbreviations", I mistyped
> >
> > On Mon, Oct 7, 2019 at 11:15 AM Michael Gogins
> > <michael.gogins@gmail.com <mailto:michael.gogins@gmail.com>> wrote:
> >
> > That's my point exactly. PAAA stands for Please Avoid All
> > Acronyms. The acronym is opaque, and spelling it out is crystal
> > clear.
> >
> > Best,
> > Mike
> >
> >
> >
> > On Mon, Oct 7, 2019, 10:07 joachim heintz <jh@joachimheintz.de
> > <mailto:jh@joachimheintz.de>> wrote:
> >
> > what is PAAA? and what would you suggest?
> >
> >
> >
> > On 07/10/19 14:56, Michael Gogins wrote:
> > > PAAA. Or, please avoid all abbreviations in any style guides.
> > >
> > > Regards,
> > > Mike
> > >
> > > -----------------------------------------------------
> > > Michael Gogins
> > > Irreducible Productions
> > > http://michaelgogins.tumblr.com
> > > Michael dot Gogins at gmail dot com
> > >
> > >
> > > On Mon, Oct 7, 2019 at 8:53 AM Oeyvind Brandtsegg
> > <obrandts@gmail.com <mailto:obrandts@gmail.com>
> > > <mailto:obrandts@gmail.com <mailto:obrandts@gmail.com>>>
> > wrote:
> > >
> > > Hi,
> > > Oh, you got me fooled there Joachim. I always thought
> > the capital
> > > second letter was intentional to signify an array.
> > > I also like it very much. And I see now that you have
> > a mixed style
> > > in those examples.
> > > I do think that it would not work as well as a style
> > guide to
> > > suggest that an underscore (or anything) at the end of
> > the name
> > > would suggest the type. Then it could be confused by
> > the type
> > > signifiers :a :k etc already in use. The problem would
> > be that one
> > > would be a suggested style and another would have
> > semantic significance.
> > >
> > > For me this slightly modified version of your code
> > > kfirstEl = kArr[0]
> > > reads very clear.
> > > Or, since we make suggestions for the style, perhaps
> > even avoid the
> > > abbreviation, so it should be
> > > kfirstElement = kArray[0]
> > >
> > > all bEst
> > > Oeyvind
> > >
> > >
> > >
> > > lør. 5. okt. 2019 kl. 09:28 skrev joachim heintz
> > > <jh@joachimheintz.de <mailto:jh@joachimheintz.de>
> > <mailto:jh@joachimheintz.de <mailto:jh@joachimheintz.de>>>:
> > >
> > > thanks for reading and for the feedback!
> > >
> > > i must admit that i have no real idea whether/how
> > we should
> > > distinguish
> > > scalar or signal variable names from array names.
> > what i can
> > > say that
> > > there was no intent to make this distinction in
> > the manual page you
> > > mentioned (as i wrote these examples). for
> > instance in this code
> > > snippet it is already mixed:
> > >
> > > kArr[] init 10 ;with brackets because of
> > > initialization
> > > kLen = lenarray(kArr) ;without brackets
> > > kFirstEl = kArr[0] ;indexing with brackets
> > >
> > > i would not like to reserve the uppercase
> > character after the
> > > i|k|a|s
> > > for arrays.
> > >
> > > would it be an idea to recommend an underscore at
> > the end of an
> > > array
> > > name, or as second character? then we would write
> > > iFreq for an i-variable and
> > > iFreq_ or i_Freq for an array.
> > >
> > > not sure ...
> > >
> > > j
> > >
> > >
> > >
> > > On 04/10/19 23:06, Oeyvind Brandtsegg wrote:
> > > > Wow, that is so nice, Joachim. Thanks!
> > > >
> > > > I have only one question, about the uppercase
> > character after the
> > > > type-specifying leading i|k|a|f.
> > > > For some reason, I had imagined that we used an
> > uppercase
> > > letter as the
> > > > second letter only when we have an array.
> > > > So that
> > > > ifrequency
> > > > is an i-rate variable
> > > > and
> > > > iFrequency
> > > > is an i-rate array
> > > >
> > > > It could be useful to know if it is a number or
> > an array just
> > > by looking
> > > > at the spelling of a variable name.
> > > > I think I got this impression from the manual page
> > > > http://www.csounds.com/manual/html/arrayOpcodes.html
> > > > where the arrays have names with caps on the
> > second letter, but
> > > > variables like kndx are all lowercase.
> > > >
> > > >
> > > >
> > > > fre. 4. okt. 2019 kl. 21:17 skrev joachim heintz
> > > <jh@joachimheintz.de <mailto:jh@joachimheintz.de>
> > <mailto:jh@joachimheintz.de <mailto:jh@joachimheintz.de>>
> > > > <mailto:jh@joachimheintz.de
> > <mailto:jh@joachimheintz.de> <mailto:jh@joachimheintz.de
> > <mailto:jh@joachimheintz.de>>>>:
> > > >
> > > > ok -- i gave it a try:
> > > >
> > >
> > https://github.com/csound/csound/wiki/Writing-Csound-Code-Best%3F!%3F
> > > >
> > > > not sure it was a good idea ... --- perhaps
> > the ways of
> > > writing code
> > > > are
> > > > too different and should remain different ......
> > > >
> > > > anyway: comments and corrections welcome;
> > perhaps we can
> > > at least come
> > > > to some agreement which can go to the website.
> > > >
> > > > best -
> > > > joachim
> > > >
> > > >
> > > >
> > > > On 04/10/19 18:07, joachim heintz wrote:
> > > > > thanks for the links; i think a menu item
> > under
> > > > > csound.com/learn
> > <http://csound.com/learn> <http://csound.com/learn>
> > > <http://csound.com/learn>
> > > > > would be the right place for it.
> > > > >
> > > > > i did some small editings in tarmo's wiki
> > page. i will
> > > try to do more
> > > > > later.
> > > > >
> > > > > joachim
> > > > >
> > > > >
> > > > >
> > > > > On 04/10/19 11:52, Hlöðver Sigurðsson wrote:
> > > > >> I would vote for a style-guide under
> > > > http://github.com/csound/style-guide
> > > > >>
> > > > >> as an inspiration we can look at how it's
> > organized
> > > from these
> > > > >> style-guides
> > > > >>
> > https://github.com/bbatsov/clojure-style-guide
> > > > >>
> > https://github.com/rubocop-hq/ruby-style-guide
> > > > >> https://github.com/airbnb/javascript
> > > > >>
> > > > >>
> > > > >> As for the new vs old syntax. As far as I
> > understand, the
> > > > dispatch type
> > > > >> should be resolved as before
> > > > >> instr 1
> > > > >> kval = poscil(1, 200)
> > > > >> aval = poscil(1, 200)
> > > > >> endin
> > > > >>
> > > > >> and denoting type makes sense in cases as
> > these
> > > > >> instr 1
> > > > >> aval = poscil(poscil:k(1, 200), 200)
> > > > >> endin
> > > > >>
> > > > >> personally I think it's a grammatical
> > unclarity when
> > > you are
> > > > calling a
> > > > >> function without parentheses, it's one of
> > the reasons
> > > so many
> > > > >> programmers avoid ruby.
> > > > >>
> > > > >> On Fri, 4 Oct 2019 at 11:35, Tarmo Johannes
> > > <trmjhnns@gmail.com <mailto:trmjhnns@gmail.com>
> > <mailto:trmjhnns@gmail.com <mailto:trmjhnns@gmail.com>>
> > > > <mailto:trmjhnns@gmail.com
> > <mailto:trmjhnns@gmail.com> <mailto:trmjhnns@gmail.com
> > <mailto:trmjhnns@gmail.com>>>
> > > > >> <mailto:trmjhnns@gmail.com
> > <mailto:trmjhnns@gmail.com> <mailto:trmjhnns@gmail.com
> > <mailto:trmjhnns@gmail.com>>
> > > <mailto:trmjhnns@gmail.com
> > <mailto:trmjhnns@gmail.com> <mailto:trmjhnns@gmail.com
> > <mailto:trmjhnns@gmail.com>>>>> wrote:
> > > > >>
> > > > >> Hi,
> > > > >>
> > > > >>
> > > > >> Very good starting point, Joachim and
> > thanks to
> > > alla suggestions!
> > > > >> I will try to sum them up and start a
> > > work-in-progress "Best
> > > > >> practices" page.
> > > > >> What would be a good environment?
> > Perhaps a wiki
> > > page by csound
> > > > >> github repo?
> > > > >>
> > > > >> Thanks!
> > > > >> Tarmo
> > > > >>
> > > > >>
> > > > >> R, 4. oktoober 2019 11:26 Rory Walsh
> > > <rorywalsh@ear.ie <mailto:rorywalsh@ear.ie>
> > <mailto:rorywalsh@ear.ie <mailto:rorywalsh@ear.ie>>
> > > > <mailto:rorywalsh@ear.ie
> > <mailto:rorywalsh@ear.ie> <mailto:rorywalsh@ear.ie
> > <mailto:rorywalsh@ear.ie>>>
> > > > >> <mailto:rorywalsh@ear.ie
> > <mailto:rorywalsh@ear.ie> <mailto:rorywalsh@ear.ie
> > <mailto:rorywalsh@ear.ie>>
> > > <mailto:rorywalsh@ear.ie <mailto:rorywalsh@ear.ie>
> > <mailto:rorywalsh@ear.ie <mailto:rorywalsh@ear.ie>>>>> kirjutas:
> > > > >>
> > > > >> I think most editor these days
> > have a "use
> > > spaces" instead of
> > > > >> tabs option, where you can set
> > how many spaces are
> > > > inserted on
> > > > >> each tab press. Even Cabbage has
> > this ;) I
> > > prefer more
> > > > that one
> > > > >> space, but any kind of
> > indentation is better
> > > than none in my
> > > > >> opinion. I agree that camelCase
> > between type
> > > and name
> > > > makes the
> > > > >> code easier to read. I would
> > rather gSFiles to
> > > gS_Files, but
> > > > >> there will always be those kinds
> > of niggly
> > > preferences.
> > > > >>
> > > > >> @Eduardo Moguillansky
> > > > >>
> > <mailto:eduardo.moguillansky@gmail.com
> > <mailto:eduardo.moguillansky@gmail.com>
> > > <mailto:eduardo.moguillansky@gmail.com
> > <mailto:eduardo.moguillansky@gmail.com>>
> > > > <mailto:eduardo.moguillansky@gmail.com
> > <mailto:eduardo.moguillansky@gmail.com>
> > > <mailto:eduardo.moguillansky@gmail.com
> > <mailto:eduardo.moguillansky@gmail.com>>>> can you explain more
> > > > >> what you mean about not being
> > able to overload
> > > opcodes
> > > > using the
> > > > >> new syntax? Or give me an
> > example? I've no
> > > doubt you're right
> > > > >> btw, but I had always assumed
> > this was possible?
> > > > >>
> > > > >> On Fri, 4 Oct 2019 at 09:15,
> > Oeyvind Brandtsegg
> > > > >> <obrandts@gmail.com
> > <mailto:obrandts@gmail.com> <mailto:obrandts@gmail.com
> > <mailto:obrandts@gmail.com>>
> > > <mailto:obrandts@gmail.com
> > <mailto:obrandts@gmail.com> <mailto:obrandts@gmail.com
> > <mailto:obrandts@gmail.com>>>
> > > > <mailto:obrandts@gmail.com
> > <mailto:obrandts@gmail.com> <mailto:obrandts@gmail.com
> > <mailto:obrandts@gmail.com>>
> > > <mailto:obrandts@gmail.com
> > <mailto:obrandts@gmail.com> <mailto:obrandts@gmail.com
> > <mailto:obrandts@gmail.com>>>>> wrote:
> > > > >>
> > > > >> Agreed, and I am a sinner to
> > the tabbed
> > > formatting too.
> > > > >> Seeing how the tabs are
> > interpreted
> > > differently by
> > > > different
> > > > >> editors, the mixing of code
> > from different
> > > sources
> > > > may lead
> > > > >> to severe mixup of the
> > once-so-tidy columns.
> > > > >> I think adopting something
> > like the style
> > > used in the
> > > > >> Springer Csound book would be
> > nice.
> > > > >> https://github.com/csound/book
> > > > >> We could discuss details, but
> > it is a
> > > starting point.
> > > > >>
> > > > >> fre. 4. okt. 2019 kl. 09:56
> > skrev Eduardo
> > > Moguillansky
> > > > >>
> > <eduardo.moguillansky@gmail.com
> > <mailto:eduardo.moguillansky@gmail.com>
> > > <mailto:eduardo.moguillansky@gmail.com
> > <mailto:eduardo.moguillansky@gmail.com>>
> > > > <mailto:eduardo.moguillansky@gmail.com
> > <mailto:eduardo.moguillansky@gmail.com>
> > > <mailto:eduardo.moguillansky@gmail.com
> > <mailto:eduardo.moguillansky@gmail.com>>>
> > > > >>
> > <mailto:eduardo.moguillansky@gmail.com
> > <mailto:eduardo.moguillansky@gmail.com>
> > > <mailto:eduardo.moguillansky@gmail.com
> > <mailto:eduardo.moguillansky@gmail.com>>
> > > > <mailto:eduardo.moguillansky@gmail.com
> > <mailto:eduardo.moguillansky@gmail.com>
> > > <mailto:eduardo.moguillansky@gmail.com
> > <mailto:eduardo.moguillansky@gmail.com>>>>>:
> > > > >>
> > > > >> after developing a bunch
> > of opcodes
> > > myself I came to
> > > > >> realize how fantastic the
> > type dispatch
> > > is in csound,
> > > > >> allowing for opcodes to
> > be overloaded
> > > in inputs and
> > > > >> outputs. This is only
> > possible with the
> > > "old"
> > > > syntax and
> > > > >> would require big
> > modifications to
> > > adapt to a
> > > > functional
> > > > >> style. Much more
> > confusing for me when
> > > reading
> > > > code by
> > > > >> others is the way
> > indentation and
> > > spacing is
> > > > used, which
> > > > >> in many cases resembles
> > more that of
> > > assembler
> > > > than any
> > > > >> modern language I know.
> > > > >>
> > > > >> eduardo
> > > > >>
> > > > >> On 04.10.19 09:17, Tarmo
> > Johannes wrote:
> > > > >>> Hi,
> > > > >>>
> > > > >>> Yes, the two syntaxes can be
> > > confusing. But we
> > > > cannot
> > > > >>> do with the old one
> > since for two or
> > > more outputs we
> > > > >>> still need the old one like
> > > > >>>
> > > > >>> aL, aR pan2 aSignal,
> > iPanning
> > > > >>>
> > > > >>> I personally use the
> > inline syntax
> > > only when
> > > > there are
> > > > >>> several opcodes in one line
> > > > >>>
> > > > >>> out poscil::a(0.1,220)
> > > > >>>
> > > > >>> Otherwise old, to be
> > sure how the type
> > > is assigned
> > > > >>> (and avoid the :<type>)
> > > > >>> iNumber random 1, 10
> > > > >>>
> > > > >>> But I agree, using the
> > equotion mark
> > > and new
> > > > syntax is
> > > > >>> more similar to other
> > languages and maths.
> > > > >>>
> > > > >>> What do others think
> > about it? Should
> > > me make
> > > > >>> suggestions?
> > > > >>>
> > > > >>> Tarmo
> > > > >>>
> > > > >>> N, 3. oktoober 2019
> > 23:57 Rory Walsh
> > > > <rorywalsh@ear.ie <mailto:rorywalsh@ear.ie>
> > <mailto:rorywalsh@ear.ie <mailto:rorywalsh@ear.ie>>
> > > <mailto:rorywalsh@ear.ie <mailto:rorywalsh@ear.ie>
> > <mailto:rorywalsh@ear.ie <mailto:rorywalsh@ear.ie>>>
> > > > >>> <mailto:rorywalsh@ear.ie
> > <mailto:rorywalsh@ear.ie>
> > > <mailto:rorywalsh@ear.ie <mailto:rorywalsh@ear.ie>>
> > > > <mailto:rorywalsh@ear.ie
> > <mailto:rorywalsh@ear.ie> <mailto:rorywalsh@ear.ie
> > <mailto:rorywalsh@ear.ie>>>>>
> > > kirjutas:
> > > > >>>
> > > > >>> This is a good
> > point. I recently
> > > starting using
> > > > >>> functional syntax
> > with a class of
> > > mine. For the
> > > > >>> ones who programmed
> > before it made
> > > far more
> > > > sense
> > > > >>> to see:
> > > > >>>
> > > > >>> kOsc = oscil:k(1, 10)
> > > > >>>
> > > > >>> For the ones who
> > have never
> > > programmed before it
> > > > >>> made just as little
> > sense as what
> > > we were doing
> > > > >>> before! It made me
> > think about why
> > > I don't just
> > > > >>> switch to this
> > modern syntax
> > > entirely. I
> > > > guess the
> > > > >>> main reason, for me
> > at least, is
> > > the body of
> > > > work
> > > > >>> that exists which
> > was written in
> > > the 'old'
> > > > style.
> > > > >>> I'm concerned that
> > students
> > > looking to old works
> > > > >>> would end up
> > wondering if they are
> > > actually
> > > > >>> looking at the same
> > language as
> > > the one they are
> > > > >>> learning in class.
> > But I have to
> > > say, in my
> > > > >>> opinion it is more
> > readable this way.
> > > > >>>
> > > > >>> So who's going to
> > ask Menno to
> > > rewrite all the
> > > > >>> examples using
> > modern syntax
> > > > >>>
> > > > >>>
> > > > >>>
> > > > >>>
> > > > >>> On Thu, 3 Oct 2019
> > at 21:03, Tarmo
> > > Johannes
> > > > >>> <trmjhnns@gmail.com
> > <mailto:trmjhnns@gmail.com>
> > > <mailto:trmjhnns@gmail.com
> > <mailto:trmjhnns@gmail.com>>
> > > > <mailto:trmjhnns@gmail.com
> > <mailto:trmjhnns@gmail.com> <mailto:trmjhnns@gmail.com
> > <mailto:trmjhnns@gmail.com>>>
> > > <mailto:trmjhnns@gmail.com
> > <mailto:trmjhnns@gmail.com> <mailto:trmjhnns@gmail.com
> > <mailto:trmjhnns@gmail.com>>
> > > > <mailto:trmjhnns@gmail.com
> > <mailto:trmjhnns@gmail.com> <mailto:trmjhnns@gmail.com
> > <mailto:trmjhnns@gmail.com>>>>>
> > > > >>> wrote:
> > > > >>>
> > > > >>> Hi!
> > > > >>>
> > > > >>> As continuation
> > to the
> > > discussion about more
> > > > >>> examples and
> > updated manual -
> > > it is clear
> > > > >>> that is also
> > important to
> > > strive for as
> > > > >>> readable code as
> > possible.
> > > > >>>
> > > > >>> Should we think
> > to write down
> > > something like
> > > > >>> "Best practices"
> > or there are
> > > too many
> > > > >>> approaches? I
> > mean like "use
> > > camelCase,
> > > > >>> readable names
> > of variables,
> > > first letter
> > > > >>> after i/k/a is
> > uppercase, use
> > > tabs to indent
> > > > >>> lines between if
> > and endif?"
> > > > >>>
> > > > >>> If we settle
> > some suggestions
> > > before major
> > > > >>> examples/manual
> > update, it
> > > could be good
> > > > >>> point to improve
> > the code
> > > culture and
> > > > >>> readability? I
> > think big part
> > > of the
> > > > examples
> > > > >>> is from time
> > when wasting as
> > > little ASCII
> > > > >>> symbols for the
> > code was a
> > > good thing to
> > > > do...
> > > > >>>
> > > > >>> kprkt linseg
> > kbgn, kdr1, kpt2,
> > > kdrxtr, kooo
> > > > >>>
> > > > >>> Greetings,
> > > > >>> tarmo
> > > > >>> Csound mailing list
> > > > Csound@listserv.heanet.ie
> > <mailto:Csound@listserv.heanet.ie>
> > > <mailto:Csound@listserv.heanet.ie
> > <mailto:Csound@listserv.heanet.ie>>
> > > <mailto:Csound@listserv.heanet.ie
> > <mailto:Csound@listserv.heanet.ie>
> > > <mailto:Csound@listserv.heanet.ie
> > <mailto:Csound@listserv.heanet.ie>>>
> > > > >>>
> > > <mailto:Csound@listserv.heanet.ie
> > <mailto:Csound@listserv.heanet.ie>
> > > <mailto:Csound@listserv.heanet.ie
> > <mailto:Csound@listserv.heanet.ie>>
> > > > <mailto:Csound@listserv.heanet.ie
> > <mailto:Csound@listserv.heanet.ie>
> > > <mailto:Csound@listserv.heanet.ie
> > <mailto:Csound@listserv.heanet.ie>>>>
> > > > >>>
> > > > >>>
> > https://listserv.heanet.ie/cgi-bin/wa?A0=CSOUND Send
> > > > >>> bugs reports to
> > > > >>>
> > > https://github.com/csound/csound/issues
> > > > >>> Discussions of
> > bugs and
> > > features can be
> > > > posted
> > > > >>> here
> > > > >>>
> > > > >>> Csound mailing list
> > > > Csound@listserv.heanet.ie
> > <mailto:Csound@listserv.heanet.ie>
> > > <mailto:Csound@listserv.heanet.ie
> > <mailto:Csound@listserv.heanet.ie>>
> > > <mailto:Csound@listserv.heanet.ie
> > <mailto:Csound@listserv.heanet.ie>
> > > <mailto:Csound@listserv.heanet.ie
> > <mailto:Csound@listserv.heanet.ie>>>
> > > > >>>
> > <mailto:Csound@listserv.heanet.ie
> > <mailto:Csound@listserv.heanet.ie>
> > > <mailto:Csound@listserv.heanet.ie
> > <mailto:Csound@listserv.heanet.ie>>
> > > > <mailto:Csound@listserv.heanet.ie
> > <mailto:Csound@listserv.heanet.ie>
> > > <mailto:Csound@listserv.heanet.ie
> > <mailto:Csound@listserv.heanet.ie>>>>
> > > > >>>
> > > https://listserv.heanet.ie/cgi-bin/wa?A0=CSOUND
> > > > >>> Send bugs reports to
> > > > >>>
> > > https://github.com/csound/csound/issues
> > > > >>> Discussions of bugs
> > and features
> > > can be
> > > > posted here
> > > > >>>
> > > > >>> Csound mailing list
> > > Csound@listserv.heanet.ie
> > <mailto:Csound@listserv.heanet.ie>
> > <mailto:Csound@listserv.heanet.ie
> > <mailto:Csound@listserv.heanet.ie>>
> > > > <mailto:Csound@listserv.heanet.ie
> > <mailto:Csound@listserv.heanet.ie>
> > > <mailto:Csound@listserv.heanet.ie
> > <mailto:Csound@listserv.heanet.ie>>>
> > > > >>>
> > <mailto:Csound@listserv.heanet.ie
> > <mailto:Csound@listserv.heanet.ie>
> > > <mailto:Csound@listserv.heanet.ie
> > <mailto:Csound@listserv.heanet.ie>>
> > > > <mailto:Csound@listserv.heanet.ie
> > <mailto:Csound@listserv.heanet.ie>
> > > <mailto:Csound@listserv.heanet.ie
> > <mailto:Csound@listserv.heanet.ie>>>>
> > > > >>>
> > > https://listserv.heanet.ie/cgi-bin/wa?A0=CSOUND Send
> > > > >>> bugs reports to
> > > > >>>
> > https://github.com/csound/csound/issues
> > > > Discussions of
> > > > >>> bugs and features can be
> > posted here
> > > > >> Csound mailing list
> > > Csound@listserv.heanet.ie
> > <mailto:Csound@listserv.heanet.ie>
> > <mailto:Csound@listserv.heanet.ie
> > <mailto:Csound@listserv.heanet.ie>>
> > > > <mailto:Csound@listserv.heanet.ie
> > <mailto:Csound@listserv.heanet.ie>
> > > <mailto:Csound@listserv.heanet.ie
> > <mailto:Csound@listserv.heanet.ie>>>
> > > > >>
> > <mailto:Csound@listserv.heanet.ie
> > <mailto:Csound@listserv.heanet.ie>
> > > <mailto:Csound@listserv.heanet.ie
> > <mailto:Csound@listserv.heanet.ie>>
> > > > <mailto:Csound@listserv.heanet.ie
> > <mailto:Csound@listserv.heanet.ie>
> > > <mailto:Csound@listserv.heanet.ie
> > <mailto:Csound@listserv.heanet.ie>>>>
> > > > >>
> > > <A hr
|