adamiam

I'm developing a max object using the Java API, which I know is a bit old now but it's working quite nicely for me. The object is meant to be used within a M4L object, to process received notes and to output results to various Ableton channels.

Outputting MIDI to multiple channels in Ableton seems to be an age-old problem, as Ableton doesn't allow a MIDI channel to receive just one channel from a MIDI channel, as would be possible in other programs. In my mind, the standard workaround to this is to create a bunch of send objects in my main device and separate remote devices for each channel to then use receive objects, selecting from whichever channel they want the notes of.

So this is my setup: a main device that processes input MIDI and then puts it into 16 send objects, and in indeterminate number of separate receive devices, which can choose which sends to receive from.

Here's the problem: I've timed the output of my main device and everything's being output at the precisely correct time, but the notes received by the remote devices on each channel are jittered and glitch out occasionally, and the Send Receive objects must be the thing causing this.

I know that there's a method for using UDP in the Java API, but that would just be the same as using Send and Receive objects, unless I am mistaken?

I'd greatly appreciate any advice on how to make the most consistently and accurately timed communication take place between my main device and the remote devices, even if this would mean there would be increased latency, as this could be compensated for.

I'm developing a max object using the Java API, which I know is a bit old now but it's working quite nicely for me. The object is meant to be used within a M4L object, to process received notes and to output results to various Ableton channels. 

Outputting MIDI to multiple channels in Ableton seems to be an age-old problem, as Ableton doesn't allow a MIDI channel to receive just one channel from a MIDI channel, as would be possible in other programs. In my mind, the standard workaround to this is to create a bunch of send objects in my main device and separate remote devices for each channel to then use receive objects, selecting from whichever channel they want the notes of. 

So this is my setup: a main device that processes input MIDI and then puts it into 16 send objects, and in indeterminate number of separate receive devices, which can choose which sends to receive from. 

Here's the problem: I've timed the output of my main device and everything's being output at the precisely correct time, but the notes received by the remote devices on each channel are jittered and glitch out occasionally, and the Send Receive objects must be the thing causing this. 

I know that there's a method for using UDP in the Java API, but that would just be the same as using Send and Receive objects, unless I am mistaken? 

I'd greatly appreciate any advice on how to make the most consistently and accurately timed communication take place between my main device and the remote devices, even if this would mean there would be increased latency, as this could be compensated for. 

Hello All, 
I'm developing a max object using the Java API, which I know is a bit old now but it's working quite nicely for me. The object i

quickest-and-most-accurately-timed-method-of-communication-between-objectspatches

I think perfect timing is only possible with standard routing between tracks. So you could try this: In the main device put a program change message immediately before each note message with 16 different program numbers and send everything out of the track. Each remote device can then receive all messages via standard routing and filter out the relevant notes using a gate controlled by program number.

@broc Thanks very much for your help. I've tried this but have encountered something that prevents this from being a solution. The main device is a max instrument, as this allows it to receive from multiple channels, but max instruments don't seem to be able to output Program Change messages, unless I am mistaken.

Another remote max device does not seem to receive Program Change messages using [pgmin], from my main max instrument device's [pgmout] object, and I can't figure out why. I've tested this with max midi effects, which seem to communicate perfectly fine using [pgmout], so it seems to be a limitation on max instruments?

@broc Thanks very much for your help. I've tried this but have encountered something that prevents this from being a solution. The main device is a max instrument, as this allows it to receive from multiple channels, but max instruments don't seem to be able to output Program Change messages, unless I am mistaken. 

Yes, unfortunately M4L instruments don't allow midi output. It's a general limitation of Live where devices and tracks are strictly classified regarding midi/audio communication.

Broc's approach is definitely the best in terms of timing. 

I am not sure about your "receive from multiple channels" issue, but wouldn't that be a case in which the instrument rack could be useful? For example, running an M4L instrument and a M4L midi device on the same track in parallel?

Screen Shot 2018-10-11 at 4.33.26 PM.png

Broc's approach is definitely the best in terms of timing.  

I am not  sure about your "receive from multiple channels" issue, but wouldn't that be a case in which the instrument rack could be useful? For example, running an M4L instrument and a M4L midi device on the same track in parallel? 

Thanks for the suggestion, Florent, although I'm not sure I understand it. Could you explain further possibly?

Just for the sake of clarity, I need to be able to route MIDI from many channels into my device and also route MIDI from my device to many channels, all with accurate timing (allowing for latency.)

Thanks for the suggestion, Florent, although I'm not sure I understand it. Could you explain further possibly? 

Just for the sake of clarity, I need to be able to route MIDI from many channels into my device and also route MIDI from my device to many channels, all with accurate timing (allowing for latency.) 

ah sorry I misunderstood your question. you're kind of stuck with the limitation of M4L unfortunately

but you could maybe use a third-party plugin like this one 

https://www.codefn42.com/midichfilter/index.html 

on a midi track, add a midi effect rack with as many chains as midi channels you need and with an instance of this plugin on each chain. On each chain, a midi device that adds a specific program change number. The midi effect rack's output is combined and sent out of the midi track using Live's routing. 

I'm getting pretty good results with send and receive when selecting low buffer sizes though. Not sure why you're getting glitches. 

ah sorry I misunderstood your question. you're kind of stuck with the limitation of M4L unfortunately
but you could maybe use a third-party plugin like this one  https://www.codefn42.com/midichfilter/index.html 
on a midi track,  add a midi effect rack with as many chains as midi channels you need and with an instance of this plugin on each chain.  On each chain, a midi device that adds a specific program change number. The midi effect rack's output is combined and sent out of the midi track using Live's routing. 
I'm getting pretty good results with send and receive when selecting low buffer sizes though. Not sure why you're getting glitches.  
Hope this helps! 



A possible solution would be to change the concept of your "main device". Put all midi processing into midi effects on the input tracks and add program changes to indicate the channel. All outputs from these tracks go to the instrument track (separating the channels internally by program change) and can also be read from other devices. Relevant parameters of the "distributed midi processing" could still be controlled globally using send/receive (where latency doesn't matter).

Thanks for the help and suggestions @Florent and @Broc.

If I understand you both correctly, that the MIDI processing should take place on each input's own channel, this would not be a solution because the purpose of the main device is to process each input with respect to each other.

The processing of channel 1 is directly dependant on the state of channel 2 and channel 3, for example, which means that all channels need access to the state of each other at any moment in time, hence the need for a central main device rather than many separate processes.

That said, as @Florent says, I'm getting pretty good results now with Send-Receive (although not perfect) by minimising the actual number of messages sent. Sending a list of every note in a chord as a message rather than sending every note in the chord in its own message has made a huge difference, as can be seen below - maybe I'm just being OCD about it now... I'd still prefer it to be perfect!

Screenshot 2018-10-13 at 20.45.49.png

If I understand you both correctly, that the MIDI processing should take place on each input's own channel, this would not be a solution because the purpose of the main device is to process each input with respect to each other. 

I'm interested in what you're saying about combining chords as a list. Do you use thresh to do it? 

it looks like black midi :) 
I'm interested in what you're saying about combining chords as a list. Do you use thresh to do it? 




yes black midi has been something of an influence. I'm using a buffer in the mxj object to combine notes into chords.

Sorry, I'm working on this with the hope of selling it as part of a larger project, so I can't share it, but it will be available once it's all done.

Quickest and most accurately timed method of communication between objects/patches