Which makes me wonder: what’s the memory landscape on this project? I’d be interested in playing with a deeper stack, deeper delays, other pattern configurations. Off-the-cuff: how much wiggle room is there?
is that global across the whole scene?
Yeah, 8 delay slots total.
there is enough room. @sam has hard numbers in another thread elsewhere, perhaps in the parser thread… will see if i can find it.
Looks like I should read this.
Hi all. I haven’t quite got over the Christmas and New Year mayhem yet. School has only just gone back today. Hopefully in a few days things will settle back down and I can crack on with some more teletype code.
Anyhow, regarding free RAM and ROM… firstly a caveat, once features are added, or limits expanded it’s really hard to remove them, this is especially important when it comes to the ROM usage (as we store 32 scripts it’s easy for this to get used up quickly).
However… delays are running script only and are stored in RAM only, and there is loads of that left. So you’re in luck @sliderule…
70kB free? Well then…
would a dedicated command bypass the delay limitation? i mentioned something earlier, but something like
TR.TRILL A 3 that allows you to select the trigger output and number of repeats would be really useful …
The delay limitation is pretty arbitrary at 8.
The size per delay slot looks like it’s about 100 bytes by itself, not really sure what other memory requirements it generates.
With 70kB RAM to spare, I don’t see why the delay stack couldn’t be much larger. It should be as easy as changing the constant and recompiling. There might be computing overhead on large delay stacks, however.
That said, your solution currently uses SCRIPT to perform a subroutine. The other options are: develop a macro for the PRE combination L + DEL or alter the parser to accept nested PREs.
TR.TRILL seems very specific. It’s musically useful, and this is a musical computer, so it might make sense, but implementing it would come at a cost and only do one thing.
Wouln’t it need some time and sperd parameter? TR.TRILL A x y z
agreed that a more modular design would be better for the whole system programmatically, but there seems to be emphasis in the language on simplicity, to which a very specific musical command would make sense.
ultimately i don’t care how it is implemented, but it’d be best if it could be accomplished without significant limitation (eg 8 DEL limit) in an efficient amount of code (within single script).
i’d think time being dictated by the
TR.TIME value is fine. spread, sure that would be useful.
Just wanted to say that I raised this idea (a command that would fire a series of triggers) early last year in the TT v2 proposals thread:
and to say: I still think it would be super useful.
While I would prioritize debugging the current firmware atm I think this sounds interesting. Three parameters would be great as even with TIME there would have to be a gap specified between the triggers.
wondering about this myself. we now have
SCRIPT, so less cabling necessary. is that currently the best practice for delays with probability?
something like this could work:
PROB (prob_value) : X FLIP
DEL MUL X (delay_value) : (command)
oh ho ho, very clever! gotta try this out…
or probably better:
PROB (prob_value) : X 1
DEL MUL X (delay_value) : (command)
Finally got my TT in a rack. Thought I’d share my clock divider here. It’s pretty rough, set the divisor with the knob (1-16), clock on 1 is the only input, as 2, 3, and 8 are subroutines. I haven’t ironed out the rounding errors so there are duplicate triggers that will occur sometimes near the master clock. You can mask them with sufficient
As a first attempt it works 90% okay, but it’s not super accurate. I’ll give it another crack tomorrow.
M SCRIPT 8 D LIM DIV PARAM 1000 1 16 I Q.N 4 M.ACT 0 T 0 TIME.ACT 1 D LIM DIV PARAM 1000 1 16 X 0 1 M.ACT 0 SCRIPT 8 Q TIME TIME 0 X LIM ADD X 1 0 4 IF EQ X 4 : SCRIPT 2 2 M DIV Q.AVG D M.RESET M.ACT 1 8 TR.PULSE 1
So I called this a clock divider, but I guess it’s really a clock multiplier.
I was thinking in terms of musical notes: producing smaller notes is division.
This produces more triggers than it receives, not fewer.