#1

Is this the best place to discuss W/ Type? I read on the documentation page (https://www.whimsicalraps.com/pages/w-type) that W/ Type will be incorporated into Teletype 2.3 - and I don’t see a Thread dedicated to W/ Type.

I have just installed W/ Type and am in the process of investigating the new Ops.

One thing that is immediately obvious is that there is no way to check a W/ state rather than just setting it.

eg. It would be useful to be ably to poll the Play direction with WS.PLAY rather than just set it.

Please let me know if there is a more suitable place for W/ Type findings - otherwise I will continue to post here.

6 Likes
Mannequins W/ (with)
Mannequins W/ (with)
Teletype 3.0
#2

Teletype freezes under certain circumstances when a (Metro?) script is controlling the W/ and you manually operate W/ at the same time.

I will try to narrow it down…

#3

re: 2.3 - once W/ changes are merged to master i will incorporate them into the next 2.3 beta and link to this thread from the 2.3 original post.

3 Likes
#4

Some way of treating cues in through an absolute index would be very useful. It could work as postfix applied to operators, something like .A, as in WS.CUE.A. This could act both as a setter or a getter of the current cue location. That would open up the possibility of jumping over multiple cues and sequencing cues. It could be a lot of fun on grid interfaces. Going off the tangent of grid interfaces, I think an operator for getting the number of cues on tape would be necessary for many applications. An operator for adding or removing cues would also be nice. Again it could reuse the relative/absolute way of addressing cues for deletion.

I think the most useful way of giving speed control is through the volt/octave standard established by the Teletype DACs, as this would enable us to use either the N operator to specify notes, the JI operator to specify ratios, both in frequency and speed, or simply the V operator to specify half, full or double speed. I also think it would be good to have the operator accept negative values for reversing the playback. That might overlap weirdly with WS.PLAY though.

Edit: there was a brain fart: negative values don’t exist in a logarithmic scale… They just translate to division rather than multiplication.

5 Likes
#5

I wonder if cues are coded that way though - or are they just markers on the file which are identified as the tape head passes.

If they could be made addressable via an index - how many cues would be enough? It is currently possible to set several cues per second. I wouldn’t want to see the situation where it was impossible to set a new cue because a limit had been reached - or that it was impossible to set a cue at an exact location because cues had to be spaced a certain distance apart. How would you see it working?

I agree the possibilities for sequencing would be great.

Seconded. I would be very surprised if this wasn’t already planned.

I would like to see ops for sending a voltage into THIS and THAT, as in JF.RUN. Perhaps using the same system whereby a cable inserted over-rides the op (or is it the other way around?)

#6

I’m pretty sure it will be possible to create more cues on W/ than Teletype can handle in it’s own number format (which has 65 536 distinct values, assuming we use the negative values too, which is weird in this context). With 8 hours of tape, that equates to a cue every 430ms. But then why would you even want that? It isn’t so much of a problem really because this wouldn’t happen in the first place in actual use cases.

For creating cues, there’s two ways I see of doing it. The first, simplest one, would be an operator that creates a cue at the current tape location. This is straightforward and I see many uses for it. The second would be to specify a time. But this one is more complex and potentially less useful, because again we have to deal with the limitations of Teletype’s number format. The time format would need a parameter for seconds and one for milliseconds, because evenly distributing the 65 536 values over 8 hours gives us increments of 430ms, which is really coarse, and really weird to work with. An annoyance that comes from using two parameters is that getting the time of a cue should return two parameters. But as far as I know Teletype can’t deal with that. So you’d need a getter for seconds and one for milliseconds. To me this feels pretty convoluted.

Maybe a lot of this is wrong as it’s not clear yet if every tape is 8 hours or if they total 8 hours together. Speaking of tapes: why not an operator for changing tapes? This is the kind of thing that could be very useful in the I script.

With the corrected tape lengths, the 430ms intervals become 73ms while using both positive and negative values, and 150ms while using only positive

#7

They total 8hrs together. Each tape is 80mins.

1 Like
#8

Unfortunately this isn’t short enough to get to tenths of seconds without using negative values — which means we’d still need that second/millisecond format.

#9

Could it return seconds the first time and milliseconds the next time?

#11

That could work, but I think that could also lead to a lot of confusion. No other Teletype operator has this kind of context-aware behaviour. I think simply adding a .M or .S postfix might be the best thing to do; it doesn’t use up too many characters either, and makes everything explicit. This might get postfix heavy though.

1 Like
#12

I’d love a command for creating a number of evenly spaced cues.

1 Like
#13

I am probably misunderstanding but doesn’t OTHER behave differently depending on the last EVERY?

#14

You’re right, some operators have contextual behaviour, I didn’t quite explain my thought properly. If you look at operators that have contextual behaviour, like DRUNK, FLIP, Q, S, P, EVERY et cetera they all perform a function related to the operator’s internal state; calling them or their sub-operators alters this internal data, and this data is what we’re interested in using. In the case of our hypothetical operator, it’s only a getter, meaning it just polls some data and brings it back. It’s been the convention so far to have those not rely on internal states related to the way we call them, so that they perform the same action no matter what the order is.

2 Likes
#15

An operator to create a cue with an optional parameter which is the additional delay from the current time, in ms.

(The syntax is probably bad but this is just yo illustrate)
WS.CUE
-> create a cue at the current time
WS.CUE 1000
-> create a cue 1 second after the current time

This would make more sense than specifying the time in the tape as W/ seems to be more about relative than absolute.

Also, something to delete cues within a specified range would probably be useful.

4 Likes
#16

Also : visual feedback on TT of the current time (minutes:seconds:ms) and maybe the time between the previous cue and the next cue…

4 Likes
#17

Given that teletype has a delay op, I’d guess you don’t need the second version of cue.

#18

It would be different than a delay in TT though. That would only be roughly similar if W/ was playing at a speed ratio of 1 for the whole duration of the delay.

And then, the cue would be added later in “real” time, so any associated behaviour could be changed.

I still think the time offset parameter (which could be negative) would be extremely useful and very easy to understand/type.

#19

The purpose would be to create two cues at the same time - one for the start of the loop, one for the end.

#20

Hi all! These are some interesting ideas - as usual I’m going to badger you to articulate the use-cases of any and all of this. The intention is to keep the number of commands small, thus it would be great if the commands we settle upon each have multiple use cases, and interact in interesting ways. For example I do like the idea of a command to add a cuepoint, and agree that a single command that can add start & end is preferable to a command that makes a ‘loop brace’, as the former is capable of so many different functions!

A couple technical details:

  • There is a maximum of 1365 cuepoints per tape. This is a RAM limitation on W/ (most of the 512kb RAM is used to buffer audio from the SD card).
  • Deleting cuepoints will enable their reuse, however the list needs to be defragmented (happens on boot, or loading a tape).

If someone wants to delve into data visualization of W/s state on teletype I’d be very happy to help with the W/ side of the dev & any design elements (only if you want), but I will not be pursuing this myself. TT is already fully open source so all you’ll need is some added i2c hooks to access W/s state which should be relatively simple to implement on my side.

Regarding the timestamp issue, i wonder if there is a more musical way to articulate timing than seconds? I’ve used DAWs more than half my life, and still don’t have an intuition for hh:mm:ss in terms of musical time. BPM and divisions always seem much more natural to me. Internally W/ reads/writes audio in blocks of ~71ms (2688 samples), it can (and does) index inside of this range, but I do like it as a musically granular increment. The 2 main shortcomings are dialing in attack transients (read: zero-crossings), and tempo-locked loop sizes. Just some food for thought; yet another arbitrary format is probably not the best idea.

An aside: The W/ firmware will be open-sourced, but not until our internal feature-list is completed. I know some will baulk at this, and I’m sorry but we insist. At this stage, bugfixes are our priority. Please don’t ask me for a date, I will give nothing beyond “when it’s ready”.

20 Likes
#21

Handling time in a ms-agnostic way could work well as long as the basic time unit is not arbitrary.

In that case it would be useful to have an operator to define this time unit.

An easy to understand way would be to have some sort of tap tempo operator. The simplest version could take the interval between two TAPs as the time unit. A slightly more advanced version could use an average over more than two TAPs (but might require a reset option).

The simplest syntax for this could be :
WS.TAP

But then the non-obvious thing in terms of user understanding is that you need to do that twice to get a relevant result.

I also think that being able to specify this unit in ms could be useful for the more mathematically inclined of us so having that option would be nice. For that, there could be an optional parameter in TAP that, when specified, would set the time unit in ms.

WS.TAP 100
-> set the time unit to 100ms

After this, this basic time unit could be used for the CUE operator or other similar things.

WS.TAP 100
WS.CUE
WS.CUE 20

–> set the time unit to 100ms, create a cue at the current position, create a cue 2 seconds (20*100ms) after the current position

A different syntax would probably be better to be able to use TAP as an accessor too, and CUE defined just like that is probably quite confusing. This is obviously just a very rough first idea…

1 Like