Making a process node available globally

[lecloneur]

Hi,

I’m trying to make a communication system where I don’t have to patch an OSCClient down to all levels and potentially the same for OSCServer.

I know how to make a SingleInstance, but my approach to store an OSCClient in a singleton isn’t working.

Is this even possible without repatching the OSCClient ?

GlobalOSC.vl (36.4 KB)

[tonfilm]

Yes this is possible, you can wrap the process node in a class and then call create and update individually. This way your can put the create in the single instance and then call the update or other methods of it wherever you access the single instance.

[lecloneur]

Thanks,

this is how I made it working : GlobalOSC.vl (38.0 KB)

Still curious why here the ouput pin looks like it is on Update while the link is of a different Operation, There was a post where @Elias explained something about that I think but couldn’t find it again.

[Elias]

The “State Output” of a process node is special in a way that it behaves more like a pad than a pin. Say we wouldn’t have process nodes at all, then you’d use a pad to manage the instance. And pads are not assigned to any operation/moment - they hold a value/instance you can access anytime you want. We didn’t want to take that feature away when using a process node, therefor that pin behaves like a pad and is rendered in gray (well thruthfully it should probably be rendered as a circle, but that might look weired).

[Elias]

On a second note looking at your patch: a nicer approach would probably be to simply use the S/R nodes to make a server/client globally available, like this:

Note: I use the Do region to ensure that S is executed before R.

[lecloneur]

I didn’t thought about the good old R&S but while I do understand this sentence :

I use the Do region to ensure that S is executed before R .

why is the Do region needed because it seems to be working without it ?

[joreg]

it is really only needed in case you want to make sure that your app can send and OSC message in the first frame after it started.

explanation: since by default there is no link between S and R nodes, their execution order is undefined. ie in the first frame it coult be that R is executed, receiving nothing, before S is executed. the Do region is an option to define a dependency between S and R in a way that S gets executed first.

if sending an OSC message in the first frame is not a requirement, you can ommit this explicit specification of the execution order.