#81

yeah, i meant more as a standalone automaton that could be edited from a teletype. and yeah, feature creep! but taking even further, it could simply execute one script but then allow for storing a library of scripts which could then be selected from teletype, so you could have modules that would change their function with TT serving as the ‘control tower’. modular that would change ‘modules’ under CV control.

#82

Sorry if this is in the thread somewhere (didn’t see it though I’m sure it’s been talked about), but I wonder if we could put a SCRIPT command on the table to trigger other scripts? Chaining scripts is a great way to get around the command limit for scripts and is something I find myself frequently wanting. (The pattern generally is a bunch of scripts that update variables and patterns that delegate to a shared script that updates CVs and TRs.) A simple guard would have to prevent recursion but I don’t think it’d be too hard.

Curious if anyone else would find this handy?

#83

this exists now! enjoy!

1 Like
#84

That was quick! :wink:

Actually, this is a little hilarious. I have teletype.c open at the moment and sure enough op_SCRIPT is right there. The issue, as it happens, is somewhere in my code. Classic case of looking for a zebra instead of a horse.

Now back to the debugger!

1 Like
#85

I think it would be cool if there was something like Max’s UZI operator, useful for multiply trigger with a unique line.
:wink:

2 Likes
#86

totally agree @kkempes
see earlier in this thread:

:slight_smile:

2 Likes
#87

Also,
I’d like we can play with envelopes on the CV outs.
Maybe you can define parameters like CV.EXP 1-4 and CV.LOG 1-4 next to CV.OFF, CV.SLEW.

Ciao

#88

Now that the new Arc is on the way…

It’d be awesome if Arc could plug into TT. I’d imagine four internal Params (ARC1, ARC2, ARC3, and ARC4) could be controlled by the Arc interface. This would give a great alternative to the Param panel knob.

5 Likes
#89

That would be amazing. Four “knobs” and four manual trigger/gate.

#90

Starting to look into the Teletype code in more depth and plan integration for the expanders.

Things I’m thinking about:

  • I’d like to communicate with the modules using the 7-bit root address and then bundle all commands in the message body. Any thoughts of moving the other modules to this paradigm?

  • Message body that is variable length so that when I’m sending something like a TOG command I don’t have to throw in a BS # - which is easy for custom operators - especially if there is common variable length i2c command. Any plan for this?

  • As suggested by @tehn, the TT operator would handle multiple modules of the same type by continuing to increment the output ids: TO.CV 5 N 2 - would address the second expander’s first CV output.

  • Want to keep the i2c chatter down, so for the input module it might be better to poll than to push from the module (which is more like the TT’s behavior with its own CV inputs). That gets a little tricky - so I’d love to know more about what you (@tehn) have been cooking in the lab regarding bi-directional i2c functionality.

  • In regards to refactoring and V2, are there any things that I would need to keep in mind that are on the roadmap that would impact my analysis and planning, @sam?

Thx!!

b

2 Likes
#91

Never mind on my two questions, @tehn. @Sam pointed the way to your check-ins in the avr32 repository. I’m going to dive in!

Thx.

b

1 Like
#92

just be prepared that rev2 might have an overhaul of the II system, but i’ll ensure there’s backwards compatibility.

1 Like
#93

Don’t worry about backwards compatibility on my account; not against a refactoring in the future. :slight_smile:

Good luck with rev2!!

b

#95

Suggestions, presented without thought to how difficult it is to implement
2. Script change: replace one script with another from a different scene
3. Load pattern data from another scene

#96

I imagine most of this is pretty challenging, at least from a user-interface perspective. In the same vein though, I’d love to be abel to copy a whole script, not just one line at a time-- Often I make scripts that are duplicated to different triggers with slight adjustments between them.

The idea of separate patterns & scripts (as opposed to the current linked setup) was originally tossed around. It ended up being a UX nightmare though, so never got passed design stage. It would be powerful to have separate access to them, but the way patterns are often used as simple variable lookups / working data might make the patterns so incompatible as to be useless. I guess it would work if you were very strict about how you entered / modified data in the patterns so your scripts would at least continue to work when changing between patterns.

1 Like
#97

For item 1. have you messed w/ the SCENE parameter? I’ve actually not used this one yet myself, but my assumption had been it could be used to jump scenes

#98

+1 from usability standpoint if there was a streamlined way to copy an entire script, I could see it being very useful

2 Likes
#99

I had missed that, thanks! I’ll try it out later.

#100

i definitely agree that the ability to copy whole scripts would be quite useful. perhaps even just the ability to copy multiple lines would be useful? i often find myself deciding to break out multiple lines to their own script.

from a ui perspective, it seems like using shift + up/down to select multiple lines could be an intuitive way to do this? then the selection could be copy/cut as usual. i suppose then the ux issue that would arise from that method would be dealing with what happens when pasting multiple lines into scripts that are already populated.

1 Like
#101

this +1

command + shift + C to copy all?