Strange feedback while write automation<->VSTi

Renoise Tool Development
1

If you write automation using LUA api, strange feedback write-backs while occur, in the following or similar way:

writing automation-point -> linear-mode-graph is interpolated immediately -> current automation-point is updated -> updated value is sent to VSTi -> VSTi sends value back to automation device -> automation device slider is updated etc…

or

writing automation-point in point mode -> some feedback or refreshing of the ORIGINAL slider value is happening -> in between automation, the original / start value of the slider will occuroccasionally

Maybe the causal chain is not 100%, but I hope you get the idea / the problem.

Currently trying to make a parameter write directly from VSTi gui:

https://forum.renoise.com/t/topic/43378

Please see shortcut “Global:Tools:Setup automation device and record hires”

Line 1476++ in source code.

Short manual:

  • Bind shortcut"Global:Tools:Setup automation device and record hires"

  • Add VSTi

  • Hit shortcut

  • Activate edit mode / recording

  • Move any slider in the VSTi gui

  • Switch to automation panel for detail view

Here I write automation values in high resolution to the automation graph, with a little backwards offset from play position. But it still behaves really strange. The higher the LPB, the stranger the effect.

So I would like to suggest to you one of the following:

- a lua api function that temporarily disables the sending to VSTi:

https://forum.renoise.com/t/the-api-wishlist-thread/29285

- If a automation value was just sent to a VSTi and immediately will be returned back from VSTi (due handle change),Renoise is so intelligent, that the returning value at IDENTICAL(?) timestamp/same controller number won’t be interpreted. So no feedback can occur.

- PATCH of sng:instruments[].plugin_properties.plugin_device.parameters in a way, that feed backed / endless looped sending of values is not possible.

Or maybe there is a better solution. Do you have any tipps for workaround?

2

I’ve never experienced this myself (some of my tools also do high-res recording).

Wonder if you’re doing it the right way?

Take a look at these two classes to see a different implementation:

Generic automation class:

https://github.com/renoise/xrnx/blob/master/Tools/com.renoise.xLib.xrnx/source/xLib/classes/xAutomation.lua

That class gets the high-resolution time (song-position alike) from here:

https://github.com/renoise/xrnx/blob/master/Tools/com.renoise.xLib.xrnx/source/xLib/classes/xPlayPos.lua

I’m basically arriving at the fractional time by extrapolating the timefrom os clock + song position in beats.

3

Hey, thanks for the infos! Really cool, will check differences and use your lib then.

I guess in my case its kind of special case, since usage with VSTi or VSTi guis? Did you use your scripts in combination with VSTi gui controls movements?

The script keeps observing the parameters of the vsti and after setting up the automation device, it then writes automation using “add_point_at()”. Then the observer function will be triggered again, maybe due line automation mode, and sometimes with strange values. The stranger the higher the LPB.

Also I don’t know how I candifferentiate a trigger by handle movement in the GUI and movement of the automaton device slider…

4

So thoughts about xPlayPos

Danoise, hm, but xplaypos is updated on idle() and idle has a very low frequency, so I guess, xPlayPos’ fractional resolution cannot be that high? I don’t really see that this is the right way, IMO the automation should be written immediately when the parameter change was observed…?

Tried it on idle() now, too, but then the resolution still is quite low.

xAutomation:

Is there a example of usage here? :slight_smile:

5

IMO the automation should be written immediately

Yes, of course it does. One implementation is in xRules (a simple example would be the TouchOSC one)

But perhaps something is really different when automating VST parameters, I don’t know.

Will try testing with my own toolage to begin with, to see if it works here…

6

Yes, of course it does. One implementation is in xRules (a simple example would be the TouchOSC one)

Well, I expressed not precisely enough. It writes automation immediately, but seems to be often the identical position, since the fractional xPlayPos is only updated on idle(). In the tuned shortcuts it also now calculates the position in xlib way, but also in the moment the parameter change is triggered. So you get a much higher resolution of automation. At least my tests here look like this.

So I would like to suggest to you to recalculate the xPlayPos in xAutomation in highres_mode parameter write or similar:

this:https://github.com/renoise/xrnx/blob/master/Tools/com.renoise.xLib.xrnx/source/xLib/classes/xAutomation.lua#L92

also here:https://github.com/renoise/xrnx/blob/master/Tools/com.renoise.xLib.xrnx/source/xLib/classes/xAutomation.lua#L143

7

