Delay Metadevice

what about a metadevice which has:

  • one input slider (such as the one in Hydra),
  • a “Line” unsigned integer value,
  • an output parameter which sends the value of the slider to the output (as Hydra does with its 1->9 design) after “Line” lines?

So it would be a sort of sample-and-hold metadevice? What sort of applications did you have in mind for it?

I would find this sort of thing extremely useful if it accepted signal input. You could absolute value and lowpass an audio signal, route it to the metadevice, and use it’s average amplitude to automate effects.

well what you describe is the often mentioned “AmplitudeDevice”; what I meant instead is a sort of event delayer, then not for audio signal.

It could have really interesting effects combined with other devices, breaking the time bounding between related devices.

I don’t know if it is easy to add this in Renoise, it depends on the event engine implementation: it could be super easy, but also super hard.

Cryptic…whats an input slider? Whats hydra?

Hydra is the new device introduced with Renoise 2.1.
It has one input slider which can control up to 9 outputs.

Read more here.

It would be like making phase difference between automation events. Think of an LFO set to 8LPC controlling two sliders through Hydra, one directly and one through delay device set to 4 line delay. Sliders are at exactly opposite phases at lines 2 and 6 and have exactly opposite movement cycle to each other.

Not really parectical example because you could inverse it with Hydra, but for any more advanced tweaking it would become impossible. As said, this would be for adjusting timing between values controlled by same device.

Apparently this Delay-device would be pretty much useless without Hydra, so would there be any way to just apply inertia-setting for Hydras output sliders? Would be the same without additional device.

indeed I proposed intertia for Hydra during alpha stage, but anyway this Delay Device would be good even alone, for example in combination with KeyTracking Device to delay the effect of note triggering, but it is just an example

Make it a ADSR device with delay (DADSR).
With scale settings for each part.

that would be ace, but maybe a bit too complex to understand and/or to setup as a DelayDevice. Having both would be better

sorry for noobish question but what exactly is inertia ?

Indeed. So what kind of approach should be taken towards such kind of metadevices modulation delay? I would find it most pleasable to have the parameters in one place, so why not to put inertia into KeyTracking and Velocity Device too? I can’t even think of routings that could not be accomplished without a Delay Device. The inertia setting, automatable, would be more than succifient and extremely more comfortable to use.

It is a parameter that controls other parameters reaction time to change of value. Like in filter, if you set inertia to ‘instant’ the cutoff follows tweaking instantly. Then the more inertia is applied, the more the response is delayed and smoothed out.

If the parameter that has changing value would be a ball that is moved in a liquid by rubber bands. Density of a liquid would be inertia. Just imagine how the ball would move in a water or in a tar. Tar would have stronger inertia applied.

this is true when you need inertia, but can be really annoying when you don’t need it.

think at these different Hydra scenarios:

a] you need the same inertia for each Hydra output

in this case, a single Inertia parameter would suffice, but a DelayDevice put before HidraDevice (i.e.: DelayDevice’s output is linked to HydraDevice’s input) would be the same.

b] you need different inertia values for each Hydra output:

in this case, you would need an Inertia value for each output. Can you imagine the crowd in Hydra interface? With DelayDevice, instead, you could link the Hidra outputs to be delayed to a DelayDevice

c] you need the same inertia for some of the Hydra outputs, but you need no inertia on others

same as above

d] you need no inertia for your Hydra outputs

in this case, the whole inertia stuff would just be wasting space on your screen

Sorry for being slightly off-topic, but this reminds me that Renoise need MIDI-VST support.
If we had such a thing, we would be able to do this, and all sorts of other things
Also, midi-plugins are actually quite easy to program, compared to audio/DSP

Here’s what a quick search on Google brought up: MidiFripp midi delay

Yes it would add one more value for Hydra, but could be represented with just a single numreical value instead of slider like in filter, and I would be totally happy with it even if every slider would have its own inertia-value. It would be scale-setting-wide max.

Point a is plausible, although you could use another Hydra for it.

