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

[3dot...]

@hofmann2k

that is totally doable, i'll try and sort out a test script over the weekend that just pipes raw midi too and from a udp socket,

YES PLEASE !!!
wow this would really help me out right now..

[hoffman2k]

Sweet!

The way I understand it, with UDP we bypass Max's scheduler. Depending on how long the piping in python takes, that should be the only latency.

[ST8]

Latency will be of the order of 60-100ms im afraid, the remote scripts are not designed to be strictly timed. Theres no threading (threads are killed or knocked to 60ms refresh), and no select module, so your stuck with processing incoming data in a 100ms refresh function (or 60ms if you use the callback for the current song time).

I'm not sure what sysex is used for on a lot of synths and the likes, do you need strict timing? 60ms should be fine for updating displays and the likes though.

[hoffman2k]

Latency will be of the order of 60-100ms im afraid, the remote scripts are not designed to be strictly timed. Theres no threading (threads are killed or knocked to 60ms refresh), and no select module, so your stuck with processing incoming data in a 100ms refresh function.

I'm not sure what sysex is used for on a lot of synths and the likes, do you need strict timing? 60ms should be fine for updating displays and the likes though.

Honestly, its not for me personally. People using synths usually have CC controls for more immediate stuff. The sysex is useful for tweaking rare parameters which depending on their sound require real-time or not.

But this isn't just sysex, right? If everything is passed, people can use multiple channels of MIDI. The entire midi spec unfiltered.
I have a BCR application I built for Max runtime, to port it to M4L, I'd require 16 channels of CC's and a 100+ ms latency would be acceptable.

But now I'm wondering. Does this mean ALL remote MIDI scripts are having this same latency? For example with every automapped controller controlling a Macro.

[ST8]

Yer your right this applies to all midi, certainly not just to sysex, so you should be able to talk to any channel, its just a nibble on the first byte of midi data.

For receiving midi data (ie from controller -> Midi Script) there is a specific callback, but i think this is still limited to around 60ms.

I think note data is passed directly to ableton and not interfered with so timing is strict, however CCs do go into a midi remote scripts. So yes my understanding is that automapped parameters do respond on around a 60ms timescale.

PS: Also bear in mind that you'll loose any automap functions as i dont think you can map the same port to more than one midi remote script

[flowdesigner]

So, that will open the door for this

http://www.youtube.com/watch?v=EgGn85rolJE

[hoffman2k]

Yer your right this applies to all midi, certainly not just to sysex, so you should be able to talk to any channel, its just a nibble on the first byte of midi data.

For receiving midi data (ie from controller -> Midi Script) there is a specific callback, but i think this is still limited to around 60ms.

I think note data is passed directly to ableton and not interfered with so timing is strict, however CCs do go into a midi remote scripts. So yes my understanding is that automapped parameters do respond on around a 60ms timescale.

PS: Also bear in mind that you'll loose any automap functions as i dont think you can map the same port to more than one midi remote script

Ah. Thanks for the explanations. I'm not too worried about losing automap, I made my own. Theoretically with sample accuracy, but there's always the delay of incoming MIDI.

This all sounds very acceptable compared to piping it from a 3rd party source and everything you need could be stored with the Live Set. No more looking for this and that when loading old projects. Its all there along with the version used at that time.
This would do nicely until Ableton gets rid of the limits on track input.

As far as I am aware, there's only one mystery left in the API. The red ring and offset calls/functions. Anybody got the code for the SessionComponent? I believe that is where those functions lie.

[Hanz_Petrov]

As far as I am aware, there's only one mystery left in the API. The red ring and offset calls/functions. Anybody got the code for the SessionComponent? I believe that is where those functions lie.

My ProjectX example script shows how to manipulate the "red box". I use a Framework SessionComponent with mappings for left & right and up & down, and also override _on_selected_track_changed to automatically set the box focus to the currently selected track. The required code is fully commented at my site.

Hanz

[Hanz_Petrov]

