I just found this gem, that I’d like to share here.
An auto-labeling control surface for Ableton Live and TouchOSC.
Maybe some ideas from it can be used in the future development of OSCelot.
1 Like
This is possible already, unless I’m misunderstanding. You can have your OpenStage template for example with 16 faders mapped to an Oscelot. When you map or remap a control, it send labels and other info, which you can use to populate your OSC controller.
When you move the fader it only sends the current value by default. You can change this to send full feedback in the options menu under resend OSC feedback.
See here: https://github.com/The-Modular-Mind/oscelot/blob/master/docs/Oscelot.md#osc-feedback
The doc was written for v1, in v2 the second message has one more param, the default value for the current mapped param. This is if you want a button to reset to default or some pitch bend like control. eg. here the 0.79xxx value is the default value for the mixmaster vol fader.
address: ‘/fader/info’,
args: [ 1, ‘MixMaster’, 0.7937005162239075, ‘-01- level’, ‘-1.2784’, ’ dB’ ]
1 Like
What impressed me with zsKnobbler3, was the ease of use.
Put zsKnobbler3 on a track, and set the IP/port of the tablet. (default is port 2346 send AND receive).
for each control i want to map:
- wiggle control with mouse in ableton.
- slide up on unmapped slider on tablet to assign it to the control (or red dot + slider to clear mapping of allready mapped slider)
Offcause I have no idea if the VCV Rack API lets you monitor which controllers are “wiggled” like that, from your module.
That’s the same way it works, for e.g.
- if you have faders mapped to Oscelot. You click on the param in Oscelot and then wiggle the vcv control
- if you don’t have it mapped already, then you click Oscelot to start mapping, then wiggle both vcv control and OSC control
Hi, the output of my OSCelot is jumpy and jaggedy for some reason. Wasn’t like that before, something must’ve changed. cvOSCcv works fine and smooth on the same port, but I have about 200 controls to map and I don’t want to waste CPU on unnecessary modules. OSCelot seems to be the only workable solution for me.
Could you please point me in the direction of possible source of the problem and maybe a possible solution as well?
I haven’t updated the library version recently, unless you grabbed the dev build? Do you have a patch or something I can reproduce the issue with.
Jumpy OSCelot.vcv (907 Bytes) The patch is just OSCelot mapped to a knob. If it works fine on your end then it’s my machine to blame, something must be interfering.
Here’s a video of how it looks like on my end https://youtu.be/mtfm6h-iEZM
Also, a question. is OSCelot supposed to open a port for discovery? I’m asking because I can only see available connection from my TouchOSC on iPad when I launch Protokol app and enable OSC port. Without Protokol running I can’t connect at all even when Receive toggle is ON on OSCelot.
From your video, it looks like the send port is not on. The light should be green. Possibly because it’s in use by some other app.
Click on the button to turn it on, if it still stays orange the send port is in use.
Ok I figured out what was causing this jumpy behavior.
The knob on my TouchOSC uses an overlaid transparent fader that controls the knob locally, and provides an ability to turn the knob by up/down motion instead of circular. And both knob and a fader had OSC messages set up. Fader was set up in compliance with OSCelot format, but the knob kept sending it’s own data at the same time. When I deleted that other knob message the control started working smooth again. I recon the reason cvOSCcv kept working smooth regardless of the mesaages is that it has a better implementation of OSC messages unpacking.
So in order to reproduce that bug just set up a knob and a fader in TouchOSC, connect the fader to a knob by local message, have them both send OSC messages and format one to /fader id x, then map it any control in VCV.
1 Like