strudel
strudel copied to clipboard
tidalcycles
Failure modes
s("bd") (without .webdirt() or similar) will cause an 'unplayable event' error, but will still play a note, with infinite sustain. This seems to be the last note that was triggered. (ctrl-. doesn't stop this sound, it seems to need a refresh.)
That one is a bug but I think there are design decisions around how to deal with errors. For example this one gives 'cannot parse as number: "cp" and the pattern falls silent:
s(pure("bd"),pure("cp").div(3)).rev().webdirt()
This one falls silent only on the cycle where the 'sometimes' is (randomly) triggered:
s(pure("bd"),pure("cp").sometimes(div(3))).rev().webdirt()
In Haskell, these would be compile-time type errors so the pattern would not replace the currently running one. Run-time errors are possible (e.g. in tidal's mininotation), in which case the previous version of the pattern is swapped in.
s("bd") (without .webdirt() or similar) will cause an 'unplayable event' error, but will still play a note, with infinite sustain. This seems to be the last note that was triggered. (ctrl-. doesn't stop this sound, it seems to need a refresh.)
fixed in #177
That one is a bug but I think there are design decisions around how to deal with errors. For example this one gives 'cannot parse as number: "cp" and the pattern falls silent:
These runtime errors are harder to catch, because we have a valid pattern, but it fails to query, probably not all the time.
One quick but not perfect fix would be to query the pattern after it has been evaluated, and reject it when the query did not work. This will fix the first snippet (always .div(3)) but not the second.
A more thorough approach would be to switch to typescript and add a client side type check on evaluation, though I am not sure how well typescript will be able to check types in this style of programming. It might generally be tricky to type this stuff in advance / could mean a good amount of refactoring. If it does indeed work, it would be really worth it.
Run-time errors are possible (e.g. in tidal's mininotation), in which case the previous version of the pattern is swapped in.
This is also something we could do right now. Although we can never be sure if a pattern will throw an error at any point in time, but I think anything in that direction would improve how it is right now.
One design goal should be: Keep the music going at all cost.
One design goal should be: Keep the music going at all cost.
Yes agreed. In practice 'switch to previous one' doesn't work well, going back in time is often not at all what you want.
Probably better:
- On eval, test it by generating the next cycle or so's worth of events. If there is a runtime error, tell the coder and don't swap it in
- If there are runtime errors later, tell the user but carry on with the next 'slice', probably more events will be calculated.
I think strudel is still generating at 1Hz, this would make more sense once it's on a higher frame rate (tidal is at 20Hz).. Although I guess some errors will be present for whole cycles or more anyway..
On eval, test it by generating the next cycle or so's worth of events. If there is a runtime error, tell the coder and don't swap it in
:+1:
If there are runtime errors later, tell the user but carry on with the next 'slice', probably more events will be calculated.
With "carry on", do you mean skip the current cycle or silence?
I think a combination of all of those ideas will improve things a lot.
Another interesting bit: I am currently reading babel docs for https://github.com/tidalcycles/strudel/issues/174 and found https://babeljs.io/docs/en/babel-parser/ (search errorRecovery). So it could be possible to still evaluate even when parts of the code are invalid.. Could also be a bad idea but worth noting anyway
as noted by @yaxu :
btw giving a workshop last week, it was a bit harder to solve error messages without the line numbers like Unexpected token (9:21), having to count the lines
so either add line numbers (easy) or find a way to add error squiggles (not so easy)