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

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

i think it is a good point, and i like the word suggestion in this context.

as to functional syntax: i sometimes ask my students what they prefer, 
and the result is similar to what rory reported.  the ones who already 
know a programming language prefer the functional style, the others 
prefer the "old style".

so i think both styles should be supported in a "best practice" 
suggestion.  and actually the old style is very readable, if well written.

to start with some points:
1. use meaningful names for the variables
	aLeft, aRight pan2 aWhiteNoise, kPan
	instead of
	a1, a2 pan2 asig, kdontknow
2. use uppercase or underscore to make variable names more meaningful:
	gS_files[] directory .
	instead of
	gSfiles[] directory
3. transform p-field numbers into meaningful i-variables:
	iPchMidi = p4
	iVolDb = p5
	aSine poscil ampdb(iVolDb), mtof(iPchMidi)
	instead of
	aSine poscil ampdb(p5), mtof(p4)
4. use meaningful instrument names rather than numbers.
5. use indendation to make blocks visible.  in the springer book, victor 
suggested to indent the instrument code by one space, and i use it since 
then.  also i think spaces are preferable to tabs, because tabs can be 
different in each editor, but spaces are not (if you use the proper 
font). so:
instr Trigger
  if ...
   do something ...
  endif
endin
6. use user defined opcodes as much as possible (look at steven's code 
for live csound).
compare
	giBeats loadSample("beats.wav")
to
	giBeats ftgen 0, 0, 0, -1, "beats.wav", 0, 0, 0
(where loadSample is defined as
	opcode loadSample, i, S
	 S_file xin
	 iNum ftgen 0, 0, 0, -1, S_file, 0, 0, 0
	 xout iNum
	endop

uff -- i did not expect me to right so long ...

	joachim


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 :)
> 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  > 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      > 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
>         
>         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
>     
>     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
> 
> 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
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

