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

[ST8]

Its not an osc packet, its a raw udp packet (= raw midi message in this case), no headers or anything. I could make it osc but i thought a raw socket would be easier to start

[hoffman2k]

Its not an osc packet, its a raw udp packet (= raw midi message in this case), no headers or anything. I could make it osc but i thought a raw socket would be easier to start

Its what the Max window says.
I expect values to come out of it, but I just get these errors.
Have you managed to get it to work?

[amounra93]

EDIT::

@hoff type an arg after receive---this receives full packets and u won't get errors (e.g. [udpreceive 5001 full] )

BUT

@ST8 I'm not logging the script as getting any input from m4l so [udpsend] must be mucking it up. I am logging output back to m4l, but, again, the raw data is merged into a denominator (the length of the tuple) and a single integer . Prolly need to split up the tuple and send it out one byte at a tIMOe with proper formatting, then we can use [midiparse] to get it where it needs to be. Same with input, I'd imagine. One more short flight and I'll see what I can find out. Thanks for the work; this will function, just needs tweaking.

[hoffman2k]

EDIT::

@hoff type an arg after receive---this receives full packets and u won't get errors (e.g. [udpreceive 5001 full] )

Cheers. Now I'm getting a readout, but not sure how to handle the data yet.
When I send CC0 to the script i get a readout like:

print: FullPacket 3 411776464
print: FullPacket 3 411776464
print: FullPacket 3 411887728
print: FullPacket 3 411887728
print: FullPacket 3 411776464
print: FullPacket 3 411776464

The only thing that keeps changing is the last number.

[amounra93]

I'm home now and looking into it. There isn't much we can do with it the way it stands. I've been looking through the LiveOSC python scripts, and there are a lot of methods which need to be instantiated before max will be able to use the data that is being sent. I could fix something up quickly with a js, but it doesn't handle BLOBs without some extensions.

I think ST8 knows all this...this script is very preliminary I'm guessing. Its good for me b/c its leading me into learning the python stuff that I've been putting off. Its excellent that we are getting some feedback into max with this; that shows its moving in the right direction.

@ST8...I still can't get any logging to show up from events sent to the script from M4L. I got something at some point, but mucked about with the Sysex script a bit and now I can't seem to get anything useful. I'm assuming that all I need to do is change _LOG=1 and that should turn logging on? I'm on OSX, I changed the path appropriately and it creates the file, but I don't see anything I can used there. Presumably, you can have two methods named identically, each within different modules, and have that method only refer to the module you are calling from? Sorry for the stupid questions, I'm tryng to read up on python as I write....

After looking a little more closely at the python scripts provided with LiveOSC, I see how much work is involved (for me) to try to make this work. Seems like most of the modules will stand as they are, they just need to be integrated to make this work. Again, thanks for all the work you've already done, it was my mainstay solution before M4L rolled around

[ST8]

At the moment it sends raw data, so thats basically a string.

To recieve data, if you look at the raw packet you'll get something like £!?. Each character is a byte, you need to convert back to the relevant number using ord or the equivalent.

To send data you need to concatenate the three bytes together into a string. Using Pd at least you send use a send 12 143 145 message to send three bytes out. Does that work in max/msp too?

For example a cc message on channel 1 is 176 <cc number> <cc value>

From what i can see with midiformat you can build the raw bytes, but then you need to concatenate the single byte output into a three byte message?

Does any of the above make sense? I'll try and build some test patches to explain this better. Its easier to accept raw bytes to udpsend especially for sysex messages where they will be much longer than 3 bytes


EDIT: Ok its quite clear the udpsend/udprecieve objects in maxmsp vs pd are quite different. You DONT want the fullpacket option in udpreceive i dont think. Can someone send me a test patch with:
* udpsend object receiving a list int string
* udpreceive to a print.

I only have the max runtime here and have no idea what max *actually* sends if you send a string of three numbers. I guess really we want to accept a list of bytes? I'm just not sure what exactly max sends when you send a list.

Also try passing udpreceive to a midiparse object and see if you get any output

[hoffman2k]

Here's the patch you asked for: http://covops.dreamhosters.com/uploads/ ... maxpat.zip

Cheers

- Bjorn

[amounra93]

