EchoLab - (closed) beta test - release candidate 1

[Music Engineer]

Hi test-team,

so this thread is now the place where we can talk about bugs feature-requests, comments and whatever else of the upcoming DelayDesigner. from former private conversations via email, i have collected some issues and will list the ones that have not (yet) be addressed:

bugs and 'wrong' behaviour:
-right-click -> enter value (on sliders) does not yet work
-in some hosts, keyboard input does not work - i.e. is taken ("stolen"?) by the host -> i'm not yet sure if that can be solved from the plugins side. probably only with hacky workarounds, which i want to avoid
-take away keyboard focus when clicking on an empty area
-the feedback-loop is unbounded which may lead to instability (in the sense of infinite signal buildup) for some settings
-snap-to-grid setting not recalled when closing/re-opening the GUI (in some hosts - FL)
-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?)

feature-requests:
-pan/feedback adjustment in the graphical editor with shift- (or ctrl-) dragging
-macro-parameter to sweep all EQ frequency-settings at once (->dunno - will be complicated and probably a potential CPU hog)
-insert first EQ handle when user selects EQ mode via dropdown box

soo, this is the list i collected, please tell me when i missed something. ..or when new issues arise. or quite generally for any comments. i'll try to address as much of it as possible, but some things might turn out to be impractical.

[pedrorf]

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

I was going to report this one... Same thing happens in reaper and energyxt.

[Music Engineer]

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

I was going to report this one... Same thing happens in reaper and energyxt.

i have already adressed this one - next version will then (hopefully) recall this setting. (i think) it was caused by the fact that only the GUI knew about this setting and not the plugin-core itself. so when closing the GUI and re-opening it, the setting was lost.

[geroyannis]

Robin, about the keyboard input thing: I checked and some of my plugins that accept keyboard input are gcomp (from the gvst collection), izotope ozone, and voxengo voxformer. Maybe you could ask their developers.

Also ReaComp from the ReaPlugs bundle accepts keyboard input but it doesn't take away the keyboard focus when you click on an empty area, so you have to select another parameter.

[pedrorf]

Will you be adding midi-learn to other parameters? I was playing with drum loops and found some interesting effects by dragging the EQs around in real time. It would be nice to be able to use midi for this, especially since there are no internal modulators.

[Music Engineer]

Will you be adding midi-learn to other parameters? I was playing with drum loops and found some interesting effects by dragging the EQs around in real time. It would be nice to be able to use midi for this, especially since there are no internal modulators.

yes that would be nice indeed. alas, with the way i currently handle parameters, MIDI-learn is not possible for dynamically created parameters. only for static parameters (which are 'just there'). all parameters that are not always there (which includes all per-delayline parameters, so basically everything except dry/wet) can't do it. at the moment, i cant really do much about that but i'll think about it to find a solution... btw.: does midi learn for the dry/wet control work for you? ahh, wait - i just see that it doesn't. ....fixed. next version will have it at least for dry/wet.

[Music Engineer]

Robin, about the keyboard input thing: I checked and some of my plugins that accept keyboard input are ...

O.K. thanks. i found some lengthy discussion over there at the juce forums on that topic (my plugins are juce based):

http://rawmaterialsoftware.com/juceforu ... sc&start=0

mmmmhhh...according to jules' final post, the most recent revision of juce will probably solve it...but....this would then be some unofficial version from the svn-repository at sourceforge...not sure if i'm going to switch over. might come with other side effects. but i will look into it.

[thelizard]

A Master volume control would be a huge help, especially as the taps add up.

An idea for automation: You could set-up automation parameters for, say, the first ten taps that are user created, and have the rest act the way they currently do. I don't know if that could be done, but it's just an idea.

[Music Engineer]

A Master volume control would be a huge help, especially as the taps add up.

O.K. no big deal.

An idea for automation: You could set-up automation parameters for, say, the first ten taps that are user created, and have the rest act the way they currently do. I don't know if that could be done, but it's just an idea.

unfortunately, that wouldn't be really practical. i think the only way to do it in a meaningful way would involve to completely re-organize my whole parameter-handling infrastructure. i will consider that, but it won't come overnight.

[pedrorf]

An idea for automation: You could set-up automation parameters for, say, the first ten taps that are user created, and have the rest act the way they currently do. I don't know if that could be done, but it's just an idea.

unfortunately, that wouldn't be really practical. i think the only way to do it in a meaningful way would involve to completely re-organize my whole parameter-handling infrastructure. i will consider that, but it won't come overnight.

What about adding a set of six or so fixed "realtime controllers" with automation, and then the ability of mapping any regular control into one of these? No idea if this is doable or not, just thinking out loud.

As it is now, the plugin is a multi line delay, with a trick or two. Being able to modulate the delay lines or the filters, either internally or by automation, would bring a whole new dimension to it.

[Music Engineer]

What about adding a set of six or so fixed "realtime controllers" with automation, and then the ability of mapping any regular control into one of these? No idea if this is doable or not, just thinking out loud.

something like that has been poking around my head for a while. would enable the user to create his own 'macro' parameters. in general, i like the idea but this will take time. ...and i think it wouldn't save me from re-designing the parameter-handling architechture - it would be something additional then.

[Dozius]

Maybe the addition of a few more tricks in the feedback path would set it apart and make it more attractive to buyers as well. I know you've done pitch shifting stuff in the past, perhaps some of that in the feedback chain would be an added perk. There aren't very many delays with good pitch shifting feedback capabilities and certainly none with virtually unlimited delay lines.

[Music Engineer]

Maybe the addition of a few more tricks in the feedback path would set it apart and make it more attractive to buyers as well. I know you've done pitch shifting stuff in the past, perhaps some of that in the feedback chain would be an added perk. There aren't very many delays with good pitch shifting feedback capabilities and certainly none with virtually unlimited delay lines.

interesting idea. perhaps a comb filter would be interesting as well. i've been a bit quiet about it for a while, but i think it is approaching a state mature enough for a release candidate for v1.0. i hope to send out a new version next week which will then also incorporate the demo-version / keyfile-detection mechanism and i will then send out the keyfiles to all you beta testers. stay tuned... additional stuff in the feedback path is certainly an intersting path for enhancement but i would then postpone that for future versions.

[Musical Gym]

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

[S-N-S]

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