Hi, I'm currently demoing the Remote Control VST. I plan to integrate this in my Live rig, hosted in forte from brainspawn, and Automapped using the Novation Remote SL.

I have a problem with the scaling of the CC's. They ssem to be fixed at a range og 0 to 100, everywhere in the skin files I encounter steps of 101, the automap software sees a 0 to 100 range whatever I try to change. I absolutely didn't figure out how to change this, even the automap editor doesn't succeed. Apart from the fact that I would love to re-skin the VST to suit my needs, and my needs are all but 0 to 100% display,there is another more serious problem: there is a conversion going on to map the standard 128 values of the hardware controllers to the 101 values of the Remote Control VST, and then the host rescales these up again to 128 when mappping to the VST's I want to control. The problem is that depending on several settings, some values are problematic and instable due to rounding, probably. When that happens, we go into some "parameter changed" loop, and a continuous flux of CC messages is generated, each of a slightly different value, but all rounded to the same integer. This is quite annoying and can lead to buffer overflows and of course unneccessary processing.

This could be fixed if the Remote plugin could be configured to accept standard 0 to 127 values so that no conversion is going on.

Is that possible?

Also, less important, how do we rescale the Remote Control's text display to custom values, other than 0-100%?

Thanks many. Cool software, BTW, thanks!
Dirk

Just a precision: the AutoMap server software is not involved. If I use the Blue Cat Gui (change a know position from there) acerything's fine; if I control it from any external controller that uses the 128-levelm scale, it's not.

Dirk

Hi,

Thank you for your interest in our plug-in and sorry for the late reply.

The plug-in's parameters range from 0 to 100, but these are continuous floating point values (typically used for automation), so there should not be any rounding error nor conversion here. The skins indeed use 101 positions in order to map nicely to the 0-100% range, but that's only in the user interface.

Anyway, if you use MIDI exclusively, you may indeed want to see 128 values instead, and we are thinking about releasing specific skins for this purpose.

But I guess we need to fix your rounding issue first. Can you describe with more details your setup and what you exactly notice?

Well, how should I put it: on some values sent by the hardware controller to the Remote Control VST, the RM starts putting out a continous flow of CC's that can only be stopped by sending another value. The CC's that behave this way are fixed, so it's reproductible, but if I change the range (manually, with an editor) in the preset file (global.prefs) I can change the CC numbers where this happens. It's a loop, that really looks like a rounding error. Like the plugin receives a midi value, set's the corresponding parameter,messages this to the plugin editor, who sets it's GUI element (knob,fader) which in turn sends a position value back to the plugin, if this value is equal to the current parameter value, it discards, otherwise (and here might be a rounding problem!), it'll change the parameter value, which is sent back to the plugin editor, and here we are in a loop. Not easy to explain, but it does happen and I can reproduce this.

Dirk

Thanks, it's definitely helpful. Just in case, do you remember the values which caused problems?

Using the 32 channel Remote Control; the skin: controls32.xml; preset set to use Global Settings everywhere; Global settings Midi in enabled for C1, default 1:1 mapping; midi out idem; automation out: off. I program an endless encoder on my Control Surface to send CC 1 values ranging from 0 to 127 on channel 1. No Automap, just plain midi. The midi input received by the BCRC32 is monitored by the host software, so is it's output.

Observation:

-BC RM32 receives values ranging from 0 to 127

-BC RM32 sends values ranging from 0 to 127 as well BUT the transfer curve is different, not linear, probably logarithmic

rx 0 tx 0
<snip>
rx 5 tx 7
<snip>
rx 8 tx 11
<snip>
rx67 tx 78
<snip>
rx 106 tx 111
<snip>
rx 127 tx 127

Values that generated a loop are (a lot!) 15 30 45 47 49 51 60 62 90 94 98 102 107 111 115 119 120 124

This was tested in forte by brainspawn, but I confirmed it in Reaper, which crashed upon me while doing this.

Somewhere the maths are wrong, or there's a rescaling algo missing in the code?

Dirk

Continuing on this: I found the lin/log switch (it was set to "fast" in my global.prefs). Switching to linear ouput does indeed result in a 1:1 transfer, but the exact same problem remains, with an additional issue: midi values are now output twice: two identical messages issued for each incoming message. The loops are still there on the same values.

Now if I set the inputs and output range (in global.prefs, manually, I didn't succeed to do this from the UI, the text input bow doesn't change the values) to 0 - 127, the loops are not at the same values anymore. But I notice that all values over 100 don't have their doubled output. Nor do they loop.

Loops values are now: 5 10 20 23 40 43 46 49 67 73 80 86 92 98 99

I can't think of more information to hand over. If you need me to do some perticular test, please let me know.

Dirk

Hi

Was able to reproduce in Nuendo as well.

Dirk

Thanks a lot for the details, we'll check this out.

It is expected that you cannot change the min/max values outside the [0;100] range as this is the actual range of the internal parameters. Changing them manually in the preferences won't help.

It should not be host dependent btw, so I am not surprised that you have the same behavior in Nuendo.

Hi,

It would be highly recommendable to use the standard 0-127 range as internal resolution instead of reducing this already rather rough midi resolution...... you need to do several useless conversions.

just my .002....
Dirk