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