|
Post by feijai on Mar 18, 2024 8:55:05 GMT
Neither TW's webpage nor the wiki seem to provide enough information to understand this unit. Can anyone help?
I'm trying to understand the NOISE ("R") output and the RANDOM CLOCK ("CLK") output.
I think from the Wiki that the Tap/Mode button controls the nature of the NOISE output only?
- When you set to "noise output", I presume this is audio noise? Does anyone know its spectrum or at least color?
- When you set to "random cv", what is this? Is this S&H CV?
- When you set to "random cv, smoothed", what is this? Does this linearly go from sample point to sample point? Or is it some kind of exponential curve, or what exactly? If it only has the last clock value, how does it know how long to spend smoothing?
- You can also tap the button to change the trigger time, else TRG 2 is used. Does this affect "noise output", or just the CV?
And then there's the RANDOM CLOCK output.
- What does this even do? It's not mentioned at all!
- Is it affected at all by the Tap/Mode button?
Last, the text says "Track and hold is a very unusual function to be offered even in modular world". But in fact T&H was somewhat common. For example, in the Eurorack world, the extremely common Doepfer A-148 had track and hold as early as 2003. Indeed, given the relationship between Doepfer and TW, I would imagine that A-148 is where the idea for T&H on this module might have come from.
|
|
|
Post by leethargo on Mar 18, 2024 10:03:57 GMT
I think that the CLK output corresponds to whatever was tapped in, but I can try later and also run some experiments for your other questions. Feel free to suggest patches to try, besides looking at the output in the scope/spectrum.
|
|
|
Post by leethargo on Mar 18, 2024 14:19:29 GMT
So the CLK output indeed simply sends triggers that correspond to what you tap in. Even if another clock is patched to the TRG2/CLK input, the CLK output keeps on its own tempo.
As for the R output, let's go mode by mode:
1) Does give audio rate noise. I can't identify the noise by looking at the spectrum in the METER module, but to my ears, it sounds quite similar to the A OUT of the NOISE module when the rate knob is fully clock-wise. So this should be white noise?
2) When you change into this mode, it outputs a step function, so piece-wise constant, based on its internal clock. If you tap a couple of times, it updates its internal clock. If you tap just once, it will follow the triggers from the TRG2/CLK input instead. I don't think the random values are uniformly sampled. It looks more like a random walk where a random step is added to the previous state, becaues sometimes the output gets stuck at either 0V or 5V for 2-3 steps.
3) Same as 2), but with linear interpolation between the samples. If you stop feeding in clock, the output will stay constant.
Outputs 1 and 2 are just for S&H and not related to the mode, in my understanding.
|
|
|
Post by leethargo on Mar 18, 2024 14:25:55 GMT
I also played with the T&H switch, which works as advertised (and expected). The output 1 simply mirrors what is fed in at IN 1 when the gate is high at TRG1, but holds the value when the gate is low. To my surprise, this switch only seems to affect the first S&H/T&H circuit, while the second one is always in S&H mode, regardless of the switch setting.
Also, for my earlier experiments with the random outputs, I used the rbss clock out, which worked fine. But nothing happened when I plugged this same clock into TRG1 or TRG2/CLK, so I used the square output of 2LFO instead, which worked fine.
Hope this answers your questions.
|
|
|
Post by feijai on Mar 18, 2024 14:57:26 GMT
Very interesting. It'd be really weird for the sample and hold to be a random walk! I hope I held onto my S&H module... And quite interesting to find that track and hold only effects one of the channels...
|
|
|
Post by leethargo on Mar 18, 2024 16:13:58 GMT
To avoid any misunderstanding, the S&H functionality (outputs 1 and 2) is separate from the random output ("R"), so my comment only applies to the latter.
|
|
|
Post by feijai on Mar 19, 2024 21:55:07 GMT
A random walk is okay to do, but there's a bug in its implementation. Normally a random walk works like this:
0. Let's say our bounds are 0...10
1. Start at random point X
2. Pick a value R under a distribution centered at, oh let's say -1 ... + 1
3. If X + R is outside the 0...10 range, go to 2.
4. X <- X + R 5. Go to 2.
A slightly faster but less well distributed approach would be:
0. Let's say our bounds are 0...10 1. Start at random point X 2. Pick a value R under a distribution centered at, oh let's say -1 ... + 1 3. If X + R is outside the 0...10 range X <- X - R 4. Else X <- X + R 5. Go to 2.
I think what the module is doing is probably this:
0. Let's say our bounds are 0...10 1. Start at random point X 2. Pick a value R under a distribution centered at, oh let's say -1 ... + 1 3. X <- min(max(X - R, 0), 10) 4. Go to 2
Or something along those lines. That should be fixed! That's why it's getting stuck a lot at the bounds.
|
|
|
Post by leethargo on Mar 20, 2024 7:23:30 GMT
Did you observe the same behavior? I hope that we don't interpret too much in my 5 minute experiment.
|
|
|
Post by feijai on Mar 20, 2024 10:58:03 GMT
Did you observe the same behavior? I hope that we don't interpret too much in my 5 minute experiment. Yes, same behavior. You get a lot of bounded S&H stuck at the bounds. It feels like a bug and, having built several random-wander and S&H things, I'm pretty sure I know what the bug is.
|
|