EchoLab - (closed) beta test - release candidate 1

[Music Engineer]

What types of sounds are the best to use for testing?

i like to play short minor chords with some synth-stab like sound. this lets you clearly here the time-structure of the delays:

www.rs-met.com/democlips/delaydesigner/SynthStabDry.mp3
http://www.rs-met.com/democlips/delayde ... ousy3c.mp3

...and sounds pretty cool (IMHO). i'd say, instant house in this case. actually i don't really like house ...still this sounds cool. percussive sounds are also good for hearing the time structure. with slow, pad-like sounds on the other hand, you may be able to create some kind of reverberant impression with short delays (but this does not work on percussive sounds though, so it's not really a replacement for a real reverb)

[Music Engineer]

man i didnt even hear you were looking for beta testers,or else i would have volenteered

yeah, sorry. it was announced in the effects forum. it was full pretty quickly.

[Musical Gym]

thanks for tips and demos

[Music Engineer]

so here is a new version to test:

www.rs-met.com/software/betas/DelayDesigner_beta004.zip

as forecasted, this new version now incorporates the demo-version / keyfile detection mechanism and participants of the beta test are now entitled to get their keyfile. i would need some personal information in order to generate it. that would be: real name and postal address and email address (you can send this to me via email and it will - of course - be treated strictly confidential). i also want to encourage to test / verify whether this mechanism works as it should.

...and for fun, here's yet another democlip:

www.rs-met.com/democlips/delaydesigner/ThirdsDry.mp3
http://www.rs-met.com/democlips/delayde ... gBall3.mp3

[Music Engineer]

ah, and the way it 'should work' is as follows: without the keyfile, the plugin will run in demo-mode and inform the user about it by writing 'DelayDesigner - Demo Version' as headline on the GUI. after 20 minutes of use, the output will be muted. if the keyfile is present (in the same directory where the plugin resides), the GUIs headline won't have the ' - Demo Version' part (and no output muting will take place)

[pedrorf]

after 20 minutes of use, the output will be muted.

I've been driven mad lately by a demo that times out every 30 seconds or so, so cheers for a generous demo policy

I'm sending my personal info by email.

[Music Engineer]

after 20 minutes of use, the output will be muted.

I've been driven mad lately by a demo that times out every 30 seconds or so, so cheers for a generous demo policy

30 seconds? and then you have to reload? that's indeed a bit short. ...more than a bit. i forgot to mention that total recall by the host is also disabled in the demo version (this doesn't affect the internal preset management though).

I'm sending my personal info by email.

yup - received. keyfile sent.

[Dozius]

Tested with and without key. Protection scheme working here.

[pedrorf]

Same here.

[Music Engineer]

i'm glad to hear that. seems like we are approaching v1.0. regarding to the list of bugs and feature requests from the beginning:

-right-click -> enter value (on sliders) does not yet work

just checked - mmm...still doesn't work - will look into it

-in some hosts, keyboard input does not work - i.e. is taken ("stolen"?) by the host

on double-click, this works now over here (with VSTHost, where it formerly didnt)

-take away keyboard focus when clicking on an empty area

done

-the feedback-loop is unbounded which may lead to instability (in the sense of infinite signal buildup) for some settings

feedback loop is now bounded by a clipper - this leads to distortion when feedback is above 100% (at some frequency) but not to indefinite growth anymore.

-snap-to-grid setting not recalled when closing/re-opening the GUI (in some hosts - FL)

fixed

-sometimes, a new EQ band is inserted when the user wants to grab an existing one (grab-area of equalizer handles seems to be smaller than drawn dot?)

i enlarged the grabbable area a bit - fixed?

-pan/feedback adjustment in the graphical editor with shift- (or ctrl-) dragging

done

-insert first EQ handle when user selects EQ mode via dropdown box

widgets are now grayed out when no node is selected - i think this makes just as much or even more sense?

[Chester Desmond]

In Tracktion 3, the demo timed out as it should, and key file also worked to remove the limitation.

In beta 4, flush doesn't seem to be functioning, whereas I'm sure it did in beta 2.