6. use user defined opcodes as much as possible (look at steven's code for live csound).
compare
    giBeats loadSample("beats.wav")
to
    giBeats ftgen 0, 0, 0, -1, "beats.wav", 0, 0, 0
(where loadSample is defined as
    opcode loadSample, i, S
     S_file xin
     iNum ftgen 0, 0, 0, -1, S_file, 0, 0, 0
     xout iNum
    endop

I agree with this and brings for me to the question: should we not think about an import mechanism, more robust than #include, together with a minimal "standard library" of user defined opcodes distributed together with csound? This last point is important because only so could we rely on it being always available.

#import std/table loadSound, emptyTable

giSample loadSound "sample.wav"

instr ...
  iTable = emptyTable(1024)
  ...
endin

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

Hi,

I find that I don't like using the new functional syntax because it doesn't work with opcodes with more than one output. I don't like mixing styles.

It would be great in the future to have the functional style implemented for opcodes with more than one output.

Javascript does object destructuring for ordered elements like this:

cost [element1, element2] = orderedObject;

perhaps in Csound something like:

[aOutL, aOutR] = diskin2(arg1, arg2....) would work?

Also in regards style guide I have found things like Clang Format, Prettier (Javascript) to be extremely helpful. Having an auto format tool that formats everything on save would be fantastic, I'm not sure how these are built, but I assume any work on parsing done for syntax highlighting would help in this regard?

Just some thoughts anyway,

Thanks

Ed

On Fri, 4 Oct 2019 at 12:32, Tarmo Johannes <trmjhnns@gmail.com> wrote:

Hi,

for editing and to get started I created wiki page:

https://github.com/csound/csound/wiki/Best-Practices-for-Writing-Csound-Code

I copied in Joachim's suggestions and added something but did not have time yet to finish it.

What concerns

  kval = poscil(1, 200)
  aval = poscil(1, 200)

I think in this case the type is not assigned automatically - probably the default type is returned and this can be source for nasty problems. Have not tested, though...

I would suggest rather  "ALWAYS set a type in function like syntax).

Greetings,

tarmo

Kontakt Hlöðver Sigurðsson (<hlolli@gmail.com>) kirjutas kuupäeval R, 4. oktoober 2019 kell 12:52:

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

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

Hi,

And is the extra assignment optimized somehow? I mean, I've used and I
like things like this:

  aVar poscil poscil:k(1, 200), 200

However, if there's no optimization, I wouldn't think the following
should be considered a "good practice" since the old style would
actually be more efficient in this case:

  kOsc = oscil:k(1, 10)


Cheers.


On 4/10/19 10:06, Victor Lazzarini wrote:
> It's in Steven's new parser.
>
> Prof. Victor Lazzarini
> Maynooth University
> Ireland
>
> On 4 Oct 2019, at 14:03, Ed Costello > wrote:
>
> Hi,
> I find that I don't like using the new functional syntax because it doesn't work with opcodes with more than one output. I don't like mixing styles.
> It would be great in the future to have the functional style implemented for opcodes with more than one output.
> Javascript does object destructuring for ordered elements like this:
>
> cost [element1, element2] = orderedObject;
>
> perhaps in Csound something like:
>
> [aOutL, aOutR] = diskin2(arg1, arg2....) would work?
>
> Also in regards style guide I have found things like Clang Format, Prettier (Javascript) to be extremely helpful. Having an auto format tool that formats everything on save would be fantastic, I'm not sure how these are built, but I assume any work on parsing done for syntax highlighting would help in this regard?
> Just some thoughts anyway,
> Thanks
> Ed
>
> On Fri, 4 Oct 2019 at 12:32, Tarmo Johannes > wrote:
> Hi,
>
> for editing and to get started I created wiki page:
> https://github.com/csound/csound/wiki/Best-Practices-for-Writing-Csound-Code
>
>
> I copied in Joachim's suggestions and added something but did not have time yet to finish it.
>
>
> What concerns
>
>   kval = poscil(1, 200)
>   aval = poscil(1, 200)
>
> I think in this case the type is not assigned automatically - probably the default type is returned and this can be source for nasty problems. Have not tested, though...
> I would suggest rather  "ALWAYS set a type in function like syntax).
>
> Greetings,
> tarmo
>
>
>
>
> Kontakt Hlöðver Sigurðsson (>) kirjutas kuupäeval R, 4. oktoober 2019 kell 12:52:
> 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 > 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 > 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 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 > 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 >:
>
> 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 :)
> 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 > 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 > 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 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 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 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 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 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 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 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 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 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 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
> 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
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

thanks for the links; i think a menu item under
	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  > 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      > 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
>          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
>         > 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
>                          >:
>
>                 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 :)
>>                 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 >                 > 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
>>                     >
>>                     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
>>                         
>>                         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
>>                     
>>                     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
>>                 
>>                 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
>                 
>                 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
>             
>             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
>         
>         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
>     
>     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
> 
> 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
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

I thought that was optimised with the extra assignmemt removed.  Is that 
do the case?

On Fri, 4 Oct 2019, Guillermo Senna wrote:

> Hi,
>
> And is the extra assignment optimized somehow? I mean, I've used and I
> like things like this:
>
>  aVar poscil poscil:k(1, 200), 200
>
> However, if there's no optimization, I wouldn't think the following
> should be considered a "good practice" since the old style would
> actually be more efficient in this case:
>
>  kOsc = oscil:k(1, 10)
>
>
> Cheers.
>

Csound mailing list
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

i like this import idea --- perhaps add it under the csound7 suggestions?
https://github.com/csound/csound/issues?q=is%3Aopen+is%3Aissue+milestone%3A7.0.0



On 04/10/19 10:24, Eduardo Moguillansky wrote:
>
>> 6. use user defined opcodes as much as possible (look at steven's code
>> for live csound).
>> compare
>>     giBeats loadSample("beats.wav")
>> to
>>     giBeats ftgen 0, 0, 0, -1, "beats.wav", 0, 0, 0
>> (where loadSample is defined as
>>     opcode loadSample, i, S
>>      S_file xin
>>      iNum ftgen 0, 0, 0, -1, S_file, 0, 0, 0
>>      xout iNum
>>     endop
>>
>
> I agree with this and brings for me to the question: should we not think
> about an import mechanism, more robust than #include, together with a
> minimal "standard library" of user defined opcodes distributed together
> with csound? This last point is important because only so could we rely
> on it being always available.
>
> #import std/table loadSound, emptyTable
>
> giSample loadSound "sample.wav"
>
> instr ...
>   iTable = emptyTable(1024)
>   ...
> endin
>
> this would look at a file std/table.udo inside $INCDIR and would only
> make the opcodes "loadSound" and "emptyTable" available inside the .csd.
>
> ---
> 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
>>> :)
>>> 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 >> > 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 >>     > 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
>>>         
>>>         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
>>>     
>>>     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
>>> 
>>> 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
>> 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
> 
> 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
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