Here it is, running in xRules (recording MIDI @64BPM. 1 line per beat)

highres-rec.gif?raw=1

I was controlling an instance of Bazille, didn’t detect any feedback.
I wonder what plugin you’re trying to control?

Here’s the ruleset (xRules > Add > Paste from clipboard)

-----------------------------------------------------------
-- Ruleset definition for xRules
-----------------------------------------------------------
return {
manage_voices = false,
description = "",
{
  name = "Tilt → XY Pad",
  actions = {
      {
          call_function = "rprint(values)\nlocal dev = rns.selected_device\nif dev and (dev.name == \"*Instr. Automation\") then\n --print(\"got here 1\")\n local param_x = dev.parameters[1]\n local track_idx = rns.selected_track_index\n local x = xLib.scale_value(values[2],0,127,0,1)\n x = xLib.clamp_value(x,0,1)\n if rns.transport.edit_mode then\n record_automation(track_idx,param_x,x)\n print(\"got here 2\",x)\n else\n if not has_automation(track_idx,param_x) then\n param_x.value = x\n end\n end\nend\n",
      },
  },
  match_any = true,
  midi_enabled = true,
}
}

Note to self: I should use longstring to make these rulesets more readable

8

Regarding resolution: Hm, but the resolution of xPlayPos fractional is as higher the slower the playback speed. Have a look at LPB 4 or LPB 8. And then compare with the realtime updated xPlayPos. Tried with different plugins.

Regarding feedback:

If you set the song to BPM 140 and LPB 8 and TPL 16, and now repeat your test, don’t you see some strange occurrences?

EDIT:

Hm, cannot reproduce with Zebra2, but with FM8.

Or Albino3, LPB8, BPM 110, TPL 16 (with tuned shortcuts, uses now xlib way for automation write/pre-clear and fractional playpos):

Attachment 6969 not found.

Those strange saw-like spikes will disappear almost, if the TPL is set to 1.

How do I execute a xrule again?

9

Oh, also you recorded MIDI input, but not vst-parameter-changes using the mouse… ?

10

I’m not experiencing those spikes, no matter what BPM/LPB I’m running. It “just works”.
To be sure that we’re not missing something fundamental, could you run the xRule on your own system?

How do I execute a xrule again?

This particular rule requires you to add an instr.automation device. Once you’re in edit mode and focus is on that device, it will record.

Other than that, just a question of pasting the snippet above (and if not already done, set automation recording to highres in xRule prefs…)

Oh, also you recorded MIDI input, but not vst-parameter-changes using the mouse… ?

Yes, MIDI input. In theory it shouldn’t make a difference - but let’s try not to assume anything here.

11

This particular rule requires you to add an instr.automation device. Once you’re in edit mode and focus is on that device, it will record.

Other than that, just a question of pasting the snippet above (and if not already done, set automation recording to highres in xRule prefs…)

Meh, lol, I seem to be miss the point here. Added VSTi, added “*Instr. Automation”, wired first parameter to control. Now started xrules, pasted rule, edit mode and play enabled, mouse focused on automation device, moved first parameter slider. Nothing happens. If I moved the knob in the vsti gui, also nothing happens.

In xrules the rule is checked. BTW. how can I remove a rule?

12

Hm, maybe the behavior differs on Mac OSX vs. Windows?

13

Oh, you need to enable the port too. xRules is always processing raw MIDImessages.

If I moved the knob in the vsti gui, also nothing happens.

Yes, it’s not listening for parameter changes, only the incoming MIDI. This is not even possible with xRules, it only deals with incoming OSC/MIDI messages ATM.

Just wanted to ensure that basic recording is working on your system too before we move on :slight_smile:

I will try and do a test where I record parameter changes. But can you give an example of a (free) plugin that exhibit the problem, other than FM8, Albino? I tried with Bazille and a few others, but they all seemed to work.

Would be great if we could test with roughly the same setup.

14

I can reproduce those spikes with tunefish4 (https://www.tunefish-synth.com/?action=download), more or less, at LPB 8+, TPL 16…

I think I would like to have a way to detect, if an vst parameter trigger did came from the renoise automation or the VST gui…

If you think about this, I would say this makes a lot of sense, that Renoise should prevent in any case that sent automation to plugin never will be bounced back as parameter trigger again / should be filtered out by Renoise thru an intelligent filter.

Or some property of device sliders like “connection-mode: two-way, incoming only, outgoing only”