[Csnd] new GETTING STARTED in flossmanual

hi all -

i have written a new GETTING STARTED for the csound floss manual. the develop version is here: The Csound FLOSS Manual

if anyone has time to read, and can give feedback (suggestions, corrections), it is very much welcome. we plan to release in some weeks.

thanks -
  joachim

Csound mailing list
Csound@listserv.heanet.ie
https://listserv.heanet.ie/cgi-bin/wa?A0=CSOUND
Send bugs reports to
        Issues · csound/csound · GitHub
Discussions of bugs and features can be posted here

Hi Joachim
Thanks for this nice resource! I think it makes a good introduction to the language. I think it is a good choice to use functional syntax from the beginning. Perhaps it could be useful to have a very first example with just i- variables, in order to show just syntax and a simple calculation? Then introduce a- variables as a second step?

Just some technical issues with the web page when I read it on android:

  • The figures are not displayed, only the caption and a blank space of a Suze the could fit the figure.
  • The navigation menus displayed at the bottom of the screen do not automatically update the page, so a menu selection does not become effective until I manually refresh the page.

All best and thanks again
Øyvind

ons. 5. apr. 2023, 22:43 skrev joachim heintz <jh@joachimheintz.de>:

hi all -

i have written a new GETTING STARTED for the csound floss manual. the
develop version is here:
https://csound-floss-dev.firebaseapp.com/get-started

if anyone has time to read, and can give feedback (suggestions,
corrections), it is very much welcome. we plan to release in some weeks.

thanks -
joachim

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, oeyvind, for this feedback! i will think about your suggestion, and will consult the master of javascript about the technical issues.
cheers!
  j

This is great Joachim, thanks for your many efforts, I’m sure they are much appreciated. The FLOSS manual has been a great resource for me.

l haven’t had time to deep dive it yet but will continue going thru it over the next while & reach out if I have suggestions or notice any errors.

Scott

ST Music
https://soundcloud.com/st-csound
https://soundcloud.com/stoons-1

https://youtube.com/channel/UCGhwmkS1uWmX6mhTIQ0IDsg

Nice tutorial, I even learnt some things myself (I had never heard of the "z" duration in the orchestra...). I like the casual writing style and the coding style as well, not only using functional style and more standard indentation but also the more modern version of some opcodes (mtof)

Some observations from a fast read:

> The main reason for introducing k-rate was to save CPU power. This was essential in the
> early years of computer music. Nowadays it is not the same. For usual instruments in
> electronic music, we can omit k-rate variables, and only use a-rate variables. In our case,
> we can write:

Even if this might be true in certain contexts, doing logic with audio variables is still not really ergonomic and often not what the user intended. The rule of thumb I would propose is that besides audio signals per se, anything amplitude related needs to be computed at audio rate and the rest can be left as k-rate variables until some audible artifact is actually detected.

Best regards,

Eduardo

I agree with Eduardo.

I agree with Eduardo.

Also, as a “live musician”, I think of it this way:
a-rate is what we hear
k-rate is what we perform
i-rate is the instruments we bring and play

FWIW, I tend to use a-rate by default for most everything, e.g.,
amplitude and things like modulation for filter cutoff frequencies and
pulse width modulation for vco2. I agree it's easier with logic to use
k-rate. That'd probably be the rule I'd go with personally, default to
a-rate unless doing logic.

I think it’s good to point out that it can still matter depending on the context (embedded platforms, big complex orchestras, live performance etc.). Not to overcomplicate things in a “Getting started” section, but habits get established early on.