I don't think so.

Prof. Victor Lazzarini
Maynooth University
Ireland

> On 4 Oct 2019, at 17:12, john  wrote:
> 
> I thought that was optimised with the extra assignmemt removed.  Is that do the case?
> 
>> On Fri, 4 Oct 2019, Guillermo Senna wrote:
>> 
>> Hi,
>> 
>> And is the extra assignment optimized somehow? I mean, I've used and I
>> like things like this:
>> 
>> aVar poscil poscil:k(1, 200), 200
>> 
>> However, if there's no optimization, I wouldn't think the following
>> should be considered a "good practice" since the old style would
>> actually be more efficient in this case:
>> 
>> kOsc = oscil:k(1, 10)
>> 
>> 
>> Cheers.
>> 
> 
> Csound mailing list
> 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
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

Looks like no assignment to me

instr 1
avar poscil poscil:k(1, 200), 200
out avar
endin

gives

poscil.kk args: #k0     1       200     -1      0
poscil.a args:  avar    #k0     200     -1      0
out.a args:     avar

ow could that be optimised?


On Fri, 4 Oct 2019, Victor Lazzarini wrote:

> I don't think so.
>
> Prof. Victor Lazzarini
> Maynooth University
> Ireland
>
>> On 4 Oct 2019, at 17:12, john  wrote:
>>
>> I thought that was optimised with the extra assignmemt removed.  Is that do the case?
>>
>>> On Fri, 4 Oct 2019, Guillermo Senna wrote:
>>>
>>> Hi,
>>>
>>> And is the extra assignment optimized somehow? I mean, I've used and I
>>> like things like this:
>>>
>>> aVar poscil poscil:k(1, 200), 200
>>>
>>> However, if there's no optimization, I wouldn't think the following
>>> should be considered a "good practice" since the old style would
>>> actually be more efficient in this case:
>>>
>>> kOsc = oscil:k(1, 10)
>>>
>>>
>>> Cheers.
>>>
>>
>> Csound mailing list
>> 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
> 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
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

I thought the question was

a1 = poscil(...)

which *I think* gets translated as

##a0 poscil ...
a1 = ##a0

but it might have changed

Prof. Victor Lazzarini
Maynooth University
Ireland

> On 4 Oct 2019, at 17:53, john  wrote:
> 
> Looks like no assignment to me
> 
> instr 1
> avar poscil poscil:k(1, 200), 200
> out avar
> endin
> 
> gives
> 
> poscil.kk args: #k0     1       200     -1      0
> poscil.a args:  avar    #k0     200     -1      0
> out.a args:     avar
> 
> ow could that be optimised?
> 
> 
>> On Fri, 4 Oct 2019, Victor Lazzarini wrote:
>> 
>> I don't think so.
>> 
>> Prof. Victor Lazzarini
>> Maynooth University
>> Ireland
>> 
>>> On 4 Oct 2019, at 17:12, john  wrote:
>>> 
>>> I thought that was optimised with the extra assignmemt removed.  Is that do the case?
>>> 
>>>> On Fri, 4 Oct 2019, Guillermo Senna wrote:
>>>> 
>>>> Hi,
>>>> 
>>>> And is the extra assignment optimized somehow? I mean, I've used and I
>>>> like things like this:
>>>> 
>>>> aVar poscil poscil:k(1, 200), 200
>>>> 
>>>> However, if there's no optimization, I wouldn't think the following
>>>> should be considered a "good practice" since the old style would
>>>> actually be more efficient in this case:
>>>> 
>>>> kOsc = oscil:k(1, 10)
>>>> 
>>>> 
>>>> Cheers.
>>>> 
>>> 
>>> Csound mailing list
>>> 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
>> 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
> 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
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

Indeed. Sorry if I worded it wrong. I was trying to say that I like
functional syntax, but in the case Rory posted (unless there is some
hidden optimization in place) the following line implies an extra
assignment when compared to the old style:

