#103

Interesting

I need to explore that

#104

I have a tendency to play the pattern trackers directly but have seen the limitations of that

Had never really tried similar (far more dynamic) techniques with LIVE

#105

I fear this, too. I think if the TIMELINE is going to be a sort of blob of subroutines, I’d rather use it.

Good news! I’ve submitted a patch that overhauls pattern data entry so this kind of thing should be much easier going forward.

4 Likes
#106

It’s very useful imho. You can try out stuff before you actually write it in a script. Which is great since sometimes (well very often) you need to make space for an additional thing in the script and it’s great to be able to test it before you do so.

#107

Great news ! Thanks :slight_smile:

#108

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:

e.g.

SCRIPT I:
FN 0: N SCL7 0 2 4 5 7 9 11 X
T 0

SCRIPT 1:
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 git or GitHub required. The current Teletype studies tutorials are already in a Markdown format…

1 Like
#109

Yes, I can make the hex myself. Thanks, much appreciated.

#110

Just working my way through some of the PRs that @sliderule submitted.

Can I get some sort of consensus regarding MSPB please? I would like it added.

It’s used to calculate the number of milliseconds a beat at a given BPM would last for (and is very useful with M, TR.TIME and DEL).

e.g.

M MSPB 120    # metro will tick every 500 milliseconds
7 Likes
#111

I actually would dig this, as I’ve been using DELs and SLEWs to hack these together but am having troubles with the cost of DELs and adjusting them dynamically. what were some of the arguments this would hypothetically pair with?

#112

Not opposed but I feel dense for not understanding how 500 came from 120…how is this calculated?

#113

120 BPM / 60 S/M = 2 B/S = 0.5S/B = 500ms/B.

3 Likes
#114

The more I think about it and having calmed my initial apprehensiveness I find the MZ suggestion to mark integer dividers quite nifty for applications like counting, dividing and stepping continuous variables.

I also see it fitting in the existing EZ, NE, GT,… syntax nicely. I don’t think it will be easily confused with metro or Z variables after you have accustomed to those compare-to-zero-operators. Keeping it connected to modulo by naming it MZ also helps understanding both better I think.

:grinning:

#115

Sorry I’m going to blame baby brain for this. But I’ve just realised that the following:

IF EQ % X Y 0: [some sub]

doesn’t need the EQ, you can use NOT or !:

IF ! % X Y: [some sub]

That’s only 1 extra character over MZ, and 1 extra op.

Now MZ might be a lot easier for some people to understand, and it does have very musical applications. But I think we’d be better trying to figure out which direction we’re going with regards to TL, FN, and some of the other proposals before making a decision about it.

I also think that if we do add it, it should go into a proposal with all the other similar style OPs that we are thinking about adding. I would like to avoid having them added one at a time.

#116

Yes, I promise to give my best with all this programming language stuff - But I really would like to stay with letters instead of arbitrary symbols.

I understand that it is about developing habits and perceptual frameworks but IF MZ X Y still feels like a sentence with a meaning to me while IF ! % X Y doe snot.

#117

You can type it in words instead, but you don’t get the benefit of the space saving.

IF NOT MOD X Y: ...

But if the argument for adding MZ is purely about space saving…

edit: my bad, there is no NOT op, it should have been:

IF EZ MOD X Y: ...
1 Like
#118

For me the argument for MZ is that it stands between a language that is sometimes space consuming and one that is short but hardly understandable to non-proffessionals. I have the feeling that MZ is a good compromise because it leads me to its meaning by using letters while !% is very abstract. Also it seems to fit parts of the already existing abbreviation system (EZ,…) which makes it consistent and easy to grasp.

BTW: Is NOT always connected to zero? I did not find it in the teletype documentation. Maybe it’s my lack of understanding but when I read IF NOT MOD X Y: … the first thing I think is: “If MOD X Y is not what?..”
MZ seems to be a lot clearer to me.

#119

NOT is negation. So it ends up being false if MOD X Y is non zero and true if zero.

E.g.:
NOT 1 //0
NOT 0 //1
NOT 6 //0

(0 = false, > 0 = true)

1 Like
#120

So NOT is basically the same as EZ?

#121

My bad, there is no NOT, I should have typed EZ, and yes they would be the same if NOT existed!

#122

lol my bad too for trusting so blind without checking first :grin:

edit: can we have a NOT then? :stuck_out_tongue_closed_eyes:

2 Likes