It was because of crowding-factor I asked if someone could come up with an idea how inertia could be added, I would not knock it out before having thought it over. Imagine you want different delay for every Hydra slider. You then have 9 different delay-devices for that purpose alone in that channel. It goes without saying that this would clutter DSP view as inertia values would clutter Hydra view and would cause unnecessary routing-hassle. For convenient use I would prefer slightly more crowded but faster to use inertia-approach. Extra setting really would not confuse me because of self-explanatory essence of Hydra Device. In fact I think it would be very natural part of such an advanced modulation device.

If no inertia is needed, just ignore it. If no delay is needed, don’t use delay device. No big deal.If Hydra is too wide for someones taste, why not add show settings-button in it that would show/hide min, max, scale and inertia settings? Though I doubt I would need it.

If IT-Aliens point a] is still something someone would consider more important than my point, why not have both? Although there would propably never be a situation where someone needed same delay for all Hydra sliders, because then it would be the same to delay the actual change of input slider value in sequencer, no?

The point was to delay value changes relative to each other, where Hydra needs to be used anyway.
Another point was to delay KeyTracking device or Velocity device events, and inertia setting could be added to those devices too without any kind of fear of crowding the interface or confusing people.

if we could convert metadata to audio and vice versa, we could simply use the delay DSP to delay the metadata :P

With totally analog gear this could actually be done. And then we would have SiDeChAiNiNG!

Well…
to add to the actual discussion, line level delaying would propably be too rough, I would prefer tick precision.

And because the discussion died I’m gonna make counter-argument to myself:
Even though it is very clear that putting delay-option for sending metadata inside the actual device that sends it is far superior method of achieving wanted effect in most cases, in some cases it could, theoretically, have insufficient syncing or measuring options as well as more limited time window. It is necessary to think if line- and tick-level sync would be needed for such a device. Also if integrated method would include only one of previously mentioned units for measuring, would it be limitig precision or length of delaying too much?

The way I see it tick-based defining of delay would be sufficient in most applications, and that could be easily put into a device as an extra parameter using reasonable amount of panel space. If this is to be done, it would be best to develop a standard methon for Renoise to display such a parameter and make it habit to include it everywhere where seen necessary as standardized.

When it comes to line level sync, it is easy to calculate from TPL setting. Only really possibly limiting factor could be that if tick-delay, or inertia, would be represented as say two-digit number, with unreasonably high TPL or insanely long delays it could reach its max before the wanted delay could be achieved. With three digit number this would hardly become problem, ever.

Then there is this point that word ‘inertia’ I have used before really refers to resistance to change motion, so it is not exactly same as delay, because delay just delays events where inertia, in addition to delaying value motion also, by definition, smoothes its corners. So it is not precisely the same thing, although might produce very similar effects. Thus in some cases it could be inappropriate to handle the two approaches as opposed, because other might produce result not achievable with other. In fact the suggested Delay Device itself could have inertia-setting to smooth out rough edges and it would not, if not set too high, much affect its planned behaviour.

All in all, if another of those is to be implemented, I would really like the inertia setting more. But as said above, those two are really two different things and I would really like to see both. Even integrated into modulation devices, if anyhow possible because, as said, handling nine different MetaDelay Devices for one Hydra is really a bit too tedious. There has to be a better way to do this. As for now I have no solution, but am not really satisfied with ones that have been suggested.

I’d really love such a device, but:

Uhm… but that would be even more crowding - not in the hydra interface, but in the device chain and the mixer… 9 little boxes or 9 delay devices… hmmz.

Well, not really… that is, if the fx hide the inertia by default and expand their UI when the user choses so! You could “hide” stuff like this (“show/hide inertia” and what not) in the context menu, that would even be kinda intuitive (for me at least).

I like the ideas here, but it seems like there should be an easier way to implement this.

I had the need for delay on an LFO device when working on a recent tune, but I just thought (and it’s a bit off topic), this could kind of be overcome by having a loop point in the LFO (for the custom envelope). Once again the downside is it would add another cluttering item to an already ‘busy’ looking device!

*edit
+1 for what he said.
|
/

There is an easier way to impliment this… taktik just codes a delay metadevice :P

Then why is this thread started if actual decisions are made by the League of Gentlemen? Is this forum just as meaningful as Russian democracy?