kOsc = oscil:k(1, 10)


On 4/10/19 13:58, Victor Lazzarini wrote:
> I thought the question was
>
> a1 = poscil(...)
>
> which *I think* gets translated as
>
> ##a0 poscil ...
> a1 = ##a0
>
> but it might have changed
>
> Prof. Victor Lazzarini
> Maynooth University
> Ireland
>
>> On 4 Oct 2019, at 17:53, john  wrote:
>>
>> Looks like no assignment to me
>>
>> instr 1
>> avar poscil poscil:k(1, 200), 200
>> out avar
>> endin
>>
>> gives
>>
>> poscil.kk args: #k0     1       200     -1      0
>> poscil.a args:  avar    #k0     200     -1      0
>> out.a args:     avar
>>
>> ow could that be optimised?
>>
>>
>>> On Fri, 4 Oct 2019, Victor Lazzarini wrote:
>>>
>>> I don't think so.
>>>
>>> Prof. Victor Lazzarini
>>> Maynooth University
>>> Ireland
>>>
>>>> On 4 Oct 2019, at 17:12, john  wrote:
>>>>
>>>> I thought that was optimised with the extra assignmemt removed.  Is that do the case?
>>>>
>>>>> On Fri, 4 Oct 2019, Guillermo Senna wrote:
>>>>>
>>>>> Hi,
>>>>>
>>>>> And is the extra assignment optimized somehow? I mean, I've used and I
>>>>> like things like this:
>>>>>
>>>>> aVar poscil poscil:k(1, 200), 200
>>>>>
>>>>> However, if there's no optimization, I wouldn't think the following
>>>>> should be considered a "good practice" since the old style would
>>>>> actually be more efficient in this case:
>>>>>
>>>>> kOsc = oscil:k(1, 10)
>>>>>
>>>>>
>>>>> Cheers.
>>>>>
>>>> Csound mailing list
>>>> 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
>>> 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
>> 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
> 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
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

Thanks Tarmo for getting that wiki page started!

Some thoughts below:

I'd mention the CS7 parser code I did optimized away the last
assignment in code like this:

avar = poscil(...)
kvar = poscil(...)

to become more like

avar poscil ...
kvar poscil ...

Which also allowed for:

a1, a2 = someOpcode()

to work.

I tend to use snake_case for a lot of variable names these days, but
use camel case in the past.  Example of code style I use is at:

https://github.com/kunstmusik/csound-live-code/blob/master/livecode.orc

which I think reads pretty well.  I also tend to use lots of += and *=
in my coding these days.  When there are multiple signals to sum or
multiply, it isn't as efficient in processing as using sum or mul
opcodes, but I find it easier to experiment with.

I also find the newer-style code great for experimenting due to
expressions. So I tell students that static values can be replaced
with dynamic ones, changing something like:

asig = vco2(p5, p4)
asig = zdf_ladder(asig, 4000, 4)

to

asig = vco2(p5, p4)
asig = zdf_ladder(asig, expon:a(4000, p3, 100), 4)

Opcode resolution on out-types for expressions was discussed a bit
during CS6 development. We figured type inference would be necessary
(Hindley-Milner or variant) which became out of scope, hence the :type
addition for explicit choosing of opcode variant for that phase. I'd
favor not overloading opcodes as much moving forward where the opcode
version is dependent on the output type, but at least there is a plan
for doing something about this.


