Hey, all! I have been using the GitHub AbletonOSC script and I’m struggling with something.
The address for receiving data is at an address, but it is separated by the integer (represents the track #). So, for example, I have a slider that is read only and set to receive the volume meter output. The address is /live/track/get/output_meter_level and the integer is 1 (track 1), which I added to the extra OSC arg row, followed by the float data. OSCPilot seems to interpret this first integer as the float data though (it sits at 1.0) and I have no way of assigning that slider to receive the float data from that specific integer because I cannot add it to the address.
Hi, AbletonOSC looks really promising. Does it work for you, apart from the problem you mentioned?
I now tried my best to get it running, but i m a bit dumb, and don’t even know how to make the Windows Defender Firewall of my receiving (Ableton) PC not block the incoming messages from OSCPilot (which is on another PC in my LAN network).
So my only success so far is: deactivating the Firewall completely (not good!), and then pressing a OSC Pilot button with “/live/test” in the OSC adress, shows the “received OSC OK” message in Ableton.
Other than that, i m completely lost. So in case there is a more idiot-proof documentation or youtube video on how to use AbletonOSC (=how to type in the AbletonOSC commands into OSCPilot correctly) please tell me.
Oh, and sorry that i can’t help you with your problem! I m not even sure if OSC Pilot is “built” for being able to receive certain OSC values, → i would love to know if osc pilot , in theory , could show specific db values of a volume meter, or a Clip name/color !? My dream setup would be having a Launchpad-Style Clip interface where you see the clip names, colors, and the clip playback progress in each clip!! and below the volume meters of the Tracks
I have seen an old post from you, where you ask for XY Pad having also a Z value → it has been added now thankfully With the OSC pilot version 1.9.10 shared in this post: [FIXED] Please: XY Pad tiny addition - #6 by malcolm
In OSCPilot-
Send will be 11000
Listen will be 11001
Make a text box and put the same /live/test in the address, you should receive the Ok in there
The GitHub drop down readme has some other notes for getters, senders and the start_listen functions.
Again, AbletonOSC structures it by track # as the integer argument prior to the float data. So the get ‘address’ for each track is the same, let’s say “output_meter_left” for example, but integer address 1 (which is really track 2 because AbletonOSC starts at 0) is where it sends the float data. Pilot, I believe, currently can couple multiple OSC args(integers), but maybe something like an “exclusive integer” toggle on the ‘extra OSC args’ field may be the win?
I’m Mac, not sure about PC. Get Protokol or another OSC analyzer it helps. Chat GPT is great for troubleshooting BTW I highly recommend it.
Thanks for the feedback. In general the type of the argument isn’t used to determine what it’s used for, just it’s position. A sender can send us floats/doubles/ints and we’ll accept them as the values for the Widgets. We’d need a way to say that the first argument should be ignored. I’m not sure that’s the best way forward though, rather than the sender having it’s argument adjustable instead…
Yes - perhaps a “follow mode” switch for the extraOSCargs field would do it?
So let’s say the application sends out “/live/clip/get/name 5 5 BoomBap”
In Pilot, a text box widget would need “/live/clip/get/name” in the address and “5 5” in the extraOSCargs. Currently, the text would display “5” because it follows the 1st arg. But with a follow button engaged, the widget would respond to the 3rd arg because there are two args in the extraOSCargs field.
I imagine on multi’s it could be an “add/arg” switch where instead of ascending /add/1, /add/2, /add/3 etc… it does /add 1, /add 2, /add 3, etc…
I think i m starting to understand what you’re asking malcolm for, i guess your suggestion makes sense, otherwise no AbletonOSC communication seems fully possible?
this is working fine
I m trying out the commands from the manual, but almost none is working.
“/live/song/stop_all_clips” this works, when i put it in the adress of a OSC Pilot button, great.
But “/live/song/undo”, “/live/song/tap_tempo” “/live/song/start_playing”, and many other, these dont work at all, when put into a buttons OSC adress. weird.
And how would you make a Volume Meter with OSC pilot?
Making a Slider, and put as OSC Adress: “/live/track/get/output_meter_level 0” for showing the first Tracks Volume?
And making a button with OSC Adress: /live/track/start_listen/output_meter_level 0
to start showing the volume, pressing on the button?
Sorry for being dumb
I haven’t tested those specific commands. I know the AbletonOSC folks say that it’s still in somewhat of a test phase, so there may be some incompatibilities.
For meters, best to do the start_listen command, then close OSCPilot and launch Protokol. You’ll see event data transmitting at live/track/get/output_meter_data (track#) (float).
For now, I’ve been using OSCulator to translate these track variable args into different addresses that Pilot can read. I just do meters/1, meters/2, etc…
OH! Does this problem also have something to do with your initial post here or is it an additional problem?
I encountered a translation problem, too, when trying to use a m4l tool called Livegrabber, in order to send OSC messages to OSC/Pilot and vice versa. And i found the following description of the problem in the Livegrabber manual. I guess this is exactly the same problem you encounter with ABletonOSC → OSC PILOT, and OSCPILOT → AbletonOSC ? By the way, i m sadly not on MAC, so i can’t even use OSCULATOR
"OSC arguments
A recurring source of confusion when receiving OSC with LiveGrabber is that some OSC libraries or apps format their OSC arguments as strings instead of floats. This will cause LiveGrabber to ignore their messages.
A quick way to check if your message arguments are formatted correctly is to send them to OSCulator 3.
In this example we’re sending messages from Max (patch below) both to LiveGrabber and to OSCulator, first with float arguments and then with string arguments.
In GrabberReceiver, there is no visual distinction:
As you can see, the messages formatted as strings are displayed as such.
These string-formatted arguments will not work with LiveGrabber. They will be displayed as being received in GrabberReceiver, but any receiving devices such as ParamGrabber will not show a blinking input indicator and nothing in Live will be controlled." Source: Free Tools Support | Showsync
