u-he Colour Copy - public beta!

[pdxindy]

For me personally, what William describes is much less useful for me than a full reverse mode (even with the knowledge that enabling this button will increase latency)

What am I missing?
rsp

How would that work? What would be reversed?

[zvenx]

I think an example may best exemplify it.
This is Tkdelay (a demo version so sound mutes may occur)
I was trying to find their manual to better describe it.

here is the guitar dry
https://www.dropbox.com/s/79g93hd0x312ni6/dry.mp3?dl=0

regular delay (reverse at 0)
https://www.dropbox.com/s/torsbb4ge9brx ... 0.mp3?dl=0

reverse at 50
https://www.dropbox.com/s/ttoablfct5xtm ... 0.mp3?dl=0

reverse at 100
https://www.dropbox.com/s/75kimaredw3di ... 0.mp3?dl=0

sadly kvr doesn't allow dropbox streaming. you would have to right click and download to play.


rsp

[sleepcircle]

I THINK what you're missing is that bucket brigade delay is not a single buffer of arbitrary size that gets cut up and manipulated as a single collective piece, it's hundreds of tiny tiny bufferlets operating in a continuous 'stream' where the output of each buffer is attached to the input of the next buffer from millisecond to millisecond. There is no single moment you can buffer up until, reverse, and subsequently work on, because bucket brigade takes each fraction of sound AS IT ARRIVES and begins to send it through a series of mini repetitions which can take anywhere from a tenth of a second, to ten seconds to complete die away (based on regeneration amount).

Furthermore, the delay operates not only on what has happened already, but what is going to happen an arbitrary amount of time in the future, because each bucket gets a drop or two of the current sound as well as the mixed contents of all the previous buckets, and because what happens to the contents of the bucket (in colour, transient quality, compression, smear) is very VERY sensitive to the pitch, volume, etc. of the bucket contents itself.

To get 'full reverse' you'd be constantly interrupting and partitioning a process which relies on thousands of microscopic, organic changes over time for its sound.

If Colour Copy had 'full reverse' mode like you're thinking about—which I DO appreciate the use of; I love Backmask by Freakshow Industries—then it would be extremely hard (I want to say next to impossible, but I'm no programmer) to maintain the super smooth rate-shifting, moment-to-moment feedback mixing and gentle smear that is the whole reason for bucket brigade delays to exist.

[zvenx]

I THINK what you're missing is that bucket brigade delay is not a single buffer of arbitrary size that gets cut up and manipulated as a single collective piece, it's hundreds of tiny tiny bufferlets operating in a continuous 'stream' where the output of each buffer is attached to the input of the next buffer from millisecond to millisecond. There is no single moment you can buffer up until, reverse, and subsequently work on, because bucket brigade takes each fraction of sound AS IT ARRIVES and begins to send it through a series of mini repetitions which can take anywhere from a tenth of a second, to ten seconds to complete die away (based on regeneration amount).

Furthermore, the delay operates not only on what has happened already, but what is going to happen an arbitrary amount of time in the future, because each bucket gets a drop or two of the current sound as well as the mixed contents of all the previous buckets, and because what happens to the contents of the bucket (in colour, transient quality, compression, smear) is very VERY sensitive to the pitch, volume, etc. of the bucket contents itself.

To get 'full reverse' you'd be constantly interrupting and partitioning a process which relies on thousands of microscopic, organic changes over time for its sound.

If Colour Copy had 'full reverse' mode like you're thinking about—which I DO appreciate the use of; I love Backmask by Freakshow Industries—then it would be extremely hard (I want to say next to impossible, but I'm no programmer) to maintain the super smooth rate-shifting, moment-to-moment feedback mixing and gentle smear that is the whole reason for bucket brigade delays to exist.

Thanks, I am sure what you are saying makes sense.
Will re-read and digest.
rsp

[sleepcircle]

hahah, it might not make sense. i am a notoriously disorganized thinker.

[u-he-william]