On Fri, Oct 4, 2019 at 12:58 PM Victor Lazzarini  wrote:
>
> I thought the question was
>
> a1 = poscil(...)
>
> which *I think* gets translated as
>
> ##a0 poscil ...
> a1 = ##a0
>
> but it might have changed
>
> Prof. Victor Lazzarini
> Maynooth University
> Ireland
>
> > On 4 Oct 2019, at 17:53, john  wrote:
> >
> > Looks like no assignment to me
> >
> > instr 1
> > avar poscil poscil:k(1, 200), 200
> > out avar
> > endin
> >
> > gives
> >
> > poscil.kk args: #k0     1       200     -1      0
> > poscil.a args:  avar    #k0     200     -1      0
> > out.a args:     avar
> >
> > ow could that be optimised?
> >
> >
> >> On Fri, 4 Oct 2019, Victor Lazzarini wrote:
> >>
> >> I don't think so.
> >>
> >> Prof. Victor Lazzarini
> >> Maynooth University
> >> Ireland
> >>
> >>> On 4 Oct 2019, at 17:12, john  wrote:
> >>>
> >>> I thought that was optimised with the extra assignmemt removed.  Is that do the case?
> >>>
> >>>> On Fri, 4 Oct 2019, Guillermo Senna wrote:
> >>>>
> >>>> Hi,
> >>>>
> >>>> And is the extra assignment optimized somehow? I mean, I've used and I
> >>>> like things like this:
> >>>>
> >>>> aVar poscil poscil:k(1, 200), 200
> >>>>
> >>>> However, if there's no optimization, I wouldn't think the following
> >>>> should be considered a "good practice" since the old style would
> >>>> actually be more efficient in this case:
> >>>>
> >>>> kOsc = oscil:k(1, 10)
> >>>>
> >>>>
> >>>> Cheers.
> >>>>
> >>>
> >>> Csound mailing list
> >>> 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
> >> 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
> > 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
> 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
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

That should disappear in the next version of the parser.

Prof. Victor Lazzarini
Maynooth University
Ireland

> On 4 Oct 2019, at 18:14, Guillermo Senna  wrote:
> 
> Indeed. Sorry if I worded it wrong. I was trying to say that I like
> functional syntax, but in the case Rory posted (unless there is some
> hidden optimization in place) the following line implies an extra
> assignment when compared to the old style:
> 
> kOsc = oscil:k(1, 10)
> 
> 
>> On 4/10/19 13:58, Victor Lazzarini wrote:
>> I thought the question was
>> 
>> a1 = poscil(...)
>> 
>> which *I think* gets translated as
>> 
>> ##a0 poscil ...
>> a1 = ##a0
>> 
>> but it might have changed
>> 
>> Prof. Victor Lazzarini
>> Maynooth University
>> Ireland
>> 
>>> On 4 Oct 2019, at 17:53, john  wrote:
>>> 
>>> Looks like no assignment to me
>>> 
>>> instr 1
>>> avar poscil poscil:k(1, 200), 200
>>> out avar
>>> endin
>>> 
>>> gives
>>> 
>>> poscil.kk args: #k0     1       200     -1      0
>>> poscil.a args:  avar    #k0     200     -1      0
>>> out.a args:     avar
>>> 
>>> ow could that be optimised?
>>> 
>>> 
>>>> On Fri, 4 Oct 2019, Victor Lazzarini wrote:
>>>> 
>>>> I don't think so.
>>>> 
>>>> Prof. Victor Lazzarini
>>>> Maynooth University
>>>> Ireland
>>>> 
>>>>> On 4 Oct 2019, at 17:12, john  wrote:
>>>>> 
>>>>> I thought that was optimised with the extra assignmemt removed.  Is that do the case?
>>>>> 
>>>>>> On Fri, 4 Oct 2019, Guillermo Senna wrote:
>>>>>> 
>>>>>> Hi,
>>>>>> 
>>>>>> And is the extra assignment optimized somehow? I mean, I've used and I
>>>>>> like things like this:
>>>>>> 
>>>>>> aVar poscil poscil:k(1, 200), 200
>>>>>> 
>>>>>> However, if there's no optimization, I wouldn't think the following
>>>>>> should be considered a "good practice" since the old style would
>>>>>> actually be more efficient in this case:
>>>>>> 
>>>>>> kOsc = oscil:k(1, 10)
>>>>>> 
>>>>>> 
>>>>>> Cheers.
>>>>>> 
>>>>> Csound mailing list
>>>>> 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
>>>> 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
>>> 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
>> 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
> 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
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

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
> 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 > > 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 >     > 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
>>          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
>>         > 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
>>             >             >:
>>
>>                 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 :)
>>>                 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 >>                 > 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
>>>                     >
>>>                     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
>>>                         
>>>
>>> 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
>>>                     
>>>                     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
>>>                 
>>>                 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
>>                 
>>                 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
>>             
>>             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
>>         
>>         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
>>     
>>     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
>> 
>> 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
> 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
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

thanks rory.  if this is more or less agreed, i can add a new item for 
the website, as hlödver suggested.  and after testing all the code which 
i just wrote off my head ...



