and with play (:c..:fs6).to_a
I got Invalid note: :h
and with play :c..:fs6
i got no sound although i would expect the same sound as with play range :c,:fs6
This seems to be similar in SPI3.3.1?
And problems certainly apply to other symbolic notes combinations like
play :c6..:e6 → no sound … bad … unexpected … is it a system failure?
compared to some sound with:
play range :c6,:e6 → expected little higher sound than play range :c,:fs6
And all this has nothing especially to do with symbolic notes
but with the intuitive ruby .. range.
Because the same problems arise with integer numbers like: play 60..90 → no sound … in my opinion a system failure!! play range 60,90 → some sound … OK!!
I mean I am a kind of nitpicking and very much prefer a SPI with
many simple intuitive ways to express musical ideas.
And in my opinion 6..79 is simpler and little bit more intuitive
than range 6,79.
Please note that Ruby’s .. range syntax is not formally supported by Sonic Pi. Whilst it should work as expected in most cases, it can’t be relied upon to continue working for future versions of Sonic Pi. Additionally, supporting ranges of notes isn’t completely obvious to me how it would make sense musically as it would always work over the chromatic scale.
just to be clear, there is nothing stopping you from using any Ruby functionality in your Sonic Pi code. Nothing is out of bounds - I absolutely encourage you to experiment and play.
However, from a practical perspective, Sonic Pi is mini language built on top of Ruby. This means some aspects of Ruby were modified and used in a non-standard way in order to make the Sonic Pi experience what it is. Sonic Pi currently does not have a formal specification and it’s not something I’m interested in spending the time to work on because I’m more interested in finding ways to improve the general experience and functionality for everyone rather than to painstakingly attempt to define all the possible edge cases where the interaction between Sonic Pi’s mini language and vanilla Ruby conflict.
In lieu of a formal specification, the tutorial currently stands as the best document to describe what functionality was intended. By intended, I mean functionality that was designed and tested to work as documented. I have also promised to try my best to specify in the changelogs where this functionality has changed between releases. I do not have the resources to document where any arbitrary Ruby functionality may break or change between release - this I what I’m specifically referring to when I talk about “supported”. It’s more of a friendly promise from me to all users that I’ll let you know when things change or are removed than a formal specification.
At some point I’m planning to move the core implementation to Elixir at which point a more formal spec may be feasible but be warned, if such a thing were to exist it will be a tiny subset of the various accidentally inherited functionality of the current Ruby DSL.
Sonic Pi isn’t intended to be a fully fledged programming language that you can use to build websites, work with AI / robotics, do numerical calculations, etc. Its goal is to be a simple yet powerful musical instrument. Simple enough to teach introductory computer science and powerful enough for professional musicians.