#453

Great to hear, need to go through the main threah but it sounds like the most crippling bugs have been ironed out then! thks

1 Like
#454

Its been working very well for me!

Definitely think of it as a sort of digital tape machine. A very versatile and flexible tape machine.

It will do one shot and pitched sample playback, but think of that as kind of a bonus? I’m sure that someone getting great use of it that way… but if you’re looking for something that does tight sample trimming and playback, there are other things that work better. I am not saying that to detract from what it does do.

What it does do, it does really well!!! SOUND On Sound on sound on sound … destructive looping warbly modulation, varispeed looping, absurdly long delays and on and on

EDIT: oh and that thing on the mannequins site

“W/ takes a nowness and returns it in a futurenow. Eight hours of audio sculpture to be recorded in and over and around. In fugues conversations fold, a fresh context for renewed identity.”

Is a really really great way to describe the “oh shit, when did I make that loop” experience I’ve been having with it when switching back to another tape

6 Likes
#455

Update on the SD card issue:

Got a new SD card(just to be safe)
Got a clean tape.bin file from a lines user (you know who you are)
Put the tape.bin file on a new card(32GB)

Result: it works! My recordings are no longer messed up by digital noise.

Sorry to have not gone the usual route @voidstar but as I said I was 100% certain it was a corrupt card. Turned out it was.

13 Likes
#457

I’m having trouble understanding the interplay between the modes, CV control and w/ type. I want to achieve a delay/sampler which moves forward and backwards and switches octaves (and ideally harmonises too). I can achieve most of this with WS.PLAY 1, WS.PLAY -1 and PLAY + up or down but I had hoped to automate it with TT. In fact, I hoped this would be achievable without TT with v1.2.1 and the THIS/THAT.

  1. I put THAT in TRANSPORT mode which is a linear tape speed control where -5v is x2 reverse and +5v is x2 forward. Add TT voltage to Cold Mac Survey, set Survey fully CCW and take LEFT out. Should I have a voltage range of ±5v corresponding to 0-10v form TT? Whilst it seems this is about right the pitch of the various playback speeds isn’t right (pitch of playback is off between octaves). (in this case I was sending 2.5v, 5v, 7.5v and 10v to Cold Mac). I noticed that @mdoudoroff’s recent videos illustrated that Cold Mac is not outputting exactly ±5v so I assume this is the problem.

  2. I put THAT in SAMPLE mode so now the tape speed is controlled exponentially. I set up a TT scene with various WS.PLAY -1 and WS.PLAY 0 commands and sent pitch CV direct from TT to THAT input (1v, 2v, 3v etc so that the octave jumps would be clear). What I would expect is that the voltage at THAT would determine the playback speed. What I found is that the w/type commands seem to dictate the behaviour. So I added WS.PLAY 0 commands expecting that if play is halted then the CV at THAT would take over. But this didn’t happen either, the play just halted.
    I though that the w/type, CV and THIS and THAT mix and matches were all interchangeable but I am having trouble understanding the behaviour. I suppose its user error or I’m miss understanding but can anyone see anything I am missing? Maybe @voidstar has some tips?

Edited for clarity

#458

@yoyosandshoes Did some very quick tests to confirm some things.

  1. With linear control (transport.THAT), I needed to send about 2.54 volts from TT directly into W/ to get precisely 1x speed, and 5.06v to get 2x speed (CV 1 VV 253 or CV 1 VV 506). This to me indicates that there is a calibration issue somewhere. Didn’t have a meter handy so I couldn’t check if it was the TT output that was slightly lower than it should have been, or if W/ has a slight negative offset on its CV pins - the latter seems more likely. Furthermore, if you are using CM to generate a negative offset for shifting your TT outputs down to -5 to 5, then the fact that CM SURVEY voltage does not precisely hit -5v at its minimum would absolutely affect your results.
  1. There is a known issue in which you cannot double/halve (PLAY+UP/DOWN) tape speed or reverse it (DOWN+PLAY from NAV or WS.PLAY -1) or set the tape speed to 0 (WS.PLAY 0) in LIVE, sample.THAT.
  • This is something that will likely be addressed in the next full update, however we have no roadmap for that release as we have tons of other stuff on our plates right now! The current expected behavior is that the tape is always moving forward, regardless of TT commands. WS.PLAY 1/0/-1 currently have no effect in sample.THAT. With no cable plugged in, the module reads it as 0v being sent in similarly to if a cable was plugged in, and sets the speed accordingly.
  • You have a 2 octave range above 0v and should be able to get the full 5 octave range below 0v (down to incredibly slow tape speeds). The reason the speed above 0 is capped is because of the need to write to the tape in LIVE mode precluding super fast tape speeds.
  • Similarly to the transport.THAT section above, you may need to send in ~1.03, ~2.03, etc. to get the precise octave shifts (verified this w/ TT).
9 Likes
#459

Thank you @voidstar I appreciate these updates and clarifications even if I don’t experience the problems personally.

1 Like
#460

Thanks @voidstar! The work that continues on w/ is not going unnoticed or unappreciated!

#461

@voidstar thank you for the response and doing the investigation to answer the query. It is good to know I am on the right track and I had been planning to work out the exact transport.THAT
voltages when I got time. Its possible that the voltage I require might be a little different anyway if its a calibrations issue.

I was actually querying the behaviour on sample.THAT but I infer from your response that the reference to signal.THAT is a typo?
It’s good to know this functionality is being addressed in the future. I’m imagining being able to have w/type controls interspersed with CV control of tape speed from elsewhere in the system.
One further question, is there a hierarchy of commands wrt w/type and CV? It appears that w/type operations take precedence over CV generally but given the above described confusion I’m unable to be sure.
Thanks again for your time and all the incredible work you all do at Mannequins. My favourite instruments