On 04/10/19 20:29, Rory Walsh wrote:
> This looks great Joachim. Maybe a link from the website would be nice
> too. Thanks for this.
>
> On Fri 4 Oct 2019, 21:17 joachim heintz,  > wrote:
>
>     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 
>     > 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      
>     >> >> 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      
>     >>     >> 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
>     >>              > 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
>     >>         
>     >> 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
>     >>                  
>     >>                  >>:
>     >>
>     >>                 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 :)
>     >>>                 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
>     
>     >>>                      >> 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
>     >>>                                >>
>     >>>                     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 
>     >>>                              >
>     >>>
>     >>> 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 
>     >>>                          >
>     >>>                     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
>     
>     >>>                      >
>     >>>                 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
>     
>     >>                      >
>     >>                 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
>     
>     >>                  >
>     >>             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
>     
>     >>              >
>     >>         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
>     
>     >>          >
>     >>     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
>     
>     >> >
>     >> 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 
>     > 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 
>     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
> 
> 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
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

instr 1
avar = poscil(poscil:k(1, 200), 200)
kk = poscil:k(1,10)
out avar
endin

gives

poscil.kk args: #k0     1       200     -1      0
poscil.a args:  avar    #k0     200     -1      0
poscil.kk args: kk      1       10      -1      0
out.a args:     avar


I see no assignment


Sorry to be annoying but thisas changed soe time back when a few cases 
were found not to work

Csound mailing list
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

I could not parse the page's title.  What does it mean?


It was too slow to actually read ore than the firt few lines but I 
disagree so much with what little I read.....

Csound mailing list
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

Then it's already correct. I must have missed the change, because last time I looked it was in the form I showed.

Prof. Victor Lazzarini
Maynooth University
Ireland

> On 4 Oct 2019, at 20:53, john  wrote:
> 
> instr 1
> avar = poscil(poscil:k(1, 200), 200)
> kk = poscil:k(1,10)
> out avar
> endin
> 
> gives
> 
> poscil.kk args: #k0     1       200     -1      0
> poscil.a args:  avar    #k0     200     -1      0
> poscil.kk args: kk      1       10      -1      0
> out.a args:     avar
> 
> 
> I see no assignment
> 
> 
> Sorry to be annoying but thisas changed soe time back when a few cases were found not to work
> 
> Csound mailing list
> 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
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

That's interesting... Where is this functional syntax documented? I've been using Csound, signed up to the mailing list and reading the manual for 6 or so years now and never saw anything suggesting that you can do this with the opcodes

Pete

On Fri, 4 Oct 2019, 20:35 joachim heintz, <jh@joachimheintz.de> wrote:

thanks rory.  if this is more or less agreed, i can add a new item for
the website, as hlödver suggested.  and after testing all the code which
i just wrote off my head ...



On 04/10/19 20:29, Rory Walsh wrote:
> This looks great Joachim. Maybe a link from the website would be nice
> too. Thanks for this.
>
> On Fri 4 Oct 2019, 21:17 joachim heintz, <jh@joachimheintz.de
> <mailto:jh@joachimheintz.de>> wrote:
>
>     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>
>     > 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>>> 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>>> 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>> 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>>> 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>>>:
>     >>
>     >>                 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>>> 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>>>
>     >>>                     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>>
>     >>>
>     >>> 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>>
>     >>>                     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>>
>     >>>                 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>>
>     >>                 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>>
>     >>             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>>
>     >>         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>>
>     >>     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>>
>     >> 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>
>     > 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>
>     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>
> 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
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 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

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

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

It's no wonder I've not ever seen that. It's burried deep in the monolithic manual, in a section already far enough in that I only go there when seeking specific info, but not in the main opcodes section so it's not a frequent visit... You should definitely make this more obvious, I'd have used this for a long time if I'd known. I'm currently on the verge of ditching Csound because of the archaic inflexible syntax... Might give this a try before I make that call.

On Fri, 4 Oct 2019, 22:15 Victor Lazzarini, <Victor.Lazzarini@mu.ie> wrote:

That is the naming style I prefer, to mark arrays more clearly.

Prof. Victor Lazzarini

Maynooth University

Ireland

On 4 Oct 2019, at 22:07, Oeyvind Brandtsegg <obrandts@gmail.com> 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>:

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

