If a GlobalController is set to not show in VCS, should it still send its OSC data?

Question

Hi SSC,

 

I'm trying to establish an OSC connection to Processing3 where I would like to send a lot of streams at the same time. I have encountered a number of blockers, and wondered if you could clarify.

Firstly, if I set a GlobalController to send osc for example -  !osc_amps_1 - and set this globalController to not show in the VCS, I don't see its output coming into OSCulator or my Processing sketch. Also if I hide the widget in the VCS editor, the OSC signal stops sending.  I deduce that if its not visible in the VCS it won't send the signal?  Is that correct?

My goal is to send many signals over OSC for a visualisation outside Kyma. But I have also noticed that when the VCS is running  I must have Kyma 7 active as the main application, because if it is in the background, the multitude of data streams become sluggish and jerky (as does the VCS animation)

So I tried a SmallFader, which is just the numbers without the widget - which does seem to work better. Unless I try to move any other fader in the VCS (for example one that is not sending OSC data, but is controlling parameters of the Sound synthesis) and then the OSC streams from the Small Faders are temporarily stopped until I stop dragging the Widget I am moving.

I would like to be able to send lots of OSC data without having to see faders animated in the VCS - so that they are not interrrupted by any movement of any of the controls. I'm sure I did this in the past for my RetroInterrupt performance for example,  but I can't seem to get the same behaviour now.

Any thoughts or suggestions?

Answer 1

You could try putting your output OSC widgets on a separate layer of the VCS.  Duplicate the VCS and rename it, then go back to your top VCS, select the OSC-output widgets, and hide them.  Use the top VCS for things you would like to control in Kyma and the other layer for sending OSC.

Comments

Thats good to know that they don't need to be on a visible layout in order to send their signals. Thanks!

Answer 2

Hi Cristian,

just a tip to make things simple ... Another way of passing infos to Processing 3 or any other Visual Software is to use good old MIDI. It works very well through the use of the MIDIOutputController Prototype for example.

With the use of ethernet and Kyma Connect  MIDI should work also fast.

If you need high resultion you can use NRPNs with the MIDIOutputEventInBytes.

Best

Christian

 

Comments

You know what Chris, thats actually a good idea. I just can't get Kyma and Processing to handshake with an arbitrary number of OSC signals. Because Kyma doesn't send the !osc_aValue fields until it receives that same message, this becomes tricky when you want to simply receive a bunch of OSC messages from Kyma into Processing. I would prefer Kyma to  broadcast the values first, and broadcast its IP address, so then the OSC EventListener in the Processing code can configure itself to the NetAddress and messages.

---

The Pacarana makes its IP address and port number available through Bonjour.  Can't Processing get the information from Bonjour?
The reason we wait to receive the OSC message first is so we know where to send it.

---

No Processing doesn't support Bonjour as such - there are UDP libraries, but I can't seem to get the UDP library to find the BeSlime IP and port without sending it a message first (which I can't because I don't know its IP)

I don't have a problem putting in the IP address manually, then I can send Kyma the /osc/respond_to,i destPortNbr succesfully   ... also I am not trying to do bi-directional!  I only want to receive signals from Kyma.

But what happens next once they have done the handshaking is that I have to somehow know how many OSC signals might be coming from Kyma, what they are called exactly and then rewrite my code to send these names. I want to compile a Processing program that can deal with arbitrary OSC data from Kyma, without the user having to do this renaming  - If my program could recieve the message from Kyma, it would be able to rewrite them within my program - only if I could receive them before sending them, but not the other way around. So this rather limits the many interesting applications of OSC from Kyma I think.

For example, I want to visualise Spectral data being transmitted from a Kyma sound. So far I have 256 OSC streams coming out of Kyma. My program needs to know the names of the streams first and send them to Kyma before it receives any data, and that seems like a chicken and egg situation.

Without involving another piece of bridge software (like OSCulator) how should I do this?

---

Hi Cristian,
since Processing is a specialized and simplified Java IDE you can extend it by using one of the various "Zereoconf" implementations for Java.

If you have a look here:
http://www.symbolicsound.com/cgi-bin/bin/view/Learn/OpenSoundControlImplementation

you will see that the Zeroconf/Bonjour is only necessary to establish the communication first.
If it is to troublesome just figure out the IP of the Pacarana manually to send the  /osc/respond_to,i message.

Have a closer look at the Controlling Notification and Requesting Information sections.

If you get into writing more complex applications with the Processing Library i recommend to switch to the Eclipse IDE.
It is a fully featured Java IDE (and more) and there are various tutorials on the net how to use Eclipse with the processing library. Eclipse will also make it easy to include other java libraries into you code (waiter or JmDNS->zerofconf).

Best
Christian

---

Hi Chris. Of course, I have read in depth the Kyma OSC implementation from the day it was first published and know it by heart. I have read all of it very closely in fact, and had many created many applications of it
* 2010 dancing blob video https://www.youtube.com/watch?v=S6ejqolvi2g
* an early experimental OSC stream recorder/looper ... https://www.youtube.com/watch?v=nx73QqONh4E

 Like I said in my post, I already establish the handshaking - its not really this that is the problem. It is that I have to handshake for every single OSC Message I wish to receive from Kyma otherwise it wont send it, even after it has replied to the port respond_to message.

Thanks for the suggestion regards IDE .. I've been coding for 7 years in Processing and prefer the Processing3 IDE over Eclipse. In fact the main point about Processing is exactly that you can avoid the rest of Java which is  really way too complicated for most artists needs.