EnvelopForLive icon indicating copy to clipboard operation
EnvelopForLive copied to clipboard

Brownian Delay SYNC and X-Y pad improvements

Open hems opened this issue 3 years ago • 4 comments

Currently i have a MONO Panner followed by a Brownian Delay but when i have only the DRY signal turned on the position of the signal is changing..

I was expecting the DRY signal position to stay the same position as the input sound?

image

On a side note it would be lovely to:

  • have feedback control on the delay
  • have option to SYNC the delay time ( currently i'm working on a metronome based composition so SYNC is really important for me 😭 )
  • the DELAY time is getting to MAX value when i move the X-Y pad horizontally to 50%.. Perhaps ideally it should be only when reaching 100% like the Freq Shifter?

overall, again, thank you so much.

hems avatar Jan 06 '22 21:01 hems

Caveat: this device I did not actually develop personally, so I am a bit less sure of all the intended functionality.

First thing I will point out, the E4L Brownian Delay does not take Ambisonics input from a chained device. It only takes regular stereo input. So the way you have E4L Mono Panner set to Chain output is not going to work properly. A device that can take a chained input will indicate that in the left gray bar (screenshot below).

As I understand it from looking at the implementation, all signal positions move on the E4L Brownian Delay, but the "Dry" signal does not have any time-delay applied to it whereas the Wet signals which also have time-delay.

I can see how this is confusing, but I believe this is what the implementation intends.

I will leave this task open as a feature request for possible future development, but will set expectations that this one isn't super likely to see improvements soon. You are definitely welcome to try to dive in and work on things like the feedback control, sync and x-y pad improvements. Cheers!

Screen Shot 2022-01-25 at 2 19 14 PM

mcslee avatar Jan 25 '22 22:01 mcslee

Caveat: this device I did not actually develop personally, so I am a bit less sure of all the intended functionality.

thanks a lot for looking at it!

First thing I will point out, the E4L Brownian Delay does not take Ambisonics input from a chained device.

This explains why i had such expectations!

It only takes regular stereo input. So the way you have E4L Mono Panner set to Chain output is not going to work properly. A device that can take a chained input will indicate that in the left gray bar (screenshot below).

thanks a lot for this explanation, this is valuable information i should have known ( as you can see i'm not 100% familiarised with the framework )!

i appreciate your time and patience explaining that to me.

As I understand it from looking at the implementation, all signal positions move on the E4L Brownian Delay, but the "Dry" signal does not have any time-delay applied to it whereas the Wet signals which also have time-delay.

I can see how this is confusing, but I believe this is what the implementation intends.

makes a lot of sense.

I will leave this task open as a feature request for possible future development, but will set expectations that this one isn't super likely to see improvements soon.

I think this turns more into a question than a feature request as if this was intended and the user ( in this case me ) have the right expectations then nothing is wrong with it!

You are definitely welcome to try to dive in and work on things like the feedback control, sync and x-y pad improvements. Cheers!

I definitely should be digging deeper into those devices and try to contribute in a more technical way than posting issues on github, hopefully i'll get to that soon.

again, thanks a lot for taking the time to explain and look at the device implementation.

hems avatar Jan 25 '22 23:01 hems

also please feel free to close the issue in case you believe this not to be a priority or to be relevant, i think the biggest issue here was my lack of understanding and not exactly the intended behaviour of the device.

hems avatar Jan 25 '22 23:01 hems

No worries at all opening the GitHub issues! Even if we decide not to change anything, it is very helpful for us to understand how people are using the devices and what kind of confusion is coming up, and it's nice also to have those questions documented here where other people can find them as well. So don't ever feel bad about opening up an issue even if just to ask a question.

I do think those are some good potential improvements you've raised here, so I will leave this one open, just with expectations set that it might stay open for a long time! :)

mcslee avatar Jan 26 '22 00:01 mcslee