i agree.  i already softened the tone compared to what i read in the 
links hlödver has sent from other language guides, but i think it should 
be even softer and less prescriptive in some points.  actually, i don't 
like prescriptions at all ... these should be recommendations.

what i experience in teaching is indeed that giving names to instruments 
is better for the students, because it helps them to understand what in 
instrument does.  but this is not your case, of course ...

	j



On 04/10/19 23:14, Victor Lazzarini wrote:
> I am not so sure about instrument names, to be honest. I much prefer
> numbers, which can be dealt with programmatically, and are better for
> identifying instances. Having to insert names under quotes to
> instantiate them is ugly to me, as well.
>
> So I do not really agree with that part of the style guide. Maybe the
> tone should be softened. I certainly would not teach my students that
> names are better than numbers.
>
> Prof. Victor Lazzarini
> Maynooth University
> Ireland
>
> On 4 Oct 2019, at 22:07, 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 > >:
>>
>>     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 
>>     > 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 >     
>>     >> >> 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 >     
>>     >>     >> 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
>>     >>         >     > 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
>>     >>         
>>     >> 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
>>     >>             >     
>>     >>             >     >>:
>>     >>
>>     >>                 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 :)
>>     >>>                 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
>>     
>>     >>>                 >     >> 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
>>     >>>                     >      >     >>
>>     >>>                     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 
>>     >>>                         >     >
>>     >>>
>>     >>> 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 
>>     >>>                     >     >
>>     >>>
>>      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
>>     
>>     >>>                 >     >
>>     >>>
>>      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
>>     
>>     >>                 >     >
>>     >>                 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
>>     
>>     >>             >     >
>>     >>             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
>>     
>>     >>         >     >
>>     >>         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
>>     
>>     >>     >     >
>>     >>     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
>>     
>>     >> >     >
>>     >> 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 
>>     > 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 
>>     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
>> 
>> 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
> 
> 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
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

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  >:
>
>     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 
>     > 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      
>     >> >> 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      
>     >>     >> 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
>     >>              > 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
>     >>         
>     >> 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
>     >>                  
>     >>                  >>:
>     >>
>     >>                 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 :)
>     >>>                 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
>     
>     >>>                      >> 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
>     >>>                                >>
>     >>>                     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 
>     >>>                              >
>     >>>
>     >>> 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 
>     >>>                          >
>     >>>                     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
>     
>     >>>                      >
>     >>>                 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
>     
>     >>                      >
>     >>                 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
>     
>     >>                  >
>     >>             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
>     
>     >>              >
>     >>         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
>     
>     >>          >
>     >>     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
>     
>     >> >
>     >> 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 
>     > 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 
>     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
> 
> 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
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

i had a similar question and got an answer:
https://listserv.heanet.ie/cgi-bin/wa?A2=ind1903&L=CSOUND-DEV&P=16141

so, if it is still the same: currently we must write explicitely :a or 
:k when we use the functional style.

	j



On 05/10/19 04:03, Pete Goodeve wrote:
> On Fri, Oct 04, 2019 at 08:29:04PM -0400, Justin Rosander wrote:
>> Thanks for this resource.  Now I have a question on this thing I’ve been seeing in code “:a” and “:k”.  Aren’t the respective variable types determined by denoting on the outtype “a” or “k” (like “aout” or “kout”).  Why indicate this again after a colon?
>>
> Another non-expert here (:-/) but I think that in cases where the output type
> is determined by the output variable, therer is still no need for a colon.
> e.g.:
>
>   aout = poscil(kamp, kfreq)
>
> is still fine.  It's when the opcode is 'embedded' that you may need to
> be more specific.  As in the example given earlier:
>
>>>> instr 1
>>>>   aval = poscil(poscil:k(1, 200), 200)
>>>> endin
>>>>
>
>  -- (The other) Pete --
>
> Csound mailing list
> 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
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

yes.