You can't really reverse a signal, that would mean that we could somehow know the future. All we can do is cut audio in parts and then reverse those parts but that requires us to delay the signal at least for the length of the parts. However, this is one of those features that you can't just add to any delay. It has some requirements on how the thing is structured internally. However, with CoCo sticking to what you would find in a BBD, that's basically out of the question.

There are some ways I though of and all have big disadvantages. If you want to know:

- Reverse delay line direction, write at 100%, read from tap
Think about CoCo as a tape, we have a write position on the left and a read position on the right. The tap is somewhere in the middle. Now instead of moving the tape in one direction, we just flip the direction and move it back again. The cool thing is that the signal would more or less be continuous, no need to cut it somewhere.
The issue here is that we change the way the taps work. Example with taps at 75%: Playing forward, the first echo delay would be (taps - in) = 75%. In reverse, it would be -(taps - out) = 25%. With the taps being at 100% in most use cases, that would mean we get really short first echo's, probably in the range where we get phase cancellation.

- Reverse delay line, write at tap, read from input.
Basically, reverse everything. We read were we once wrote, write were we once read. That solves the issue described above but it also means that odd stuff happens when we flip between forward and reverse. Basically, reversing the direction would mean that we cut the signal and, depending on the tap position, write the signal to some random position in the BBD. I didn't test that but it probably sounds odd and non-intuitive.

I'm still a fan of the first approach since it's at least really intuitive and doesn't change the mechanics of CoCo. One could even have a linear playback speed that goes down to -100%. Move it past 0% (super slow signal) to -100% were stuff just starts to play backwards.

[zvenx]

Is this pertinent?
https://www.electrosmash.com/back-talk- ... delay.html


and maybe after reading this: https://www.premierguitar.com/articles/ ... ade?page=1
I will understand why it may be technically not possible?
rsp

[zvenx]

You can't really reverse a signal, that would mean that we could somehow know the future. All we can do is cut audio in parts and then reverse those parts but that requires us to delay the signal at least for the length of the parts. However, this is one of those features that you can't just add to any delay. It has some requirements on how the thing is structured internally. However, with CoCo sticking to what you would find in a BBD, that's basically out of the question.

There are some ways I though of and all have big disadvantages. If you want to know:

- Reverse delay line direction, write at 100%, read from tap
Think about CoCo as a tape, we have a write position on the left and a read position on the right. The tap is somewhere in the middle. Now instead of moving the tape in one direction, we just flip the direction and move it back again. The cool thing is that the signal would more or less be continuous, no need to cut it somewhere.
The issue here is that we change the way the taps work. Example with taps at 75%: Playing forward, the first echo delay would be (taps - in) = 75%. In reverse, it would be -(taps - out) = 25%. With the taps being at 100% in most use cases, that would mean we get really short first echo's, probably in the range where we get phase cancellation.

- Reverse delay line, write at tap, read from input.
Basically, reverse everything. We read were we once wrote, write were we once read. That solves the issue described above but it also means that odd stuff happens when we flip between forward and reverse. Basically, reversing the direction would mean that we cut the signal and, depending on the tap position, write the signal to some random position in the BBD. I didn't test that but it probably sounds odd and non-intuitive.

I'm still a fan of the first approach since it's at least really intuitive and doesn't change the mechanics of CoCo. One could even have a linear playback speed that goes down to -100%. Move it past 0% (super slow signal) to -100% were stuff just starts to play backwards.

more reading .
I posted my stuff above whilst you were posting so it wasn't responding to what you posted here.
re: Future, But isn't that what look ahead features in limiters/compressors etc do and increases their latency? That is they can read ahead in the track? (the assumption is that it is a recorded track and not live playing).

rsp

[u-he-william]

Mhh, some diagrams in the first link look helpful. It's not really a limitation of BBDs. It's a conceptual issue. You can only reverse a signal by cutting it in pieces and reversing those. And this requires some structure that is designed to do that. We didn't have that feature in mind when we started with CoCo. Recently I came up with a different structure for a delay that would at least solve the tap-position latency issue but I don't think Urs will let me code another delay weeks after CoCo was released.

