I’m just writing up some tests for it (found 1 bug already). Once that’s done (a few days probably), I’ll push the code on to GitHub. Is that enough for you, or would you rather have a hex file?
After that I really need to start trying to catch up with @sliderule’s PRs.
FN isn’t super amazing from a more code in less space point of view,
TL would be much more useful there. But the general idea of commands stored in special variables really intrigues me. I think it’s something I will end up implementing on my own fork if it doesn’t end up in the master branch. More than anything it would be really useful with the scale code:
FN 0: N SCL7 0 2 4 5 7 9 11 X
T ADD T 1
X PN 0 T
CV 1 FN.CALL 0; TR.P 1
X PN 1 T
CV 2 FN.CALL 0; TR.P 2
The biggest thing that
FN has going for it is that it can be done quickly. So far every other solution will need non-trivial work done, so we’ll need to find someone to volunteer to do it (I haven’t got the time).
Sadly not, the tokeniser is not context aware, it can’t tell the difference between things being MODs or OPs. It can be done, but someone will have to invest the time.
I don’t wish to put a downer on any suggestions, but writing interpreted programming languages on an embedded platform has a lot of issues, especially if we allow custom names for things. The original design of the language is actually really rather clever, in that errors can only occur as lines are entered, and it’s impossible to break an existing line of code via any changes to anything.
I think that is easily fixed by increasing the number of OPs per line (there is still a limit on the number of characters per line though!).
It’s currently set to 12, and this number includes all the individual things on a line (numbers, ops, mods, semi-colons, and colons). E.g.
A 1; B 2; C 3 # this is 8 items long
A 1; B 2; C 3; D 4 # this is 11 items long
A 1; B 2; C 3; D 5; X 6 # this is 14 items long and is too long now
So we could increase the number to 16… but that would take more space in the flash ROM for saved scenes. Which is space that might be used more efficiently elsewhere, say, more allowed timeline entries per scene.
(Since I wrote the semi-colon code, I often increase it to 16 in my personal builds.)
FYI all, we currently have a lot of free RAM, the pressure is with saving scenes in flash ROM, as their are 32 saved scenes.
Tutorials… these are most welcome, you just need to know how to write in Markdown (and I know everyone on this site can use that), no
GitHub required. The current Teletype studies tutorials are already in a Markdown format…