On 05/10/19 14:31, Justin Rosander wrote:
> Alright, so the “functional style” encloses the arguments in
> comma-separated values in parenthesis, and the “non-functional style” is
> the old style of doing things?
>
>
>
> Sent from Mail  for
> Windows 10
>
>
>
> *From: *joachim heintz 
> *Sent: *Saturday, October 5, 2019 3:40 AM
> *To: *CSOUND@LISTSERV.HEANET.IE 
> *Subject: *Re: [Csnd] Best practices for Csound code
>
>
>
> i had a similar question and got an answer:
>
> https://listserv.heanet.ie/cgi-bin/wa?A2=ind1903&L=CSOUND-DEV&P=16141
>
>
>
> so, if it is still the same: currently we must write explicitely :a or
>
> :k when we use the functional style.
>
>
>
>                 j
>
>
>
>
>
>
>
> On 05/10/19 04:03, Pete Goodeve wrote:
>
>> On Fri, Oct 04, 2019 at 08:29:04PM -0400, Justin Rosander wrote:
>
>>> Thanks for this resource.  Now I have a question on this thing I’ve
> been seeing in code “:a” and “:k”.  Aren’t the respective variable types
> determined by denoting on the outtype “a” or “k” (like “aout” or
> “kout”).  Why indicate this again after a colon?
>
>>>
>
>> Another non-expert here (:-/) but I think that in cases where the
> output type
>
>> is determined by the output variable, therer is still no need for a colon.
>
>> e.g.:
>
>>
>
>>   aout = poscil(kamp, kfreq)
>
>>
>
>> is still fine.  It's when the opcode is 'embedded' that you may need to
>
>> be more specific.  As in the example given earlier:
>
>>
>
>>>>> instr 1
>
>>>>>   aval = poscil(poscil:k(1, 200), 200)
>
>>>>> endin
>
>>>>>
>
>>
>
>>  -- (The other) Pete --
>
>>
>
>> Csound mailing list
>
>> 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
>
> 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
> 
> 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
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

and with functions you can inline opcodes,
which I think is probably the greatest advantage.

Prof. Victor Lazzarini
Maynooth University
Ireland

> On 5 Oct 2019, at 13:42, joachim heintz  wrote:
> 
> yes.
> 
>> On 05/10/19 14:31, Justin Rosander wrote:
>> Alright, so the “functional style” encloses the arguments in
>> comma-separated values in parenthesis, and the “non-functional style” is
>> the old style of doing things?
>> 
>> 
>> 
>> Sent from Mail  for
>> Windows 10
>> 
>> 
>> 
>> *From: *joachim heintz 
>> *Sent: *Saturday, October 5, 2019 3:40 AM
>> *To: *CSOUND@LISTSERV.HEANET.IE 
>> *Subject: *Re: [Csnd] Best practices for Csound code
>> 
>> 
>> 
>> i had a similar question and got an answer:
>> 
>> https://listserv.heanet.ie/cgi-bin/wa?A2=ind1903&L=CSOUND-DEV&P=16141
>> 
>> 
>> 
>> so, if it is still the same: currently we must write explicitely :a or
>> 
>> :k when we use the functional style.
>> 
>> 
>> 
>>                j
>> 
>> 
>> 
>> 
>> 
>> 
>> 
>>> On 05/10/19 04:03, Pete Goodeve wrote:
>>> 
>>> On Fri, Oct 04, 2019 at 08:29:04PM -0400, Justin Rosander wrote:
>> 
>>>> Thanks for this resource.  Now I have a question on this thing I’ve
>> been seeing in code “:a” and “:k”.  Aren’t the respective variable types
>> determined by denoting on the outtype “a” or “k” (like “aout” or
>> “kout”).  Why indicate this again after a colon?
>> 
>>>> 
>> 
>>> Another non-expert here (:-/) but I think that in cases where the
>> output type
>> 
>>> is determined by the output variable, therer is still no need for a colon.
>> 
>>> e.g.:
>> 
>>> 
>> 
>>>  aout = poscil(kamp, kfreq)
>> 
>>> 
>> 
>>> is still fine.  It's when the opcode is 'embedded' that you may need to
>> 
>>> be more specific.  As in the example given earlier:
>> 
>>> 
>> 
>>>>>> instr 1
>> 
>>>>>>  aval = poscil(poscil:k(1, 200), 200)
>> 
>>>>>> endin
>> 
>>>>>> 
>> 
>>> 
>> 
>>> -- (The other) Pete --
>> 
>>> 
>> 
>>> Csound mailing list
>> 
>>> 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
>> 
>> 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
>> 
>> 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
> 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
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