And it's also not a question of whether or not it's doable. It's a question of how nice the feature works and how usable it is.

Look ahead in compressors usually is a few milliseconds. A reverse would require latency to be the length of the reversed block, so probably a good part of a second. But that's not really an issue, it's a delay, it will delay stuff anyway.

[zvenx]

lol
Indeed I don't think he would.
Was worth an ask.
That is what I have missing from my arsenal.
Crystlalizer to me is way too complicated.
TkDelay is too vanilla sounding for me, but I may end up getting this.
Bloom sounded great and had the right features, but alas....

thanks
rsp

[Funkybot's Evil Twin]

- Reverse delay line direction, write at 100%, read from tap
Think about CoCo as a tape, we have a write position on the left and a read position on the right. The tap is somewhere in the middle. Now instead of moving the tape in one direction, we just flip the direction and move it back again. The cool thing is that the signal would more or less be continuous, no need to cut it somewhere.
The issue here is that we change the way the taps work. Example with taps at 75%: Playing forward, the first echo delay would be (taps - in) = 75%. In reverse, it would be -(taps - out) = 25%. With the taps being at 100% in most use cases, that would mean we get really short first echo's, probably in the range where we get phase cancellation.

Maybe I'm being overly simplistic, but couldn't you also quietly adjust the tap position behind the scenes to compensate? So taking your example: Taps at 75% playing forward, becomes taps at 25% playing backwards. But what if hitting the hypothetical reverse button, compensated automatically? So Taps at 75% playing forwards, gets adjusted to taps at 25% playing forwards and 75% playing backwards as soon as you hit the reverse button? This way 75% forwards would remain 75% when backwards. The user wouldn't even have to know.

Or would that not work at all? Both math, and time travel, are not my strong suits. Also, I'm fine with CoCo as is.

[u-he-william]

Yep, but might also be undesired. But probably the best solution.

[kvr@barder.net]

A question that I am sure someone will have the answer to please. Which controls do I adjust on Colour Copy to achieve the same effects as I can with the Groove and Feel dials in EchoBoy?

Thanks in advance.

[u-he-william]

I couldn’t quite figure out what groove does just yet. But for the “feel“ part: Play around with the taps to create a rushing effect or an multi tap / stereo pattern effect.

[kvr@barder.net]

Here are the details - can anyone advise if Colour Copy allows these adjustments. Many thanks in advance.

GROOVE
The Groove control allows you to impart a ‘groove’ feel with EchoBoy in one of two flavors: Shuffle and Swing. Setting the knob straight up at 12 o’clock is the ‘zero’ setting and no Shuffle or Swing feel will be imparted on the echo pattern. Groove control adjustments create shift either forwards or backwards to the “even” beats towards a triplet type groove.

As you turn the knob counter-clockwise towards “Shuffle”, an increasing amount of shuffle feel will be added to the echo rhythm. As you turn
the knob clockwise from the center “0” setting an increasing amount of swing feel will be imparted on the tremolo sound. The amount of Shuffle or Swing dialed in with the knob will be relative to the currently set Rhythm. Groove settings are imparted on the signal regardless of the type of modulation used, the rate, or the rhythm setting.

FEEL
The Feel knob is similar to the Groove control but in this case shifts your whole delay output in relation to the beat, not just the groove of the pattern. The Feel control is like being able to control how echoes play
in relation to the “pocket”; should they relax slightly behind the beat or propel the movement forward, slightly rushing the tempo?

By turning the control counter-clockwise an increasing amount of delay is imparted on both left and right channels before echoes are heard, similar to pre-delay in reverb. We called this one Draggin’ because it has the effect of sliding behind the downbeat. As the control is increased, delay is added the effect will fall further and further behind the down- beat.

On the other end of the spectrum is Rushin’. Instead of sliding the modulation behind the beat it begins to move it ahead of the beat. This is kind of like adding a negative pre-delay. As you turn the knob further towards the maximum value, echoes will be moving increasingly ahead of the beat.