#462

Yes that was a typo! I have updated the post - sorry long day!

Currently, the hierarchy for the PLAY commands did not get entirely implemented, hence the bug
above! This is design work which will need to be done in the future. In general though, the latest value that the module receives for a given parameter should set the value of that parameter. With cables plugged in, the module will be continuously using the voltage on that cable to update the parameter, thus overriding whatever the last TT command was. There is still a question though as to how to interpret the polarity of WS.PLAY in transport.THAT.

  • WS.LOOP does not have any CV conflicts as there is no way to engage/disengage looping with CV.
  • WS.CUE could potentially have an interaction with using THIS in NAV mode or transport.THIS in LIVE mode - this is something we will need to make sure is working exactly as desired though the likely implementation will be that it does not trigger a redirect - I believe that is how it is currently functioning but not at a case to verify at the moment.
  • WS.REC interacts with dub.THIS - whatever the current recording state is, a trigger should always flip it. It also interacts with dub.THAT - whatever voltage is present at THAT should set the dub level when activating recording via WS.REC, not the polarity of the argument. Activating recording via TT is no different than activating via a button press or trigger.
  • WS.PLAY obviously has work which needs to be done I can’t say right now precisely how it will work as there are some considerations that must be made in relation to other commands which may be implemented! The main question is what should happen when you send in positive voltage but then run WS.PLAY -1.

Can you give me a specific example of this? As far as I am aware it should pretty much be the other way around as is?

#463

I think this clears up some confusion actually. I must be confusing the result of WS.PLAY commands with CV from TT into THAT. This is very helpful!

Thank you for detailing where the w/type commands are up to and the expected behaviour, I think this is useful info for others using this (and that).

EDIT: in dub.THIS the WS.REC seems to have precedence over THIS input. I have triggers running into THIS input and then execute WS.REC 0 (whilst play is controlled by voltage into sample.THAT) and I would expect to be punching in recording whilst recording is disable via TT but the triggers into THIS have no effect.

#464

edit: not a bug!

it’s been pretty quiet around here! i was stopping by to check for a w/type bug i ran into tonight, but it looks like the w/type-CV hierarchy issue that @yoyosandshoes was most recently talking about - i was using CV into THAT to control feedback while playing the tape, and then when i stopped the tape with WS.PLAY the CV didn’t control the tape speed like it usually would when the play button hasn’t been pressed. i had to manually start and stop play with the button for the CV to be recognized again.

side note: any progress report on w/ stuff from the whimiscal raps folks would be really really appreciated!

1 Like
#465

This sounds like not a bug. From the W/ Type page

  • nb: these settings will not change W/s mode. be sure to check the lights above the toggle to know which mode you’re in.
#466

ah! thank you for clarifying! that makes sense.

1 Like
#467
#468

can someone explain me better Sample alternate mode for THIS and THAT?
by my understanding THIS act as a sort of clock/reset to the latest cue (relaunching the cue sampled) and THAT set the speed.
In this mode act something like a “delay”? you record a cue, and by resetting you delay it right?

#469

I have been using it as a time-synced looper, with the reset into this coming around in time with a track of Kria. That track of Kria is sent into that to let me repitch what I’ve recorded.

2 Likes
#470

i recorded some of the audio crackling/overdub issues i have been having
this is fresh 1.2.1 install, fresh tape, no cue points set other than one initial to begin the recording. no cv control. no nonsense. fox only. final destination.

0:00 - 0:10 is audio straight from clouds, thru rosie, out into audio interface
0:12 - 0:50 is the same bit of audio recorded straight into w/ and then played back
0:52 - end is the same audio pitched down one octave (from clouds), then recorded into w/ in overdub mode. peeks from previous audio at :59, 1:21, 1:27.

#471

Thanks for the audio sample - could you make it downloadable so I can view the waveform in an editor (to see the clicks, rather than just hear them). I’m assuming the clicks are in the recorded material, so if you rewind and play again it retains clicks in the same place - could you confirm this?

Regarding the last part, it sounds as though you had tried to overwrite (not overdub?) the previous audio. The glitch at 1:21 is the previously recorded material being retained on the tape?

1 Like
#472

it is now downloadable. the clicks are in the recorded material.
you are correct, it is was overwrite, not overdub.
i am assuming it is the previously recorded material, it felt similar in sound. those are tiny blips though and i am not completely sure.

here are the full contents of tape 2 recorded as wav
it has a more extreme example of the clipping and overwriting clicks

https://www.drop box.com/s/x9jv8mne1o2moo7/help%20w%20wav%20full.wav?dl=0

just now, i switched to tape 3 and am unable to recreate the behavior. i switched to tape 2, fast forwarded to a blank area, and am unable to recreate the behavior. i havent cleared tapes yet.

1 Like
#473

Hi all. First post here. Glad to join lines :wink:

I got a used w/ couple of weeks ago. Started to really like how it makes me interact with the modular. But yesterday I came across an unpleasant discovery - i can no longer record without clicks and crackles. Every new recording I make gets distorted briefly, sometimes at loop points sometimes not.
It wasn’t like that before. W/ clicked occasionally on cue points but mostly it was barely noticeable. Now it’s not really possible to make anything but glitch music with it. :space_invader:
here’s a link to a video I took of the issue:

I really hope there’s a solution for this problem as I have planned to use it for my performance next week. :slight_smile: