I am curious to hear what you will do with several W/'s :grinning:

I’m thinking one for field recordings and one for some THIS and THAT live loop recording mangling, but am open to suggestions!

set them to loop lengths that are mutually prime numbers obviously :smiley:

3 Likes

Curious if anyone else has encountered this, I have a dim recollection of reading something about this but am not finding it now. I’m relatively sure this is the v1.2.1 firmware based on the presence of alternate CV modes, but bought it used and have not personally updated the firmware image.

I2C control of W/ is working fine – for example WS.PLAY -1 or ii.wslash.play(-1) start reverse playback as expected – but all I2C get commands (WS.PLAY, ii.wslash.get('loop') return 7. I notice that all the help text on the W/ Type page and on the Teletype manual say that these ops are for setting W/'s state, so I’m guessing this is an indication that W/ doesn’t support getters yet, but would like confirmation of that so it can be added to the docs.

So the getters do not return the actual value - you need to use the event callback.

I2C queries/getters on Crow

Queries are values that can be requested from a connected device. This could be asking a clock device for it’s tempo , or an analog input device for the voltage at one of it’s inputs.

crow uses a query -> event model, which is different from teletype which has a functional approach. In teletype, you call the getter, it requests the value, waits to receive it, then returns that value as it’s result directly.

crow’s query -> event model separates the request from the response . While this approach is a little more complex, it allows crow to do a great many other things while it waits for a response to it’s request.

First you use ii.<module>.get( name, ... ) , which again can be copied directly from the device’s help() call. The ... here refers to a variable list of arguments which might be none at all! eg: ii.jf.get( 'run_mode' )

Then you can declare an event action to handle the response from the device. Copy it from the help() printout! it should look something like:

ii.jf.event( event, data )
    if event == 'run_mode' then
        -- the state of 'run_mode' is in the 'data' variable!
    end
end

Note that by default the event() defaults to a satellite action which is ^^ii.<module>(<event>,<value>) for eg: ^^ii.txi('value', 0.1)

2 Likes

Thanks, this helps a lot to understand the usage and the behavior I see in Druid.

This returns 7 for WS.PLAY, WS.REC, WS.CUE, or WS.LOOP without arguments. Executing the ii.wslash.get methods with the default handler also shows e.g. ii.wslash('play', 7.0) in Druid, since Druid currently just echoes Crow messages other than input stream and change events. (sidenote: I wonder if keeping the ^^ prefix on these when displaying them in Druid would help show the distinction between these “out of band” shell messages and output from the Lua REPL?) Given that ii.wslash events are firing, I gather that this means that W/ is actually sending a response with the value 7? On Teletype I have seen values like 27 for unimplemented command responses / unconnected devices since this is a fallback value
returned in the libavr32 I2C code when the receive buffer is empty.

So, wading through these threads is difficult. I tried to take notes but didn’t write down where I got a screenshot of a cheat sheet. The issue is that whatever I saw on this thread (or maybe it was on the general thread) is cut off. Does anyone have the full sheet?

If anyone has the full cheatsheet, please post here or email me sheddingDOTsoundsATgmailDOTcom

Thanks!

3 Likes

I found this recently too. That’s from this site. http://withw.rustle.works/

4 Likes

Cool - thank you. Wish it were an easily printable document, but I’ll take what I can get :slight_smile:

So, do the IN leds remain undefined on that page? It seemed to me that the yellow was input signal, white was the recorded output signal, but I could swear someone said it was a sign of an overdriven signal. Just wanting to clarify what the white led means…

1 Like

That I don’t know and I’m not seeing any mention of what the IN lights represent in the official documentation. Hopefully someone else here knows.

The LED on the left (orange) indicates the input signal level, while the LED on the right (white) indicates output signal level. Think of them as low-res VU meters for in/out. There is no “clipping” indication.

3 Likes

Beautiful. That’s what it seemed to be to me, glad to have it confirmed. Thank you!

This is a super helpful page (thanks @damon!), but I think the top light is orange in NAV mode and is white in CUE mode!

Pull request here.

3 Likes

Thanks for the PR, much appreciated! Site updated.

1 Like

i have a new Norns companion system and i need to get over my ineptitude with the W/
i am going to dig through this thread. Currently W/ runs amok with my system. i KNOW i recorded some cool shit into it Bowie, Alan Watts and some samples of music but i never ever know exactly where i am in/on the tape

3 Likes

Kind of the same here. I constantly get lost somewhere on the tape (usually in silence). I guess it’s mostly because I lose track of which mode I’m currently in. And once that happens, I often don’t know how to find back to where I was. Usually this leads to switching my rack off, clearing the tape and starting again.

I’ve gone through the tutorial video, the manual and the cheat sheets several times, but it’s still a bit hard to get an intuition for how to use the module. Most of the time I just use it as a simple tape delay (overdubbing into a fixed loop) but I know that it is capable of so much more and I hope that I’ll eventually get it :slight_smile:

placing cue points (toggle down while in Live mode, i.e. while the tape’s transport is engaged) could be helpful breadcrumbs left for finding the places on the tape where you’ve recorded something!

3 Likes

This is always indicated by the top LEDs in the module.

white + orange: LIVE
orange: NAV
white: CUE

One thing I find useful is:

  • turn LOOP and RECORD off
  • get to NAV mode
  • patch a bipolar offset to THAT (Cold Mac’s LEFT output is great for this, nice big knob)
  • use the offset to set tape speed (negative voltages go in reverse) to zip around the tape, manually slowing down when you hear something.
  • as you’re doing this, the brightness of the LEDs above PLAY indicate playback speed. Using Cold Mac you will get ~1x playback speed at the left-pointing (9 o’clock) and right-pointing (3 o’clock) tick marks, where as fully CW / CCW will give you fast forward / fast reverse speeds.
7 Likes

Thanks for your advice! I actually played around with this technique (using Cold Mac) a few weeks ago, navigating back and forth through the recorded material and adding new layers at different speeds. Definitely fun and a good starting point for further explorations, although more of an iterative process than something suited for a live performance.

A second w/ (or something like the Morphagene) could significantly extend the possibilities for this technique, allowing to bounce sample snippets between two tapes.

And a Teletype command for jumping to specific cue points by number would be perfection. Maybe sometime in the future…

1 Like