alternatively, some sort of new ‘ratchet’ command could fulfill the same purpose.
Likely, to extend the software to support nested prefixes would be a little complicated, not to mention verbose.
It would be simpler to create macros to do fixed things in software, like:
LD [x] [y] [delay] : [command]
for loop + delay, assuming [delay] can be an expression that includes
LS [x] [y] : [command]
for loop + stack push
M S.POP 1 L 1 4 : SCRIPT 2 2 DEL 250 : TR.PULSE 1
thanks, i can try this in a bit. what purpose does the stack serve here?
edit: running that and triggering script 1 gives the same results as before-- what i presume are four overlapping pulses.
Wouldn’t this schedule 4 triggers, all 250ms from now, instead of 4 triggers 250ms apart? Also, the M script does nothing (there are no stack pushes).
1 X 0 L 1 4 : SCRIPT 2 2 DEL MUL 250 X : TR.PULSE 1 X ADD X 1
(Still getting used to polish notation. Used RPN for years so old habits make for syntax errors)
that seems to be it. in this case i believe the first MUL value cannot be faster than the TR.TIME value.
good catch! that looks to be the solution.
here’s a slight edit to the above for usability. this goes nice with the mutable instruments rings module running with 4 notes in the sympathetic strings mode-- can make harp or acoustic guitar playing sounds. editing the TR.TIME value gets you different playback rhythms and the CV line would probably be better using values as a melody instead of random semi tones, but for the sake of example …
1 X 0 Y ADD TR.TIME A 1 L 1 4 : SCRIPT 2 2 Z MUL X Y DEL Z : CV 1 N RAND 24 DEL Z : TR.PULSE A X ADD X 1
one thing i notice is that i can’t loop this beyond 4 steps. interestingly, removing the CV line gets me to 8 steps, but nothing beyond that. this isn’t very problematic for me, but if someone is into debugging, it might be interesting to find out why the loop doesn’t go past 4 or 8.
The DEL stack is only 8 deep.
#define DELAY_SIZE 8
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…
Teletype Delay Limitations
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).