#41

this is something I’d love to see as well! i.e. PN.L 0 8 feels slightly weird, but would be highly useful though.

#42

I spent years grappling with csound score before it went RT and if you are planning on giving a score language perhaps consider a SCO creator. I know John ffitch wrote a nice article in creating score with C and there were a few assistants that used Python as a helper. But something built in with the ability to create p-fields and events would be fantastic

#43

Something I’ve thought about recently, after using a lot of WW and TT back-and-forth…

It would be great if you could plug a Grid into the TT and use it to edit patterns.

I’m not entirely sure how it would work from an interface perspective, but I imagine that TT would immediately bring up the Tracker view when a Grid is connected. I imagine the first column (on the Grid) would show the active pattern (0-7, if more patterns are added in the update). The second column would have up and down scroll buttons. Maybe buttons to add or remove steps. The leftover columns would display the value of each step.

3 Likes
#44

bump as i’m about to process this thread into github issues!

if anyone wants to help implement any of these-- i’d gladly accept any time put in. this includes assistance with documentation which is bound to be the last thought.

#45

How about a command that sends a series of triggers at a specific time interval?
For example:

TRS 1 8 125

(TR-igger S-eries : produces a series of 8 triggers, 125ms apart on output 1)

I can imagine plenty of compositional possibilities with something like that. Especially in one line of code. The duration/time interval could be set up as variable, same for the number of triggers in the series, making things pretty elastic.

What do you guys think?

2 Likes
> teletype : code exchange
#46

yes i like the idea of the result-- AT is an attempt at a more flexible implementation. ie:

1
TR.PULSE 1

5
TR.TIME 1 100
AT 1 125 8

granted that’s more lines and two scripts, but it works within an established system (where the triggers/scripts have their own timer) whereas what you’re proposing is basically to put timers additionally on the outputs, right? i think having both may be confusing.

ps. i’ll work on the code comments and live value updates for v2

2 Likes
#47

Ah, forgot about the proposed AT!

Certainly can deliver what I had in mind.

(Still like the idea of single code line series, sort of like UZI in Max, but with controllable time interval ;-))

AND super excited for the live updates and comments/disabling of code lines!

#48

i should be able to help with some of the features.

#49

Si do we have to report our ideas as issues on github ?

#50

no-- i’ll create github issues.

#51

I am sort of surprised that more people do not think it would be useful.

I actually concur but have been quietly absorbing these suggestions waiting for a moment to provide some more informed input. Until then, suffice it to say, I would love something like this, and really more generally a means to write to the display. Concretely, I have a few scenes where the PARAM knob selects modes and it would be great to display them (it’s a guessing game as it is).

Having said all that, I suspect that updating the display in the general case might potentially throw off timing… I hope I’m wrong about that though! Also, thinking on this a bit more, it seems like we’d also benefit from a way to register interest only in value changes. IOW: only go to the display if a variable’s value has changed. Ah see, now it gets complicated!

1 Like
#52

Agreed!

More generally, it would be fantastic to use the grid as a UI for scenes as well but I recognize that’s pretty ambitious.

#53

i don’t think there should be a timing issue. it’s just that the mechanism isn’t in place to “monitor” value changes already, so it’ll require new functions or a brute-force query on interval.

2 Likes
#54

Hi, I am pretty late to this thread, but I hope not too late for these feature request.

(1) I use lots of variables, like X, Y, Z, A, B, C, D and O. Now when I want to initialize them in the Init Script, I have to tie up a second script to init all of them.

Wouldn’t it be nice ("…if we were older…", now stop chanting back there!) if we could do multiple integer variable assignments in one line, separated by commas? Like:
X 0, Y 0, Z 1, A 32, B 64, C 1

(2) It would be nice if the TT display displayed 0 and O differently (like it does in this lines format), right now both look identical in the TT display. A dot inside the 0 would help.

Thanks for considering!

1 Like
#55

i see your point, but what this actually suggests for the code is a big job for parsing. an alternative would be for me to get going on the TIMELINE feature which would allow an unlimited-length INIT section at a particular timestamp. this is part of why i’m excited about this feature-- it could be considered a general script extender.

absolutely!

1 Like
#56

[quote=“tehn, post:55, topic:2450, full:true”]
an alternative would be for me to get going on the TIMELINE feature … it could be considered a general script extender.[/quote]
Ah yes, of course, this makes more sense.
And thanks for adding the font change request!

#57

Another feature request: optional in-line pattern definition for all pattern commands that currently require working pattern definition.

Example:

  • P.NEXT continues to work as it does today, i.e. it affects the current working pattern.
  • But if you write P.2.NEXT this command would work on pattern 2.

So both syntax variants would work:

  • P.command gives the current behavior, i.e. it affects the current working pattern.
  • command is a placeholder for INS, RM, L, PUSH, POP, I, HERE, NEXT, PREV, WRAP, START, END
  • P.p.command defines the pattern to be affected by this command, with p (from 0 to 3) being a placeholder for the pattern to be affected.

So this request would basically affect all commands starting with P., it would not be needed for P, as PN gives functionality of P plus pattern definition. Question: Does PN also change the working pattern, or is the pattern definition in PN local to just this command and does not change the working pattern? Whatever the answer is, that should be the model for the interpretation of p in P.p.command.

This would not only save a lot of command lines, but also make scripts easier to write & digest, as you immediately see in-line which pattern a command is affecting: the working pattern or an in-line defined pattern.

Thanks for considering!

#58

Agree on this feature request!
with the current command set, the logical expansion I guess seems to be

PN.POP [0…3]
PN.INS [0…3] a b

which is a bit weird at times… but avoids introducing a new notation

#59

indeed, this has been requested previously in this thread. will note.

1 Like
#60

Let’s keep our fingers crossed that it will make it.

Not sure about this specific notation proposal, because if I understand your proposal correctly I fear it might render existing scripts incompatible.

An example:

P.HERE x currently writes x to the current index of working pattern. It should do so in TTv2, otherwise existing scripts would need to be either manually (error prone, plus I am lazy) or automatically converted (which would increase tehn’s workload).

In my understanding of your notation proposal, P.HERE x would be replaced with P.HERE [0..3] x, so it required 2 numbers (first pattern, then value).

At the same time, the command P.HERE would still be required to work, this command currently reads the value at the current index of the working pattern. In my understanding of your proposal, it would have to become P.HERE [0..3].

This is where things would get sort of slippy, because the new
P.HERE [0..3] (read value at current index of pattern [0…3])
would become indistinguishable from the existing
P.HERE x (write x to current index of working pattern).
So a replacement for the functionality of P.HERE x would be needed.

This can quickly become quite confusing, that’s why I’d rather see the pattern definition as part of the command itself, rather then become a part of the argument. Then we can continue to use the existing syntax for the existing functionality.

But hey, that’s just me trying to think aloud. I have no clue about programming (that’s why I like TT :slight_smile: ), so chances are I am talking complete nonsense here.