@ST8: yeah, I understood the premise, its just not working. I was trying to find documentation on how the udpsend extern is built in C, but couldn't really find what I was looking for. I agree that raw bytes would work better. As far as I can tell, we should be able to do away with the OSC and struct modules in the script (inclusion of them would be one way to make this work) since it will only be expecting integers, but some code will have to be added to parse each element of the string sent and pick out the relevant byte, pack it with the other three descriptors (which I haven't found a good description of yet....whatever max is sending them with) and send them out that way.

[ST8]

So it appears max does a fair bit of its own encapsulation (PD passes raw udp packets). So im wondering if its better to do this over osc. Something like

/sysex int byte int byte int byte ... int byte

[amounra93]

I've already modified the LiveOSC scripts to allow the script to pass sysex back to Live via a [udpreceive] object with no problems (I had the same thoughts as you). I've also been able to get sysex data back to the script, and it will return it via OSC, but I can't get it to send out any MIDI. I've been studying all night and I'm stumped at this point. Anyway, half of it works, just not the half that I need.

I basically just took all the original callbacks out and added a few new ones. I'll publish it tomorrow if you don't come up with anything else. I'm sure what I'm doing is much more complicated than it needs to be.

[ST8]

So you're having problems getting midi back into live from your hardware or is it the other way round? I think the issue with max is that it seems to expect midi messages one byte at a time, which is a bit weird. I guess it expects all messages to be 3 bytes long unless its a sysex message or something?

You're sending ccs, notes or what? As you can try building a raw midi message for say cc.

I'll put together a quick example from LiveOSC for what im thinking, i expect its quite similar to what you've got already though.

Does hardware need to receive a three byte message for midi, or can it work it out if you pass it a single byte at a time?

[hoffman2k]

Not sure if this is relevant, but the UDP objects help file says: Max messages are serialized and sent over the network as OSC compatible UDP packets.

Not sure what that actually means, because everything I send comes out the same way. But I suppose it means at least some type of formatting is required.

[broc]

Not sure if this is relevant, but the UDP objects help file says: Max messages are serialized and sent over the network as OSC compatible UDP packets.

Not sure what that actually means, because everything I send comes out the same way. But I suppose it means at least some type of formatting is required.

Yes, the messages which are actually sent must conform to the OSC syntax such that any OSC receiver can understand them.
The format basically requires an address-string followed by arguments.

Out of curiosity I've looked at the actual OSC messages from Max with the utility 'dumpOSC'.
It turns out that for example a list 1 2 3 is sent as <list 1 2 3>, and a number 10 as <int 10>.

Obviously, if Max itself receives such messages they are re-formatted to the original plain messages.

[amounra93]

So you're having problems getting midi back into live from your hardware or is it the other way round?

I'm having trouble getting midi OUT of Live, from the script. Packets are getting from Live to the LiveOSC (and its bouncing back an OSC message registering that its received the data) but I can't get anything to be sent from the MIDI port that LiveOSC is assigned to.

I guess it expects all messages to be 3 bytes long unless its a sysex message or something?

You can send tAll messages are going to be 3 bytes long unless its a sysex message anyway via MIDI aren't they? But, essentially, when sending MIDI everything should be serial, one byte at a time (I think this is the way it works).

You're sending ccs, notes or what? As you can try building a raw midi message for say cc.

How I've been testing: basically, sending output of Remote25SL control surface script through IAC back into SysexOSC script (modified LiveOSC script living in its own namespace) to test MIDI CC and Sysex into Live. I'm just typing digits into a message box and sending it with an OSC tag, e.g. (/live/midi 176 0 127). I haven't tried serializing the data into it, but it doesn't seem like that would work anyway, since LiveOSC is expecting packages of midi bytes. I'm not sure how to deal with the raw data coming back to LiveOSC from Max yet, that's the whole problem I think.

I'll put together a quick example from LiveOSC for what im thinking, i expect its quite similar to what you've got already though.

That would be awesome This is a great learning experience for me, but a pretty big learning curve at the same time. Some of the module objects are a bit confusing to me, the whole _c_instance_ versus c_instance thing is beating me, and I've gotten a few errors about that in stderr.log (although I think this is just due to max switching in and out of edit mode).

Thanks for the help

@broc thanks for the hint...have to give dumpOSC a whirl....

[ST8]

Ok ive updated the package. It now responds to an osc message of the format:
/ableton/sysex int byte
/ableton/selection int toffset, int soffset, int width, int height

same ports, listens to udp on 5000, sends udp on 5001

I've also fixed the OSC module to be able to send 0s, that may fix your problem.