Proposition: solution for sysex...SOLVED!!!

[amounra93]

Not sure what you mean....I'm getting 0's through OSC from the script to Live....as well as log-calls when sending them from Live to OSC. I just can't get the script to send MIDI out. I'm trying to import the _Framework module 'ControlSurface', but that so far hasn't work. I was thinking that in addition to getting the MIDI out to work, it might also add some M4L API object support.

[ST8]

Can you try out the updated script, is it different to your liveosc implementation?

You now need to send each byte individually and the script should hopefully pass it on

[amounra93]

OSC out of script is working with controllers and sysex. This is a step beyond what I got (I'm still not getting CC's with my script).

OSC into script still is not resulting in MIDI output from Live. All the newer scripts are using _Framework for _send_midi(), I'm wondering if this has something to do with it?

I'll send you a copy of my scripts as soon as I get home, at work right now so can't do much other than test stuff.

Thanks again

[ST8]

Ok ive updated again, you need to send an osc message of:
/ableton/sysex int byte int byte int byte

for midi cc and the likes, you'll have to find someway to package the three bytes from midiformat into a single message as i cant guarantee the message order in the Sysex script. My local tests seem to show that it works both ways ok now.

you should also be able to send sysex messages of any length.

Although udpsend accepts multi byte messages now it always returns each byte in udpreceive so you can pipe it directly into midiparse.

Let me know if this works better

[amounra93]

Working good here now I'll figure out the rest, if need be. You rock!!!!

[hoffman2k]

Ok ive updated again, you need to send an osc message of:
/ableton/sysex int byte int byte int byte

for midi cc and the likes, you'll have to find someway to package the three bytes from midiformat into a single message as i cant guarantee the message order in the Sysex script. My local tests seem to show that it works both ways ok now.

you should also be able to send sysex messages of any length.

Although udpsend accepts multi byte messages now it always returns each byte in udpreceive so you can pipe it directly into midiparse.

Let me know if this works better

Wow. Awesome stuff! I love it when a theory checks out

I got it working with CC's, but it doesn't seem to accept much else.

Here's how I test:

- Live's MIDI Prefs send to virtual port 1

- I'm listening to UDP port 5001

- I send CC's over virtual MIDI Port 1, I get the data in the OSC format with the bytes as expected.

- Sending notes or pitchbend over virtual MIDI Port 1 doesn't get me any OSC data

Maybe I'm doing something wrong, but it definitely partially works. And its just the part I can use

Thanks for this awesome hacks guys!

[ST8]

Ahh yes its only forwarding ccs at the moment. i'll add the forwarding for notes too. Not sure if you can forward pitch bend or not :/

[hoffman2k]

Ahh yes its only forwarding ccs at the moment. i'll add the forwarding for notes too. Not sure if you can forward pitch bend or not :/

Thanks! I don't need the PB personally, was just noting some results from testing. I'm always a big fan of your work

Speaking of which, in earlier conversations you guys narrowed down what the refresh rate is for all this script stuff. Is that the actual speed limit of python scripts? Or could it be cranked up by Ableton in the future? I'm just trying to imagine what API features could be possible down the line.

[ST8]

It could be cranked up by ableton, at the moment all udp is onlu processed in the update_display function which is every 100ms. Just need a faster callback, or be allowed to fork the udp processing into another thread

[hoffman2k]

It could be cranked up by ableton, at the moment all udp is onlu processed in the update_display function which is every 100ms. Just need a faster callback, or be allowed to fork the udp processing into another thread

I wonder how live.remote~ works. Would it bypass the entire python bit to work at audio rate?

[amounra93]

@ST8 I'm wondering how the "set_session_highlight" function is supposed to work in your script. I'm not getting anything at all with it. I havent' dug into the other scripts yet, I thought you might explain? Thanks

[ST8]

send /ableton/selection int xoffset int yoffset int width int height

[3dot...]

send /ableton/selection int xoffset int yoffset int width int height

now.. how do we get inside racks/rack mixer params?...

[Hanz_Petrov]

Hey guys,

I've been fooling around a bit with the sysex thing, and I've found two ways to get sysex data to a control surface using only Max for Live and a Framework-based python script. Unfortunately, neither way seems quite satisfactory (and only one works properly).

1. Define the sysex as a tuple in the script and set up a method which fires it to the controller, using self._send_midi(SYSEX_MESSAGE).

This is the python code:

Code: Select all

SYSEX_INQUIRY = (240, 126, 0, 6, 1, 247)
def send_sysex(self):
    self._send_midi(SYSEX_INQUIRY)

From Max, a "call send_sysex" message sent to a live.object with a ControlSurface path will trigger the message.
When I "uzi" this on a Standard MMC Device Enquiry string (240 126 0 6 1 247), the messages fire at under 10ms. From the MIDI-OX log:

Code: Select all

   4987907  1   9    240 Buffer:     6 Bytes    System Exclusive  SYSX: 240 126 0 6 1 247
   4987913  1   9    240 Buffer:     6 Bytes    System Exclusive  SYSX: 240 126 0 6 1 247
   4987922  1   9    240 Buffer:     6 Bytes    System Exclusive  SYSX: 240 126 0 6 1 247
   4987929  1   9    240 Buffer:     6 Bytes    System Exclusive  SYSX: 240 126 0 6 1 247
   4987934  1   9    240 Buffer:     6 Bytes    System Exclusive  SYSX: 240 126 0 6 1 247

The downside is that the sysex messages reside in the python script - only the instruction to fire the message comes from Max.

2. Send the sysex via a Max for Live function call directly to the script. This only seems to work partially - perhaps because of my limited Max skills. For some reason, I don't seem to be able to call a controller script function which takes more than 3 parameters. I can set up call a send_midi(self, status_byts, data_byte1, data_byte2): function in the script and pass it, say, "240 126 0" from Max, and a very short sysex message will come through(!), but if I add any more argumnents to the function, it gives me an error. So: does anyone know how to define a python tuple in Max, to be used as an argument for a script function?

Hanz

[amounra93]

Hanz, you rock. I've been playing with that idea from the get-go, but didn't have the Python skills to get even that far.

You might try sending the sysex bytes as a symbol, using the [tosymbol] object. This should send the entire message as a single symbol, and you can break the tuple apart in Python.