#1

i’ve been thinking about why teletype scenes are not more widely shared / re-used. we even have a code exchange repository but it’s not very active. part of the problem is documentation, but another part is that sometimes a scene is written for something like just friends, so it needs to be edited to be used with, say, a telex instead. such change can be less than straight forward due to the differences in how different modules operate (where one modules requires one op to play a note another will require 2 or more). and you will likely need to modify the init script (for TXo you’ll need to do at least TR.ENV.ACT) which can be difficult if it’s already full.

as a solution for the above i’d like to propose a device agnostic note op:

NOTE index pitch volume duration

by default this op will output a note using TT CV/trigger outputs. but you could also map it to various other devices:

NOTE.TT index start count
map to teletype CV/TR, same as CV/TR 1-4

NOTE.AN index start count
map to ansible, same as CV/TR 5-8

NOTE.JF index start count
map to just friends, same as JF.VOX

NOTE.TO index start count
map to txo, same as TO.CV/TO.ENV.TRIG

NOTE.SC index start count
map to er-301, same as SC.CV/SC.TR

NOTE.UN index start count
map to universal ops

index is the starting voice index for NOTE
start is the first index on mapped device
count is how many voices you are mapping

NOTE.TO 1 1 4 will map 4 voices to a TXo, for instance.

the above mapping ops will also take care of setting things up for you (so, it’ll execute JF.MODE 1 if you map just friends etc etc).

with this model you can easily change a scene for a different device with just one line of script. alternatively, you could use it to map a multi voice system that would use several devices, so you could have a 10 voice system where 4 voices are output on teletype, and 6 are played on just friends. such mapping will also allow you to switch different sound sources without having to repatch cables. you could also overlap mappings, to create layered voices.

not all devices will support all note properties (say, if you use teletype it will only output pitch and gate, but not volume).

another useful op would be NOTE.MUTE so you could also control which voices are active at any given point without changing anything in the scene itself.

something similar could also be created for CV and TR.

25 Likes
Teletype codex: community github script repository
Teletype Disting EX integration
Teletype 3.+ feature requests and discussion
Teletype 3.+ feature requests and discussion
> teletype: grid # code exchange
A user's guide to the wonderful world of teletype ⌨
> teletype : code exchange
Generic teletype ops for interacting with other devices?
#8

NOTE sounds interesting, and certainly has the potential to make sharing and/ or adapting scenes easier. Would there be any reason to use the old OPs, or does NOTE make them redundant? Sort of like P and PN?

I completely agree that…

#13

My feelings are similar - I think this is more the reason why people don’t share scenes as much.

Could a ‘find and replace’ command be possible to replace instances instead? In my mind it would be less confusing.

#15

some really good discussion around sharing scenes and specifically the git repo for teletype scenes.

i think this thread is a more appropriate place for that discussion: Teletype codex: community github script repository

could one of the mods move relevant posts from here? i’ll post some thoughts there once it’s done.

3 Likes
#16

it’s not a full replacement - there will be many cases where you’d still prefer CV and TR. one example would be decoupling gates from pitches - imagine a sequencer where one pattern bank is used for gates and another for pitches and run them on 2 clocks that are not synced to each other, or a ryk m-185 (metropolis) style sequencer where each step can trigger multiple gates etc etc.

2 Likes
#17

‘find and replace’ will not work in all cases. you might have CV and TR on different lines or in different order, and you’d have to do it separately for each voice CV 1; TR.P 1 etc. you would also still have to do a proper set up for each device.

i think NOTE will actually help with readability and conveying the intent much better (and it’s very much in teletype spirit, as it gives you an easy way to express a musical concept).

here is a simple scene for 4 track 8 step pattern based sequencer (typing it all by memory so might not actually work!). let’s say it was originally built for just friends.

#I
L 0 3: PN.L I 8
JF.MODE 1

#M
L 1 4: SCRIPT 1

#1
T PN.NEXT - I 1
IF T: CV I N T
IF T: TR.P N

now let’s say we want to use txo instead. we have to modify the init script and script 1:

#I
L 0 3: PN.L I 8
L 1 4: TO.CV I V 5
L 1 4: TO.ENV.ACT I 1

#M
L 1 4: SCRIPT 1

#1
T PN.NEXT - I 1
IF T: TO.OSC.SET I N T
IF T: TO.ENV.TRIG I

