Did you play Izzy? If not, I highly recommend it
Ok ill try:) after the moonshine
I’ve seen a couple of methods for removing cue points, but for some reason I’m not having any luck with them.
method 1: in CUE mode go to the last cue and keep pressing R to delete all cues. This definitely does not work as advertised. Pressing R once removes the current cue, but pressing it again does not bring the previous cue to the forth.
method 2: in CUE mode hold LOOP and press DOWN to go to the starting point of cue, then press R to remove it. This one works, but after a power cycle the cues are all back again.
How are y’all getting rid of your unwanted cues?
I’m on Beta 11 by the way.
I’m trying this on Beta12 and I’m removing all the cues I just added to test this, work fine on my end.
Did you clear the tape after updating to Beta11?
Good to know, maybe I’ll have better luck with 12.
Did you clear the tape after updating to Beta11
No I didn’t. When you say clear the tape, do you mean to record blank signal on the entire tape or is there a specific procedure to clear it?
Select first the tape you like to clear:
Ah, thank you. I’ll try that.
Clearing the tape fixed the problem. Thanks for the help.
Hmmmm got a problem (beta12)
Where in the middle of using the rack. Not really (at least intentional w/) no cv at all just routing audio through and sometimes playing the present cue loop.
The cue changed to a very short one unintentionally and now i get nothing but orange blinking REC Led also after restart… whats that?
Did i accidentally do some wrong setting or its a glitch? Its unresponsive now. No other LED will react but the blinking orange REC one wich is constantly running in Pulses of 3 with a short pause between.
Should this go to help or here? I dont know
Edit. Only thing i can do is boot into boot loader
W/ Firmware Update (beta testers?!)
The 3-pulse record led means it can’t find the SD card. Make sure the card is seated correctly in the back of the module (next to the i2c port).
Since i never touched it. I hope the card werent corrupted or so.
Will check now
Fixed. Indeed it was flying around the case. Just like that.
Glad all is fine. Thanks Mate. (And probably this should be moved to help)
Using beta12, Izzy keeps coming back upon start-up although I finished all the steps until the end. Is there a combination upon start up to prevent this?
Can anyone shed light on the WS.CUE ops? I have been trying to get a script to start recording from a cue by WS.CUE -1 and WS.REC 1. It seems WS.CUE -1 jumps back to the cue before the last and puts me back into the loop before. I tried WS.CUE 0 but this doesn’t seem to do anything actually.
What I’m trying to achieve… A script punches in recording at the start of the loop. After a count (in the metro script) recording punches out and returns the playhead to the start of the loop (and optionally would insert an end loop marker at the end but I don’t think w/ type has implemented this).
Sorry if this post is too Teletype-y. Please move elsewhere if more appropriate.
This should work as you describe. Perhaps there is a bug causing it not to function. I’d suggest trying to use
WS.CUE 0 on it’s own to investigate the behaviour before adding
WS.REC x. There’s a possibility the 2nd command is being lost for some reason (though I do remember testing that this didn’t happen).
Thanks @Galapagoose I think it is working as expected now. For the benefit of others, and correct me if I am wrong, WS.CUE 0 will take you to the beginning (direction relevant) of the current loop. For example if playback is forward, even though WS.CUE 0 retriggers the nearest cue, it will always start at the beginning because it would loop from the end cue if that were closer when the command is called. Is this right? Then WS.CUE -1 will always take you to the previous loop and repeating this command will take you further back, which is where I was starting to get lost.
An issue that I have identified (not sure if its w/, TT or iic) is a slight delay is noticeable when retriggering the cue which is clear when WS.REC 1 is on the same script. I guess the delay could be from looping from being retriggered at the end cue or a communication/execution of the script delay? In fact I kind of like it because its very characteristic of w/ anyway especially when manually looping and overdubbing. But maybe there is something avoidable happening here?
I wonder what would happen if you put
WS.REC 1 before the loop cue, if it would be less noticeable the other way
So it works beautifully now thank you. The script that triggered the recording from the start cue point also triggered the metro script which progressed the sequence which was being recorded. I had the M.ACT 1 buried in the script too so I put that to the front and I think this probably had something to do with it too. TT lesson learned - sequence of events is very important. w/ lesson learned - it just gets better and better the more you dig
Just checking in about the W/, I’ve been restraining from getting one because of the bugs but it’s been a while now and wondering: is it finally ready?
I believe so but I’ve always thought so. I was one of the lucky ones who, although experienced most of the bugs reported at some point, could still explore and use it. I’d be aware that a lot of the learning curve and exploration can feel buggy at times until you worked it out. For example I still will get lost when I’m trying something new. My tips would be to use a new clear tape for each session when getting started. You get less lost and can just clear tape to start again. Also pay attention to the exact or gestures -it can be subtle. But definitely do it