#Touchosc and osculator code

Then OSCulator will be used to dispatch the messages to the desired application (LiveOSC or SilentWay, both running on two different OSC ports). LiveControl is a TouchOSC for controlling Live with TouchOSC, but if you want to control SilentWay as well, you will have to customize LiveControl layout for example to add a page with all the faders and button you want to use with SilentWay. TouchOSC will send messages to OSCulator, and you will have to send them to SilentWay, just like you did for LiveOSC. Now, if you want to control SilentWay, you need some controls in your TouchOSC layout to do that. So when you receive a message in OSCulator, and want to send it to LiveOSC, assign the OSC Routing event to that message. This is what the OSC Routing will do because it has been configured with LiveOSC as the target. Your TouchOSC layout sends messages to OSCulator that you need to forward to LiveOSC. When I say 'assign the OSC Routing event to every message you want to send to LiveOSC', I mean the following: I'm sorry Rodrigo, but I don't understand you question. 2 way messaging can be a pain, it can be laggy, is quite time consuming and unintuitive to map controls compared to the plug and. I don't remember how bi-directional communications work with LiveControl, obviously you will have to configure it so it responds to TouchOSC, not the oscbroadcaster tool. TouchOSC will need to configured manually because the oscbroadcast tool does not publish a Bonjour service (i.e. Once you found the correct settings it is easy to incorporate the command line in a file that you can launch by double clicking. You will find here a small command line utility that listens for OSC messages, and dispatch them to as many targets as you want. Don't try to handle both directions in OSCulator, it is not needed. You will need to configure TouchOSC so it sends messages to OSCulator, and LiveControl so it sends message to TouchOSC. Then you assign this routing to every message that is registered in OSCulator so it is sent to LiveControl. Then create a OSC Routing (click the + button) and set its target number to the one you just configured. So in the Parameters window, OSC tab, you create a OSC target with LiveControl's port (127.0.0.1:5000, that is 127.0.0.1 for your local computer, and 5000 for LiveControl's default port). Maybe this is a better way to word it.OSCulator can echo messages but not as a whole, you have to configure every individual message so they are properly routed to LiveControl. Can you please explain to me how the midi maps translate into standard midi information. I am only familiar with midi channels and values. OSCulator is a program that translates OSC messages into standard midi so that it can be used by programs that do not support OSC.Įmulations midi map files have information like channel, message, and index. My question was not if emulation supports OSC, but how the midi map file is interpreted to standard midi information. It is already in the todo-list, but I don't know when we are going to implement it. Right?Īt this moment, Cuelux doesn't support OSC.

This would make me think that Emulation operates on only one midi channel. When you change the midi channel to something else and keep the value the same, it performs the same action. For example: If you set value to 1, and channel to 1, you can control playback fader 1.

It seams like in OSCulator it doesn't make a difference what midi channel you set a command to, only what value you set it to. On Osculator, I only have Value and channel. I am confused because it will say something like:

#Touchosc and osculator code

I understand that in the generic midimap file it shows the midi code for the controlling Emulation. I am fairly familiar with both as I am able to control my digital sound mixer with this setup. I am using the Touch OSC interface, with OSCulator. Hey guys, I recently picked up an iPad that I would like to start using in junction with Emulation.