One thing that I forgot to mention is that in both Reaper and Tracktion 3, the preset list in the GUI will not pop open to allow selection of preset (perhaps by design, but that behaviour is different from nearly all other vsts I've used).
Also with most vsts the host itself has a dropdown or pop up that allows the user to view all of the presets and make a selection .. this is empty in Reaper and non-existent in Tracktion 3.
When the plugin is first loaded, the preset box shows "StateAsRequestedByHost"
Even the tool-tips when you hover over any of the buttons in the preset area don't seem correct, ie 'load setting from state file', 'save current setting to state file' ... they don't seem like "consumer" terminology but more like a programmer's notes or deafult programming language type of thing.
The only way to browse the presets is with the + and - buttons, which works fine but is a little tedious if the preset you want is late in the list..

I know I said earlier that everything was great, but I've dove in a little deeper to nitpick now that you are close to release.
The plugin right now is very unique and powerful, so I don't want to give the impression that I'm not excited by it! Stability is excellent and there's nothing really that seems non-functioning. Most of my comments below are simply preferences.

Some other things I'd prefer and\or find useful (or I may be missing them):

The ability to select all nodes for group manipulation and a lasso\rectangle tool to select only some nodes. Being able to de-select by clicking outside the grid would be handy too. Having to select each node individually is tedious once you've got more than a few; ie if you just want to adjust the overall gain or shift them in time or apply the same filter\eq settings to all.

I find the one-click aspect hard to get used to. It is way too easy to add or delete a point accidentally. I would prefer a double click add\remove kind of behaviour. Most specifically in the timeline graph..the lower ones I don;t notice this as much.

The mousewheel behaviour of horizontally zooming is useful, but you have to first select a node to get it to work. Since it appears to zoom relative to that node, I assume this is the intention, but I would prefer for it to zoom in relation to the mouse pointer without having a node selected.

Vertical snap would be nice.

Overall, it seems like the node\graph idea could be expanded to include a visual indication of feedback (maybe the node gets bigger or changes colour and this would be adjustable with mousewheel?) and a second graph (or some kind of visual clue) showing (and allowing) pan positioning would give a good overall picture of what the sound is going to do.
As it stands, a user has a good indication of what is happening temporally, but then has to select each node to get further details and or tweak anything which is not time related.
I just think that it could be more powerful if it was a little less "individual node-centric" and presented a more obvious picture of the whole effect.
On the other side, I will admit that the ears should be doing most of this I guess.

[Dozius]

I also think that multi-node selection would be a good idea as well as visual representation of the other delay line parameters. For pan you could have a little horizontal line/handle coming out of the ball, it wouldn't actually be selectable but just a visual indication.

[Music Engineer]

In beta 4, flush doesn't seem to be functioning

not? it works over here. what exactly do you do and what happens? but i see some issue still: the button should not be disabled when no node is selected as it is a global one.

One thing that I forgot to mention is that in both Reaper and Tracktion 3, the preset list in the GUI will not pop open to allow selection of preset (perhaps by design, but that behaviour is different from nearly all other vsts I've used).
Also with most vsts the host itself has a dropdown or pop up that allows the user to view all of the presets and make a selection .. this is empty in Reaper and non-existent in Tracktion 3.

yes, these are both by design. as for the host-based preset management: that is generally not supported by my plugins because it's kinda incompatible with the ways, i do these things. and what you called 'preset list' is actually just a simple text-field. i aggree that would be desirable to turn it into a popup menu, but i don't know if/when i can manage to implement that.

When the plugin is first loaded, the preset box shows "StateAsRequestedByHost"

that actually indicates that the host has stored and later recalled the state of the plugin as it normally happens in case of total recall. it should not really happen when freshly pluggin in the plugin. i'll look into it.

Even the tool-tips when you hover over any of the buttons in the preset area don't seem correct, ie 'load setting from state file', 'save current setting to state file' ... they don't seem like "consumer" terminology but more like a programmer's notes or deafult programming language type of thing.

mmm...so-so...maybe 'save to preset-file' would be more appropriate?

I know I said earlier that everything was great, but I've dove in a little deeper to nitpick now that you are close to release.

no worries. i want to hear that. ...even though i can't promise to implement these suggestions anytime soon.

The ability to select all nodes for group manipulation and a lasso\rectangle tool to select only some nodes. Being able to de-select by clicking outside the grid would be handy too.

good idea but a hell of a lot of work. maybe someday.

I find the one-click aspect hard to get used to. It is way too easy to add or delete a point accidentally. I would prefer a double click add\remove kind of behaviour.

mmm...must think about that.

The mousewheel behaviour of horizontally zooming is useful, but you have to first select a node to get it to work. Since it appears to zoom relative to that node, I assume this is the intention, but I would prefer for it to zoom in relation to the mouse pointer without having a node selected.

but this is the way it actually behaves. not? the only thing is that the GUI window must be focused but it does not have to be a node selected. try loading a preset and then zoom via mouse-wheel. does this not work?

Vertical snap would be nice.

well, i thought, the amplitude is supposed to be smoothly adjusted anyway - why would one want to quantize it?

Overall, it seems like the node\graph idea could be expanded to include a visual indication of feedback (maybe the node gets bigger or changes colour and this would be adjustable with mousewheel?)

i have an idea: how about drawing a spike (without dot) for each of the 2nd, 3rd, etc. order delay arrival in the plot with its appropriate amplitude as determined by feedback? ...i think that would clearly show what is happening.

and a second graph (or some kind of visual clue) showing (and allowing) pan positioning would give a good overall picture of what the sound is going to do.

i kinda like the suggestion by dozius with the horizontal line - maybe with a small vertical stopper as in the equalizer bandwidth nodes (but only one-sided). but i'm a bit afraid that this could look a bit messy. i'll see.

As it stands, a user has a good indication of what is happening temporally, but then has to select each node to get further details and or tweak anything which is not time related.
I just think that it could be more powerful if it was a little less "individual node-centric" and presented a more obvious picture of the whole effect.

indeed. but it really requires some thought how to represent these things visually. but i think the ideas for the feedback and pan are pretty good already. in the beginning i was even cosidering to plot a full blown impulse response 'behind' the delayline nodes. ...but this raised a couple of issues like representing pan-position, having some kind of (zoom-level dependent) plot-'sample-rate' and so on. but spikes for the feedback-echo arrivals could be a compromise that would be straightforward to implement.

[Chester Desmond]

not? it works over here. what exactly do you do and what happens? but i see some issue still: the button should not be disabled when no node is selected as it is a global one.

I was selecting a node (believing it was a per-node control) so that is likely why it didn't do anything! So it's intention is a global "reset to blank"? As per your observation, I guess it should be greyed out\disabled when a node is selected.

yes, these are both by design. as for the host-based preset management: that is generally not supported by my plugins because it's kinda incompatible with the ways, i do these things. and what you called 'preset list' is actually just a simple text-field. i aggree that would be desirable to turn it into a popup menu, but i don't know if/when i can manage to implement that.

that actually indicates that the host has stored and later recalled the state of the plugin as it normally happens in case of total recall. it should not really happen when freshly pluggin in the plugin. i'll look into it.

mmm...so-so...maybe 'save to preset-file' would be more appropriate?

Yeah , as I mentioned, the +\- is a pretty slow method of accessing presets. The load\save works well, but there again it is a little counter-intuitive for those who like to audition presets so the pop-up would be nice.

The other text displays I only mentioned because they seemed like remnants of the design stage to me. I'm only speaking from the perspective of what a user would expect to see based on common terminology..

good idea but a hell of a lot of work. maybe someday.

even a way to select more than one node (ie +shift, +ctrl) would be useful. Although I guess then the problem of which node's info is displayed comes into play. Likely only possible for adjusting gain and time with the current workflow (ie parameters which are draggable in the graph)

but this is the way it actually behaves. not? the only thing is that the GUI window must be focused but it does not have to be a node selected. try loading a preset and then zoom via mouse-wheel. does this not work?

My mistake! this does work correctly. I was clicking on the Tracktion title bar instead of the plugin's.

well, i thought, the amplitude is supposed to be smoothly adjusted anyway - why would one want to quantize it?

this is more my obsession with exactness... for example if you wanted a series of 4 echoes, each of which was .25 louder than the previous. In other words the ability to make a perfect ramp.

i have an idea: how about drawing a spike (without dot) for each of the 2nd, 3rd, etc. order delay arrival in the plot with its appropriate amplitude as determined by feedback? ...i think that would clearly show what is happening.

This is a great idea!...the different heights would give a perfect picture of their amplitude and location. Perhaps even colour coding the spikes to correspond with a color of their associated node? Once you had a few nodes, there would be a need to know which echo belonged to which node. Being able to show\hide this would be useful as well.

indeed. but it really requires some thought how to represent these things visually. but i think the ideas for the feedback and pan are pretty good already. in the beginning i was even cosidering to plot a full blown impulse response 'behind' the delayline nodes. ...but this raised a couple of issues like representing pan-position, having some kind of (zoom-level dependent) plot-'sample-rate' and so on. but spikes for the feedback-echo arrivals could be a compromise that would be straightforward to implement.

I made an image of a way I thought might work, which I will email to you. Not sure if you are displaying the GUI publicly yet, and don't know how to post image on here.

[Music Engineer]

So it's intention is a global "reset to blank"? As per your observation, I guess it should be greyed out\disabled when a node is selected.

yes, it's a global flush for all delaylines. so it should never be greyed out then.

The other text displays I only mentioned because they seemed like remnants of the design stage to me. I'm only speaking from the perspective of what a user would expect to see based on common terminology..

yeah, i see, i'll probably modify these 'state-file' terms to something more common

even a way to select more than one node (ie +shift, +ctrl) would be useful. Although I guess then the problem of which node's info is displayed comes into play. Likely only possible for adjusting gain and time with the current workflow (ie parameters which are draggable in the graph)

yes, it would be no problem to disable (grey out) widgets when multiple nodes are selected - the main problem (workload-wise, not conceptually) would be to implement the infrastructure to allow multiple selection. ...adding the lasso on top of it, would be easy again. i'll keep it in mind for later versions.

this is more my obsession with exactness... for example if you wanted a series of 4 echoes, each of which was .25 louder than the previous. In other words the ability to make a perfect ramp.

i'm actually pretty obsessed with exactness as well but the reason why i left out the vertical snap is merely that there would not be any special significance in having the amplitudes quantized on a linear grid. if amplitude-snap, then it should be logarithmically scaled...but then...mmm...dunno

This is a great idea!...the different heights would give a perfect picture of their amplitude and location. Perhaps even colour coding the spikes to correspond with a color of their associated node? Once you had a few nodes, there would be a need to know which echo belonged to which node.

that would imply to have different colors for the nodes. i think, it will be obvious from the distances (succesive spikes belonging to one group will be at equal distances). and as soon as the user grabs a node and moves it, s/he will see the group of spikes moving along.

I made an image of a way I thought might work, which I will email to you. Not sure if you are displaying the GUI publicly yet, and don't know how to post image on here.

no problem. i usually use www.imageshack.us ...looks then like this: