#404

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 I

or:
LS [x] [y] : [command]
for loop + stack push

2 Likes
#405

how about

M

S.POP

1

L 1 4 : SCRIPT 2

2

DEL 250 : TR.PULSE 1
3 Likes
#406

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.

#407

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).

So maybe

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)

4 Likes
#408

that seems to be it. in this case i believe the first MUL value cannot be faster than the TR.TIME value.

2 Likes
#409

good catch! that looks to be the solution.

#410

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.

4 Likes
#411

The DEL stack is only 8 deep.

#define DELAY_SIZE 8

1 Like
#412

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?

#413

is that global across the whole scene?

#415

Yeah, 8 delay slots total.

#416

there is enough room. @sam has hard numbers in another thread elsewhere, perhaps in the parser thread… will see if i can find it.

#417

parser thread

Looks like I should read this. :slight_smile:

#418

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…

Here is the relevant link to the parser thread and a blog post I made if you want to do the calculations yourself.

2 Likes
Teletype Delay Limitations
#419

70kB free? Well then… :smile:

#420

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 …

#421

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.

#422

Wouln’t it need some time and sperd parameter? TR.TRILL A x y z

#423

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).

#424

i’d think time being dictated by the TR.TIME value is fine. spread, sure that would be useful.