In the documentation for the :flanger FX, the sliders for the invert_flange: and stereo_invert_wave: opts are not configured correctly - they are meant to allow either 0 or 1 (off or on), but those sliders allow an inclusive range from 0 to 1.
There are probably a few others like this also. @samaaron - is it worth documenting known bugs and limitations for users wanting to test Sonic Tau during the transition to Tau5?
Hi, I found bug. One line statements doesnāt work. Example:
live_loop :test do
play 50 if spread(1,4).tick
sleep 1
end
This works:
live_loop :test do
if spread(1,4).tick
play 50
sleep 1
end
end
I use firefox.
Not a bug - trailing if statements wonāt be supported. Theyāre really a Ruby thing. Instead use on:
play 50 on: (spread 1 4).tick
should be fixed
fixed (in a bit of a hacky way for now)
Added - also the merged versions too.
Fixed as in live? Iām still seeing the previous behaviourā¦
Would it be possible to use cue and set with a variable?
live_loop :cue_test do
cueArray = ["a/b","a/c"]
cue cueArray.tick
sleep 1
end
Nice.
The spread example in āLangā needs to be updated. Itās using a trailing if statement at the moment:
should be fixed online 
yep, it should be fixed liveā¦
Ok, well, in both Firefox and Chrome on my devices, if I slide the room: slider for :gverb in the interactive documentation, as soon as I do, the range still resets to 0 - 1 for me. 
I was referring to the kill delay for echo, pingpong and gverb. Iām currently focussed on the language and the UI layout.
Iāve been playing around a bit with Tau, truly amazing so far!
Tau tells me Ruby loops like 4. times do , isnāt implemented yet. Rust syntax, for _ in 0..4 { ... }doesnāt work either. Iād suggest implementing at least the option to use regular Rust syntax just like Ruby can be used in Sonic Pi. That way documentation and other sources of information regarding Rust can be used to solve problems in Sonic Tau, just like documentation and the like for Ruby can be used for Sonic Pi.
Iām assuming you are leaning towards using Rust syntax for Tau because of this:
Which may or may not be intentional - Itās a matter of spacing. 4 .times do ... end works (whether strictly ācorrectā or not), as does 4.times do ... end of course, but 4. times do ... end does notā¦
Re adding Rust syntax, unless Iāve been too much out of the loop, I donāt think thatās the target for Sonic Tauās official DSL - but Iāll let Sam comment on that.
" That way documentation and other sources of information regarding Rust can be used to solve problems in Sonic Tau, just like documentation and the like for Ruby can be used for Sonic Pi. "
I agree with that basic concept . Better to use a known language than try to reinvent the wheel .
Yes, which goes back to the reasoning behind Samās original plan to transition away from Ruby with Tau5. Given plain Rubyās insecurities in a shared or distributed environment, Tau5 being based on Lua made lots of sense in that it enabled things to be much more sandboxed and secure - and as well as using the DSL built on top (Tau5Lang) it also enabled using plain Lua in future compositions/performances - thus making Lua documentation and resources useful.
(Plus Lua is arguably easier than Rust for newcomers to pick up!)
It will be interesting to see how Sonic Tau maps to this idea (i.e. whether Sonic Tauās language is intended to become Tau5Lang based on Lua etc or if the planās changed slightly). Would love to know a bit more if you have any details Sam 
Yeah, apologies for the super confusing naming. Itās hard to name and describe things that donāt exist yet - itās much guesswork as it is planning!
As it currently stands, Tau5 is the broad name for the suite of technologies Iāve been exploring and building. Think of it more like a code name, kind of like id Tech 5 ( id Tech - Wikipedia ).
1 year ago I had strong ideas about what I wanted to build and those ideas are still pretty consistent, but the technology that Iām currently considering is quite radically different.
The big change was starting work on SuperSonic last summer. It completely turned things on its head. Firstly I was able to port SuperColliderās synth engine to the web which was the missing piece to my plans. Secondly the process of implementing that port taught me a lot about how audio synth engines work, how they maintain stable latency and jitter, and these were things that I really wanted. I had been prepared to give up on super low latency in favour of security and good (advanced) scheduling. With the clockwork approach I wondered if I could have both.
Sonic Tau was meant to be a short small experiment. Could I build a clockwork language? Could I implement enough of a subset of Sonic Pi that it could be useful for introductory workshops? The plan was just to do this, have a nice ābaby Sonic Piā website that educators could use, and then to step back, learn from the experience and start hacking on the new Tau5 language core.
It turned out that all of the deep design thinking I had done over the years unfolded into something rather powerful and elegant and Iāve been able to get way further than I imagined - even beyond Sonic Pi in key areas (https://www.patreon.com/posts/re-re-rerezzed-155986856?utm_medium=clipboard_copy&utm_source=copyLink&utm_campaign=postshare_creator&utm_content=join_link)
Therefore, Lua/Luerl is no longer in consideration. My clockwork language ideas offer the security sandboxing and raw speed. However, Iām still strongly considering stopping, taking a step back, extracting and synthesising the core ideas, re-deigning them and then building Tau5 - which will be very similar to the internals of Sonic Tau. The broad goal would be able to easily re-implement Sonic Tau on top of Tau5 Tech.
With respect to language deign. Ethan is right. Sonic Pi was heavily based on Ruby. It is essentially a modified Ruby not just implemented in Ruby. Sonic Tau is not Rust. It is a completely new language that happens to be implemented in Rust. It has completely different internals with radically different constraints. Kind of like how Elixir looks similar to Ruby but is a totally totally different beast.
Iām copying Sonic Piās language closely with Sonic Tau because itās something I know and understand (kind of like how js devs may learn a new framework by implementing a TODO app for the 50th time). Itās also a nice challenge with clear goals. Also, and perhaps most importantly it should be possible for educators to easily transition their lesson plans and education material from Sonic Pi to Sonic Tau.
Still, Sonic Tau is a partial language. Itās definitely not complete - will have huge holes here and there. But thatās not the goal. The goal is to see if the approach works and see if I can implement most of Sonic Pi with it. Then I can stop back and implement something a bit more holistically with more solid foundations for the future.
Iām seeing something strange with .times loops inside define:
define :beat1 do
2.times do
sample :drum_bass_hard
sleep 0.25
end
end
define :beat2 do
2.times do
sample :drum_cymbal_closed
sleep 0.25
end
end
beat1
beat2
This plays beat1 and then stops, showing ācall: expected proc valueā.
It works if I swap around the calls at the end, or if I remove the .times loop from the first function.
Modulo (or remainder) doesnāt seem to be implemented yet (a % b doesnāt work). I think it should be. Also basic math functions like abs, sin, cos, exp, floor, round, max, etc. A solid yet minimalistic list for core math functions can be found here in the Lua reference manual.
For instance, with with .floor one could make modulo with a - b * (a / b).floor but alas. Oh, and in case you had not thought of it, modulo is very useful for adding elements at specific intervals within other intervals. If, for instance, I am ticking some ring of notes, I can do something like if look(foo) % 4 == 3 to make something else happen every fourth occurance, and I can even choose exactly on which fourth one depending on what remainder i choose to look for. Obviously it also works when incrementing a value each iteration of a loop, and so much more. Very good for coding music because like that, one can tap into existing loops and add stuff into the soundscape wherever one sees fit. Bit-shifting is another way of doing it, but no luck there either.
I should add, this way of coding music cannot be used to its full potential in Sonic Pi since once such clockwork grows in size, it gets increasingly tricky to alter it in real time since re-running the code resets variables to their starting position (unless commented out or similar). Als, even if one does that, changes in the code doesnāt take effect until the live_loop loops around to the start. Also, the slowness of Ruby makes it so that use_sched_ahead_time instead of use_real_time and then parameters for functions cannot be controlled in real time either. All of this seems to be much less of an issue, if not entirely solved, with Sonic Tau. So I am really really really func really(really) excited to try it out, but I cannot see how to at the moment.
Either way, I strongly believe fundamentals like modulo/remainder, math functions and bit shifting must exist in any educational tool for coding. But I also get it if it deviates too much from the purpose of Sonic Tau as of now. But modulo couldnāt be too time comsuming to add, right? Worst case, if anyone has any idea of how to get the same result as remainder/modulo with the stuff at hand (e.g. an algorithmic expression using only the basic basics like +, -, * or /), I am all ears.
That is indeed bizarre. Something for Sam to investigate