now compare the above with a scene using NOTE. just friends version:

#I
L 0 3: PN.L I 8
NOTE.JF 1 1 4

#M
L 1 4: SCRIPT 1

#1
T PN.NEXT - I 1
IF T: NOTE I N T V 5 10

and txo version, one line change (in the init script):

#I
L 0 3: PN.L I 8
NOTE.TO 1 1 4

#M
L 1 4: SCRIPT 1

#1
T PN.NEXT - I 1
IF T: NOTE I N T V 5 10

one more thing to remember is changing a device this way is not just for scene sharing. if you have a scene that works with tt outputs and want to switch it to ansible (because you have a different voice patched to ansible) you either have to edit the script or repatch 8 cables. with NOTE you’re changing one line.

7 Likes
#18

This sounds/ looks awesome!

#19

To that end, would it make sense to have something that doesn’t affect CV but does send a timed gate, like this?
NOTE.GATE index volume duration

For the default Teletype mapping, it’d take the place of having to use two commands:
TR 1 1; DEL 500: TR 1 0
or
TR.TIME 2 500; TR.P 2

#20

yeah, i think it makes sense to have sub-ops that would allow you to change pitch / gate / volume for specified voice without affecting other parameters (assuming the device or devices currently mapped to this voice support it).

and perhaps NOTE.ON / NOTE.OFF / NOTE.P (which would be similar to TR.P) as well.

1 Like
#21

another cool thing about using dynamically mapped voices is that they are dynamically mapped. so you could create a scene that takes advantage of that. for instance, implementing a shift register with this approach would be trivial:

L 1 4: NOTE.TO I % + I O 4 1

7 Likes
#23

As always, @scanner_darkly, really thoughtful. Who would you propose take care of the duration property?
Is that something the TT would orchestrate (that is my assumption) or would supporting modules need to implement it?

#24

yeah, TT will handle it wherever possible. i don’t remember if just type allows it, so in some cases the duration value might be ignored and you’d just control it on the module itself.

same idea with attack and decay, they would be controlled via device specific means and wouldn’t be affected by duration, although i think it could make sense to also have general NOTE.ATT and NOTE.DEC ops for those devices that support it, like txo.

#25

Just Type can handle durations in ‘sustain’ mode, which really just requires a matching JF.NOTE (or JF.VOX if TT is handling voice allocation) with velocity = 0. Having automatic duration handling (like Max’s ‘makenote’) would be a welcome addition for people aiming to use it as a more traditional poly synth I think.

In general I’m a little confused about where the note allocation should be done. From the above it seems like the TT script would handle the note allocation directly. Is this preferable, or should allocation be handled by NOTE, making it a more traditional polysynth implementation. The obvious benefit of internal voice allocation in NOTE is one less argument to the op!

Of course there must be trade-offs to this approach, and I’d be curious to hear them!

#26

perfect, so duration can be supported for all devices.

re: note allocation - i’ve been debating a good balance of flexibility/usability. the most flexible form would probably be where you can map an arbitrary number of NOTE voices ot an arbitrary number of device voices. so then you could do things like:

  • one NOTE voice mapped to 6 JF voices, so when you play notes on that voice TT rotates through the 6 JF voices

  • 3 NOTE voices mapped to 1 JF voice, so all 3 NOTE voices get played on 1 JF voice - useful for adapting a poly voice scene for only 1 sound source

  • 2 NOTE voices mapped to 4 JF voices - both NOTE voices rotate through the 4 JF voices, might be interesting musically?

in this scenario you do have to specify NOTE voice explicitly. if you always want to rotate perhaps a separate op could be introduced, something like NOTE.R, but then it’s as short as doing NOTE 1 (although the former expresses the intent better).

the cool thing about allocating voices like that is that you could use both approaches at the same time. say, you could map NOTE voices 1-4 to JF voices 1-4 one-to-one, and map NOTE voice 5 to the same JF voices, but it’ll rotate.

another possibility to consider: mapping one note to multiple voices but instead of rotation specifying it as a chord. this would work well if you can also specify transposition separately for each mapping (transposition will be useful regardless if you layer multiple devices).

2 Likes
#27

i guess another question is, if you have the same NOTE voice mapped to multiple devices, when that voice is played should it rotate between them or play them at the same time? both options seem useful. another vote for being able to specify this behaviour.

1 Like