Hi Guys,
Is it possible to have more than one midi input on a device? Both inputs carrying midi note data?
My idea is for a mono sum to be produced when two midi notes trigger. The mono sum could be a division, multiplication, subtraction of the difference.
I have tried modifying the 'midi transpose' lesson, but i cant get max to register midi ch 2 activity. Then in live i cant choose channel 2 as an output to an internal track, so i am wondering if there is a way to do it within a device without using abletons midi routing.
So maybe I am asking if its possible to route midi between m4l devices?
What do u guys think?
Udprecieve only working with edit window open
Udprecieve only working with edit window open
Last edited by uberdrums on Sun Apr 08, 2012 8:56 am, edited 1 time in total.
Re: Two midi inputs on a device
It's not possible natively which is a royal pain in the ass. There are two workarounds which you can choose....
Standard send / receive objects do work between patches. So you can create an object "s midinote" or whatever in one with a "r midinote" in another. I would advise caution though as there is latency and worse than that, it is not consistent. But if you are not sending streams of notes where you would notice this difference in latency, it may work for you. It is certainly simpler than the other option....
You can use udpsend / udpreceive objects. So you would create an object called "udpsend 127.0.0.1 8002" and route your data in there. To explain - the data is actually sent over a network, so the "127.0.0.1" is the loopback IP address for your local machine, and the "8002" is simply a port number I plucked out of the air. You should probably choose a port number you know is not used by other protocols (internet, FTP, torrent clients etc). I use 8002 and it is safe for me. Then create an object called "udpreceive 8002" and that will receive all data on that port. This method still has a little latency, but I find it to be consistent. For instance, I can play a drum roll from my electronic dum kit on a synth and it sounds pretty good. This is also a great method for sending data between computers - you simply replace the "127.0.0.1" with the IP address of the other machine (assuming it's on the same network).
If you choose the UDP route, I suggest having a look at the following link as there are some pretty good externals for parsing UDP data should you want to send lots of data over the same port:
http://cnmat.berkeley.edu/
Standard send / receive objects do work between patches. So you can create an object "s midinote" or whatever in one with a "r midinote" in another. I would advise caution though as there is latency and worse than that, it is not consistent. But if you are not sending streams of notes where you would notice this difference in latency, it may work for you. It is certainly simpler than the other option....
You can use udpsend / udpreceive objects. So you would create an object called "udpsend 127.0.0.1 8002" and route your data in there. To explain - the data is actually sent over a network, so the "127.0.0.1" is the loopback IP address for your local machine, and the "8002" is simply a port number I plucked out of the air. You should probably choose a port number you know is not used by other protocols (internet, FTP, torrent clients etc). I use 8002 and it is safe for me. Then create an object called "udpreceive 8002" and that will receive all data on that port. This method still has a little latency, but I find it to be consistent. For instance, I can play a drum roll from my electronic dum kit on a synth and it sounds pretty good. This is also a great method for sending data between computers - you simply replace the "127.0.0.1" with the IP address of the other machine (assuming it's on the same network).
If you choose the UDP route, I suggest having a look at the following link as there are some pretty good externals for parsing UDP data should you want to send lots of data over the same port:
http://cnmat.berkeley.edu/
Re: Two midi inputs on a device
Thanks trevox! For my purposes, i think sync and stability are the most important factors. Latency is fine as long as it is consistant. I am only intending to send pitch information, maybe note on/off.
Does the second method use up much cpu?
Would it be taxing to have many different sources and destinations, maybe 16 of each?
And do you think these could be automated with i.e an lfo? or would there be loss of signal and dead notes?
Does the second method use up much cpu?
Would it be taxing to have many different sources and destinations, maybe 16 of each?
And do you think these could be automated with i.e an lfo? or would there be loss of signal and dead notes?
Re: Two midi inputs on a device
It doesn't use much CPU - I've never really measured it, but have never noticed it being a particular hog.
In terms of having many sources and destinations, for my drum kit router, there are 11 separate notes sent from my drum kit. I take each one of these and create a routing for them. I highly advise using the objects located at the link I posted. What they allow you to do is to route all signals into one object - providing a "name" for each element you wish to route. Just go to the download section and get "Everything for OSX" or "Everything for Windows" and dump all of it into your Max folder (or somewhere Max will find it).
I uploaded the patch I use to split the drums coming in and also one of the receivers to show you an example. I know what you want to do is probably different, but it will give you an idea as to what you need to do. Sorry, I never cleaned up the patches, so there is an amount of redundancy in them - I guess I was just happy it worked so never bothered!
http://dl.dropbox.com/u/30280761/SplitDrumsUDP.amxd
http://dl.dropbox.com/u/30280761/Synth% ... ckUDP.amxd
The first one is placed on a midi track that receives midi notes from my kit. These are always going to be the same notes, so I could hard code what to expect. So using the kick on the kit (it transmits C1) for example - when the kick is played, the route object receives the midi list (36 <velocity>), so the velocity of this gets sent out the first outlet of "route". Then the notes are repacked in separate pack objects. Now all drums are separated, you can use the "js osc-unroute.js" object using arguments to specify what you want to call each send, all prefixed with a forward slash. So for this example, the first input is the kick, so I called it that. Then just route this object into a udpsend object as described before. There is a load of redundancy in this patch which is kind of a throw back to a workaround I was using before using OSC. I could simply send just the velocity straight to "js osc-unroute.js" and treat it on the receiving end. Also, the stuff in presentation mode means nothing as there is nothing to interface with - again a throwback to a method I used to use. I must clean these up as it really is doing a lot more operations that is necessary.
The second one should be placed on a midi track before whatever synth you want the kick to play. A udpreceive object on the specified port is used and routed to a "osc-route" object with the argument of the parameter to be received. That parses all other data being transmitted on that port. And that's it. I have 10 other patches to receive the other drums, but only one splitter is needed. To explain what the rest of this patch is for - I can take the midi coming from the splitdrum patch as the trigger and use the midi data coming from the clip to choose what note value will be played. Basically it is so I can have chord structure playing, though use the kit to trigger the notes themselves. I've had 11 hardware synth patches played completely from my kit and it's loads of fun - pity I am not a great drummer, but one of my mates usually plays the drums while I dick around with the synths and chord structure that is playing.
Anyway, hope this helps.
In terms of having many sources and destinations, for my drum kit router, there are 11 separate notes sent from my drum kit. I take each one of these and create a routing for them. I highly advise using the objects located at the link I posted. What they allow you to do is to route all signals into one object - providing a "name" for each element you wish to route. Just go to the download section and get "Everything for OSX" or "Everything for Windows" and dump all of it into your Max folder (or somewhere Max will find it).
I uploaded the patch I use to split the drums coming in and also one of the receivers to show you an example. I know what you want to do is probably different, but it will give you an idea as to what you need to do. Sorry, I never cleaned up the patches, so there is an amount of redundancy in them - I guess I was just happy it worked so never bothered!
http://dl.dropbox.com/u/30280761/SplitDrumsUDP.amxd
http://dl.dropbox.com/u/30280761/Synth% ... ckUDP.amxd
The first one is placed on a midi track that receives midi notes from my kit. These are always going to be the same notes, so I could hard code what to expect. So using the kick on the kit (it transmits C1) for example - when the kick is played, the route object receives the midi list (36 <velocity>), so the velocity of this gets sent out the first outlet of "route". Then the notes are repacked in separate pack objects. Now all drums are separated, you can use the "js osc-unroute.js" object using arguments to specify what you want to call each send, all prefixed with a forward slash. So for this example, the first input is the kick, so I called it that. Then just route this object into a udpsend object as described before. There is a load of redundancy in this patch which is kind of a throw back to a workaround I was using before using OSC. I could simply send just the velocity straight to "js osc-unroute.js" and treat it on the receiving end. Also, the stuff in presentation mode means nothing as there is nothing to interface with - again a throwback to a method I used to use. I must clean these up as it really is doing a lot more operations that is necessary.
The second one should be placed on a midi track before whatever synth you want the kick to play. A udpreceive object on the specified port is used and routed to a "osc-route" object with the argument of the parameter to be received. That parses all other data being transmitted on that port. And that's it. I have 10 other patches to receive the other drums, but only one splitter is needed. To explain what the rest of this patch is for - I can take the midi coming from the splitdrum patch as the trigger and use the midi data coming from the clip to choose what note value will be played. Basically it is so I can have chord structure playing, though use the kit to trigger the notes themselves. I've had 11 hardware synth patches played completely from my kit and it's loads of fun - pity I am not a great drummer, but one of my mates usually plays the drums while I dick around with the synths and chord structure that is playing.
Anyway, hope this helps.
Re: Two midi inputs on a device
Ok, finally got a chance to play around with this today.
Using your 'Upsend' and the Sun.midisend devices on the M4L library I have got two different midi notes being received on the same channel!
It actually worked straight away. So thanks for all your help. I copyed the Upsend from your patch straight into the Sun.midisend and replaced the midi out with it. On the Sun.midireceive I have replaced the midiin with two Upsends on different ports. Now I am playing around with Maths to modify the signal to get an output.
Thanks for all your help!
Using your 'Upsend' and the Sun.midisend devices on the M4L library I have got two different midi notes being received on the same channel!
It actually worked straight away. So thanks for all your help. I copyed the Upsend from your patch straight into the Sun.midisend and replaced the midi out with it. On the Sun.midireceive I have replaced the midiin with two Upsends on different ports. Now I am playing around with Maths to modify the signal to get an output.
Thanks for all your help!
Re: Two midi inputs on a device
Ok my patch isn't working.
The upsends work, but the patch thereafter doesn't output midi. I have number boxes all displaying input and output but no notes are sounding. If anything does sound it is the original notes, not the sum of two inputs
The upsends work, but the patch thereafter doesn't output midi. I have number boxes all displaying input and output but no notes are sounding. If anything does sound it is the original notes, not the sum of two inputs
Re: Two midi inputs on a device
Ok, patch is working... but my receive device only seems to work when in edit mode. If i close the edit window dow it only seems to play midi events on its own track.
Any ideas anyone?
Any ideas anyone?
Re: Udprecieve only working with edit window open
There is a conflict of binding the udp port between Max (edit mode) and Live (performance mode).
After editing, try to save, close and re-open the Live set.. then it will probably work.
After editing, try to save, close and re-open the Live set.. then it will probably work.
Re: Udprecieve only working with edit window open
Im fairlt sure i already tried that. But I will try again. Sometimes its hard to remember what order you have done things in.
What sort of delays are normal for udpsends? I am getting midi notes delayed by an 8th at 120 bpm.
What sort of delays are normal for udpsends? I am getting midi notes delayed by an 8th at 120 bpm.
Re: Udprecieve only working with edit window open
According to my tests with a simple configuration the delay is proportional to the audio buffer size.
For example, size 512 gives about 12 msec (much less than an 8th note!).
However, it may depend on the actual configuration and thus not predictable in general.
For example, size 512 gives about 12 msec (much less than an 8th note!).
However, it may depend on the actual configuration and thus not predictable in general.
Re: Udprecieve only working with edit window open
When I close and reopen it, it doesn't even work in the edit view?!
(An Ableton forum should definitely have a 'slap-forehead' smiley)
Now the note-shift number box seems to be stuck at +48. But the number before that is showing change from a kslider keyboard object. It seems to stick because of a minus function I have before the Kslider keyboard. If I reset the number box on the left inlet of the minus function it starts going again.
Maybe this is what is happening when I close the edit view?
The note length is also changing and it seems to be shifting the notes 32th out of sync.
Is there any chance someone could look at my patch?
(An Ableton forum should definitely have a 'slap-forehead' smiley)
Now the note-shift number box seems to be stuck at +48. But the number before that is showing change from a kslider keyboard object. It seems to stick because of a minus function I have before the Kslider keyboard. If I reset the number box on the left inlet of the minus function it starts going again.
Maybe this is what is happening when I close the edit view?
The note length is also changing and it seems to be shifting the notes 32th out of sync.
Is there any chance someone could look at my patch?
Re: Udprecieve only working with edit window open
Ok somehow now it works, by saving removing and replacing from the library....It also seems to work on restarting the project. But if I have to edit the device, it means saving a new version each time. Which is bit of a pain. Is this unavoidable?
There doesn't seem to be any noticable delay either. But some of the notes are being shortened. I think it might have something to do with the flush object?
There doesn't seem to be any noticable delay either. But some of the notes are being shortened. I think it might have something to do with the flush object?
Re: Udprecieve only working with edit window open
I have sorted out the flush object. Now the output midi notes are the same length as the source signal. 
Now I am getting a 16th note delay on the note-shifts.
Now I am getting a 16th note delay on the note-shifts.
Re: Udprecieve only working with edit window open
A 16th note is way more of a delay than I get. As broc suggested, it's generally comparable with your audio buffer size, so somewhere in the region of 10ms which I would call practically negligible.
In terms of your patch not working after editing, I don't really get this issue any more, though I have had similar issues in the past when working on other patches and in particular I seem to remember it was when using some java externals that send midi on OSX's internal midi ports. I stopped using them because of this. I have never used this "sun.midisend" device - I am wondering if there is something in that which could be causing the latency issue? Or maybe something in your patch is being triggered before the correct value is set in your patch? I don't understand exactly what you are trying to accomplish, so I am really just guessing.
In terms of your patch not working after editing, I don't really get this issue any more, though I have had similar issues in the past when working on other patches and in particular I seem to remember it was when using some java externals that send midi on OSX's internal midi ports. I stopped using them because of this. I have never used this "sun.midisend" device - I am wondering if there is something in that which could be causing the latency issue? Or maybe something in your patch is being triggered before the correct value is set in your patch? I don't understand exactly what you are trying to accomplish, so I am really just guessing.
Re: Udprecieve only working with edit window open
Sorry for not being more clear, I was hoping to document my findings here to help other people... but i think this thread has been comsumed by my nubeness.
I have been making other patches using udp. which are not as complex and more sucessful.
I am still learning about midi, filtering messages, triggering and numbers in max. All of which have been the issues with my device.
I stopped using the sunsend devices as i thought they could be over complicating everything.
I am trying to make a midi pitch shifter with the shift controlled by another midi note signal.
It works, but I had issues with flush holding notes. Which i sorted it out selecting another source for the flush.
Now the issue is if i have the 'carrier' notes at 16th notes only playing C and on the 2nd beat i send a 16th note to shift it up to D, the shift doesnt occur until a 16th after the 2nd beat.
I think it is more an issue of triggering rather than the udp.
I have been making other patches using udp. which are not as complex and more sucessful.
I am still learning about midi, filtering messages, triggering and numbers in max. All of which have been the issues with my device.
I stopped using the sunsend devices as i thought they could be over complicating everything.
I am trying to make a midi pitch shifter with the shift controlled by another midi note signal.
It works, but I had issues with flush holding notes. Which i sorted it out selecting another source for the flush.
Now the issue is if i have the 'carrier' notes at 16th notes only playing C and on the 2nd beat i send a 16th note to shift it up to D, the shift doesnt occur until a 16th after the 2nd beat.
I think it is more an issue of triggering rather than the udp.