Automated mapped value shows slow update frequency (much slower than an Auto FIlter)
Hi there! First of all, thanks for taking the time to read this post. I recently ran into this issue I don't really understand.
A friend of mine wanted to automate in Ableton some lighting effects and the solution he came up with was using OSC Send (Connection kit) mapped to an automated macro inside Ableton and that being sent to Resolume (or other VJ software). In this way he thought he would be able to just write a regular automation and then send those values scaled to the VJ software through OSC Send. That actually worked, but the issue he faced was that he was receiving a couple of values a second only, and that wouldn't work for the visual automation, as it must be really subtle with no pauses or jumps of values. He reached the expected behavior using the Filter Freq of an Auto filter but he wants to have a single patch for this. At this point he asked me for help.
My idea was to build a super simple M4L device with a couple of float knobs with a high range (0. 100000.). The thing is this changed absolutely nothing. The test scenario consists of using the same automation for the Filter Freq of the Auto Filter and for one knob of my patch. For instance, if I set the automation in Ableton for the Filter Freq from 19.9k to 18k in 16 bars at 120bpm, and I copy the same automation line for my Knob, I get between 5 and 8 values for each one of the values sent in my knob. At the same tie, if you see the knob in Ableton it looks normal, changing values fluently, so it's a matter of the internal mapping of the knob value inside Ableton, I guess. It's crucial to test this with a slow automation so you can see that tiny difference.
I tried changing the Defer Automation Output (on/off), Update Limit (0. and 1.), Steps (0 or 100000, it's the same), Clip Modulation Mode (not sure this changes anything but I tried all of them), Exponent. At some point while changing almost every value I could imagine the frequency of the refresh got much faster, even faster than the Auto filter, but it just went back to its original behavior and I have no idea what did the thing. I just ran out of ideas.
I hope you can understand the issue, it's not so easy to describe for me. In the patch I'm attaching you can also see a message box showing the OSC data received on port 1234, so you could set the OSC Send to 127.0.0.1:1234 for testing purposes.
Thanks again for taking the time to read this!
No need to set a higher range, it won't change the resolution (number of steps) of your dial. If its Type is set to float and Steps is set to 0, it will be as precise as it can be.
It's not clear to me where you measure the difference in number of received steps between AutoFilter and your M4L device.
But just to be sure, I hope you're not using [number~] for that purpose? Because it outputs the incoming value at regular interval (by default 100ms, can be as low as 20ms) but it'll always be much slower than a [snapshot~ 1]