How about combining both time setting and tap tempo in a single operator, using the same convention as Just Type? We’d get a WS.TICK operator that takes a single number, which is either sent repetitively as a tap tempo with a number up to 48 representing the number of ticks per measure, or sent a single time with a number between 49 and 255 representing BPM.
I think the most musical way to go about adding delayed cues is to express the delay as a fraction of a measure. For instance, 1/1 is just a single measure, 4/1 four, 1/3 a triplet. This gets really interesting with multiple w/, as it becomes very easy to create synced loops or polymetry. For example, say the first one is 5/4, the second one 1/1. You get 5 against 4. You can also play with the denominators too, with 2/3 and 1/1 for example.
I like TICK (I use that sort of stuff almost everyday at work ) but the arbitrary threshold for different parameter behaviour seems a bit strange/not very intuitive…
I feel like ws.play 2 and ws.play -2 as double speed forward and double speed backwards is a must. Although I see now that it makes the play controls more complex (ie what about -3??). Maybe ws.double might cover a number of scenarios. And also, as mentioned above, a way of inserting cue points so that you can sync to a clock, although ws.cue 0 is a good workaround and also delivers the unpredictable character that I love about w/ especially when modulating play direction.
Apologies if the commands don’t make sense - I’m new to Teletype - but I think you get what I’m getting at.
ahhhh, a linked-list structure explains the CV and TT control paradigm for cues. also makes sense for thinking of the tape as a 90-minute tape loop, rather than an off-the-shelf cassette—one could think of the start of the tape as just where the two ends meet, useful only for orientation purposes. So without a rewrite, it looks like absolutely-indexed cue navigation will be unlikely.
I wonder if it would be interesting to disconnect the order of cue points from their position on the tape? Probably would require users to have a pretty complicated mental model of the module’s state though…
It also seems like splitting the record and play heads further apart will be unlikely given RAM limitations (also since the only use cases I can think of are delays, of which the ‘regular’ kind are well covered by setting loop points).
I agree that Teletype control of tape speed sounds interesting, although it does seem better suited to knob or CV control to me than scripting.
This week I wanna try disconnecting play state from mode and see where that gets me… just need those headers to get here!
TT controlled tape speed is definitely forthcoming, but it requires answering some difficult questions about design. I wish I’d had more time to think of this by now…
@alanza
The LL structure isn’t that constricting. Max number of cues is ~1300 per tape, so even worst-case scenario it’s only 650 steps, which actually doesn’t take that long! The firmware already attempts to find cue-points in an absolute fashion if it discovers it’s out of place. Also the NAV.THIS redirection uses this same absolute referencing already.
Ultimately I’d like there to be relative & absolute accessing modes available and we’ve been discussing some syntax for it.
The goal is to have as few operators as possible such that they are combinable to implement vastly different control structures without needing to remember too many things. Like most of our creations, technical limitations are typically not the barriers, but rather it’s in finding the right abstraction.
Not sure if this has been mentioned or implemented yet, but being able to clear a tape of audio and cues without power-cycling the synth is my number one feature request/need
EDIT: I guess that’s not really a TYPE feat request, but
Interesting. Thanks. Technical and logistical issues aside, I would argue that it’s definitely a performative command (or at least something needed to enhance the speed and smoothness of certain performative gestures). I routinely use the 10-20 sec tape loop sound on sound mode on my el cap, which lets you clear all the sound in it’s buffer by triple tapping one of the switches and have found that feature very useful on stage. Use cases include: easing the transition between sections, rapidly shifting/dropping density of sound for a sudden transition, quickly escaping a badly timed or poor loop. Also, clearing dumb sounds from soundcheck without power-cycling the synth makes sound-check potentially much easier (of course if clearing a tape makes a giant pop that’s probably no good either, tho powering down kind of does that, too). Finally, it makes recording much faster because you can quickly try different ideas and clear loops that don’t work without fiddling with feedback or cue point or whatever.
have you tried doing these things with CV into that in live mode? I agree about these effects being useful for performance, and I’ve found that to be a really effective and musically interesting way to clear space
(another possibility could be engaging overwrite record either through buttons or Teletype?)
Yeah, currently I just turn down the feedback (that) if I want to overwrite a loop live. But if your loop is, say, 3min long it still limits the type of transitions you can make. Not that that’s always a bad thing. Just different from how I like to work sometimes. It’s much closer to working with real tape.
yeah that’s fair. although, with overwrite engaged, shouldn’t you never hear your old sounds again regardless of loop length? guess I should play with this some more.
It’s probably so obvious that it doesn’t need to be mentioned, but direct control over THIS and THAT is a must. It would be cool to be able to initialize a script that pops you straight into a “tape delay” type of effect, then use PARAM, Txi or a script to dynamically control variables.
I agree. I do like how the existing “play” command decouples the “play” state from the module’s mode, though, and it would be interesting if we could find a way to do something similar with some of the this and that functions.
Seconding this. Also, just output volume control would be good for mixing scenarios, and also shaping via Teletype “envelope” or LFO.
Another idea: a TW mode which pairs or groups multiple W/s together so they can be addressed simultaneously. Good for stereo scenarios, or recording multiple voices at once to create ‘stems’ that can then be manipulated independently.
Even cooler would be if the grouping mode also applied to physical controls, so that once say 2 W/s are paired they can be controlled from the switch and buttons together. This would make for a playable stereo pair. I don’t know if this is possible with sample accuracy over i2c (or at W/s subdivision rate) but it would be neat.
There is some control over output volume in live mode via negative offset into that! (and possibly recording nothing)
I’m actually pulling hard for the opposite use case—being able to address multiple W/'s separately over I2C, but I also would appreciate synchronicity.
I keep feeling like a great level-up idea for W/ Type is on the tip of my tongue lately…
This is good! I would love for it to be decoupled from mode though and also directly addressable.
Oh I would definitely want that and I guess, since I don’t yet have multiple W/, asks a question: is that what happens now if you have multiple W/ on your network? I.e. ws.play -1 sets all your networked W/s running backwards?
) but the arbitrary threshold for different parameter behaviour seems a bit strange/not very intuitive…