For receiving midi data (ie from controller -> Midi Script) there is a specific callback, but i think this is still limited to around 60ms.

I think note data is passed directly to ableton and not interfered with so timing is strict, however CCs do go into a midi remote scripts. So yes my understanding is that automapped parameters do respond on around a 60ms timescale.

Hi ST8 :)

The newer scripts seem to use a callback to refresh the hardware state at an interval of 5 ticks:

Code: Select all

    def refresh_state(self):
        ControlSurface.refresh_state(self)
        self.schedule_message(5, self._update_hardware)

and from ControlSurface:

Code: Select all

    def schedule_message(self, delay_in_ticks, callback, parameter = None):
        """ Schedule a callback to be called after a specified time """
        assert (delay_in_ticks > 0)
        assert (callback != None)
        assert (dir(callback).count('im_func') is 1)
        self._scheduled_messages.append({'Message': callback,
         'Delay': delay_in_ticks,
         'Parameter': parameter})

If a MIDI tick is 10 milliseconds, then the default refresh interval is 50ms, although it might be possible to feed the function with a lower delay_in_ticks.

Hanz

[ST8]

Unfortunately those are not real midi ticks, if you look where the scheduled messages are actually processed its in update_display, which is only once every 100ms, therefore 5 ticks in remote script land = 500ms!

http://hanzoffsystems.tech.officelive.c ... te_display

The red ring is available from python. We could maybe double up the sysex handler with a red ring handler too? Maybe an illegal midi message could move the box around or something?

[amounra93]

@hoffman2k

Ahhhhh...see, I've been trying to get MIDI through directly from a [live.object], without success. I spent a long time last night messing with different portions of the python scripts with no luck. A script that passes MIDI to UDP would work well for me, also, now that I think about it. I, also, am mainly seeking compartmentability.

@ST8

You rock

[ST8]

Ok heres an initial draft, not tested it fully. This listens on port 5000 for raw midi data. udpsend send 12 134 151 etc in pure data (i think its the same in maxmsp?). It'll also return any ccs from your controller on port 5001 if set to receive midi too.

http://monome.q3f.org/changeset/latest/ ... format=zip

Drop the sysex folder into your MIDI Remote Scripts folder
on mac: /Live x.x.x/Live.app/Contents/App-Resources/MIDI Remote Scripts
on win: c:\progs\ableton\live x.x.x\Resources\MIDI Remote Scripts

You'll also probably need python 2.5.1 installed. If you're on osx 10.5.8 its already installed, if you're on 10.6 you need to install.

If you send a message of length 5 bytes starting with a 0, it'll update the selected region in live.
ie udpsend 0 0 0 3 4 = x offset, y offset, width, height

[hoffman2k]

Ok heres an initial draft, not tested it fully. This listens on port 5000 for raw midi data. udpsend send 12 134 151 etc in pure data (i think its the same in maxmsp?). It'll also return any ccs from your controller on port 5001 if set to receive midi too.

http://monome.q3f.org/changeset/latest/ ... format=zip

Drop the sysex folder into your MIDI Remote Scripts folder
on mac: /Live x.x.x/Live.app/Contents/App-Resources/MIDI Remote Scripts
on win: c:\progs\ableton\live x.x.x\Resources\MIDI Remote Scripts

You'll also probably need python 2.5.1 installed. If you're on osx 10.5.8 its already installed, if you're on 10.6 you need to install.

If you send a message of length 5 bytes starting with a 0, it'll update the selected region in live.
ie udpsend 0 0 0 3 4 = x offset, y offset, width, height

Sweet

You sure this is the right file though? Looks like the entire LiveControl package.

[ST8]

Oops, fixed

[hoffman2k]

It definitely responds to incoming CC's. But I get the following error instead of data:

udpreceive: OSC packet size (3) not a multiple of 4 bytes: dropping

No response to notes and program changes, but I may not be testing it properly. I'm just sending from some max helpfiles like ctlout and pgmout. Quick tests..