#42

Hi, given the recent additions to W/ in 2.0 firmware (Mannequins W/2 Beta Testing) to the ii communication is someone already working on integrating new ops? I hope I could go around with at least trying to implement like two of them over the weekend but if someone is already doing this then maybe we could settle on just one fork.
By the way what would be prefered way of dealing with “legacy” W/ ops? Should they stay in WS namespace and 2.0 would have WS2 or should they be overwritten or something else altogether? Or maybe there is anything in new 2.0 firmware that would make the teletype integration problematic?
Disclaimer: I have not worked with ii before so I am maybe underestimating such task (or even if it is possible at the moment) so note to anyone reading this - please don’t get your hopes up yet :wink:

2 Likes
#43

My preference would be to replace the old ops, with ops relevant for w/ 2.0. I think you’re going to need more details of what’s been implemented (op numbers?) on the W/ side before you can make a start.

One issue with the w/ 2.0 ops, mentioned by Trent in the demo was the timestamp. If I have this right, given the size of the tape, it needs a larger int size than Teletype supports. I don’t know what length would be implied by sticking to Teletype’s int size. I don’t know what other work arounds might be possible. Perhaps a two arg set operator, and two ops for get?

1 Like
#44

I haven’t catch the stream (and it is not available at the twitch from what I see at the moment) but for timestamp problem with int size the first hacky idea that comes to my mind would be on ii side use timestamp till the available int size at teletype and timestamp + series of seek commands for anything bigger, and as you already mentioned play around with idea of passing two args to operator or even maybe defining precision for timebased values like there are for voltage, so for example you could have:

  • 10S - ten seconds
  • 10M - ten minutes
  • 500MS - five hundred milli seconds

or alternatively:

  • 10 - ten minutes
  • 10T - ten seconds
  • 10TT - ten milliseconds

But again I haven’t done any actual development on teletype in the past so take my ideas with a grain of salt :smiley:

#45

It’s worth pointing out that the only control there is on the TT side is to call the operator with whatever variables are defined. Any changes to the behaviour have to be implemented on the W/ side, and that’s not open source. So yes, there could be multiple ops defining the timestamp resolution, or working around it as I suggested, either of which could be resolved on the W/ side, but that’s not how it’s currently implemented.

#46

I’ve not looked at implementing this on TT yet mostly because it’s not part of my testing case. Adding the ops should be an easy (albeit tedious) process.

The w/2 ii spec is public already. you can see all the required details via the ‘wtwo’ open pull request on the crow github page.

Naming-wise, i’d suggest W/T, W/D and W/S. I used WS previously not realizing there could be ‘special characters’ in op names. The slash is skinny so 3 chars shouldnt be too long.

The only real issue with the timestamp commands is when TT requests a time from W/. The response is 4 bytes long so TT will probably just discard the second 2bytes. The data is 2bytes of seconds (that’s enough for +/-9 hours) and 2bytes of subseconds. I believe this uses 1V = 1second so (0…1638).

This means teletype can already get whole-second accuracy over the tape, but subseconds will require some thinking.

Regarding replacing the old ops, the REC and PLAY ops are backward compatible, and i can probably make that true for the others so the API doesnt break. If people want to move to W/T it doesnt really matter.

If someone has the skills & motivation to add TT support for W/2 and the new JF commands and crow commands i’d be very happy to compensate you with (your choice of) one of those modules.

7 Likes
#47

Here’s a link to that PR: https://github.com/monome/crow/pull/342

2 Likes
#48

Teletype can specify how many bytes it expects the follower to respond with. One way to deal with this is maybe by having two separate ops for seconds and subseconds, receiving all 4 bytes in each op, and discarding either the first two or the last two response bytes depending on which op was called.

3 Likes
#49

the most prominent style is to use dot notation, so would be W.T, W.D, W.S, but tt language has so many ops and styles now slash can also be used if it’s easier to remember.

1 Like
#50

A slash would look like an operator to me and the dot notation looks like a namespace… but it isn’t my language :slight_smile:

3 Likes
#51

How about just dropping the ‘/’, WT, WD, WS?

#52

I’d prefer that but it may upset the current WS op?

#53

How about WP for Polysynth?

1 Like
#54

It’s alive (somewhat :P)

IMG_5120
IMG_51202650×3533 1.86 MB

and quick check of w/synth controlled by teletype:

I have implemented most of the commands of w/ synth mode:

W/S.P voice pitch
W/S.V voice velocity
W/S.PV voice pitch velocity
W/S.PN pitch velocity
W/S.AR ar_mode
W/S.LT lpg_time
W/S.LS lpg_symmetry
W/S.C curve
W/S.R ramp
W/S.FI fm_index
W/S.FR fm_numerator fm_denomenator
W/S.FE fm_envelope_amt

Naming is just temporary and is mostly short hand of names in this file: https://github.com/monome/crow/blob/2348ecb01ff8603e3fb483a1235ba305d77337b0/lua/ii/wsyn.lua

Code is here for those interested (albeit it is 2AM here so there will be bugs probably): https://github.com/kfirmanty/teletype/tree/w/-2.0

And firmware hex file for those who are brave/impatient (but please backup everything on teletype before doing upgrade as I can’t promise that I haven’t break anything in the process of adding operators):
teletype.hex (623.0 KB)

19 Likes
Mannequins W/ (with)
Teletype and W/ 2.0 integration
#55

That’s some quick work! :slight_smile:
Slashes def look odd to me as an op… :stuck_out_tongue:

Can you speak to two or more with this implementation or is that depending on the W/ firmware?

1 Like
#56

Fantastic work! Bravo!!!

1 Like
#57

Again - this was my first experience with coding anything for i2c or teletype (so I could be making things up), but currently in what I have built every W/ synth mode op is sent to one hard coded address 0x76. So if you would have multiple W/ connected and every one of them in synth mode they would all recieve the messages. Every mode in W/ can recieve data in two address so you probably could communicate with another one using generic i2c teletype ops mentioned at the first post in this topic, or there could be something hacked together into W/S ops but all solutions that come to my mind at the moment would have some disadvantage:

  • W/S could have additional operator W/S.DEV which could accept either 0 or 1 so you could for example in first script set at top W/S.DEV 0 and send data to first device and in second script W/S.DEV 1 and it would then send data to second device (simillarly how you can change working patterns) but I would need to read more about how scripts are executed in teletype to make sure this wouldn’t break when using DEL etc.

  • teletype could keep track of polyphony on each connected W/ in synth mode and try to distribute voices when using .PV command such as if first W/ has polyphony of 4 voices and second W/ 2 voices W/S.PV 0 N 12 V 3 - would send command to the first voice of first connected W/ and W/S.PV 4 N 12 V 3 - would send command to the first voice of second connected W/. But this could very easily start to break with W/S.PN operator which doesn’t specify the voice and any take on algorithm to this on teletype could clash with the one on W/ and of course this still wouldn’t allow to send specific parameter changes to W/ of user chosing.

#58

In the livestream Trent mentioned that any w/ on i2c would receive messages depending on its mode. So you could send messages to a w/ in synth mode and messages to a w/ in delay mode at the same time, but if they were both in synth mode they would only be able to receive one set of messages. At least this is how I understood it…

#60

This would make sense.
I’m just thinking of 8 voice synths in 4HP or maybe offset delays. I haven’t had chance to play yet to discover.

#61

EDIT: Updated with tape ops
My kid is sleeping today during the day (which is not so frequent) so I did another take on i2c integration - delay and tape params (taken from this file: https://github.com/monome/crow/blob/2348ecb01ff8603e3fb483a1235ba305d77337b0/lua/ii/wdel.lua and this: https://github.com/monome/crow/blob/2348ecb01ff8603e3fb483a1235ba305d77337b0/lua/ii/wtape.lua):

W/D.FBK
W/D.MX
W/D.LPF
W/D.FZ
W/D.T
W/D.L 
W/D.P
W/D.C
W/D.FR
W/D.R
W/D.F
W/D.CLK
W/D.CR
W/D.PL
W/D.MR
W/D.MA

W/T.R 
W/T.P 
W/T.REV
W/T.S
W/T.F
W/T.PL
W/T.ML
W/T.RL
W/T.HO
W/T.LST
W/T.LE
W/T.LA
W/T.LS
W/T.LN
W/T.T
W/T.SK

As is with synth names - they are temporary and you can only set values - no way of retrieving params from W/ for now - sorry.
And for the brave souls here is the firmware file:
teletype.hex (631.1 KB)
If you will notice any bugs (and there will probably be a lot of them) please let me know, hopefully I will have some time next weekend to fix them.

5 Likes
#62

i’ve added your beta to the list in the OP - when you post a new version can you update it so that it’s easy for people to find the latest version? (and also to avoid confusion as we have several active beta versions right now).

1 Like