OSC Receiver and Sender

[w_ellis]

You shouldn't do this:
asyncOut[OUTPAD_PARAMS].itg = (int)malloc(4 * numParameters);
You have a memory leak here. I'd allocate the memory only once and re-use it. In your case, every per second you are allocating 640bytes=>1h about 2.5 MB of data, which you are not releasing. Scope does not free the data.

Good spot, I am a C noob, so I actually just copied your code from here, but was probably missing context of what you were doing.

[w_ellis]

And I'm confused:
class ScopeOSCServer : private OSCReceiver

Are you trying to create a server or receiver?

It used to be doing Send + Receive, but I specialised for this module. Probably needs renaming now!

[w_ellis]

Scope arrays are a mess. Having 16 outputs instead of an array is (IMHO) the preferred way. And arrays are not updated automatically. You need to reload/reconnect the module to get an update.

We used array (inputs) a lot with ScopeSync and they work ok-ish. I'd assumed the main issue I had with output arrays was around memory allocation, but interested to hear your experiences.

I'm happy to set the module up with however many parameters, it's just a small piece of work in one place. Arrays would be fantastic if they could be made to work well, but certainly my experiences haven't been amazing either. In the short term, for proving concepts, I'd suggest having a small module and then we can extend later once things are working well.

[w_ellis]

What ever you can handle! (Normally you have to write an interface code for each pin, but my dll generator takes care of this stuff).

Would love to know more about this

[w_ellis]

ok i have done some more testing and it seems the sdk module is not so reliable.

with the app that i confirmed works, and also seeing it transmit every button press over wireshark without problems, the sdk module seems to work only some of the time.

I'll do some more testing tonight, but if you're able to share a screenshot of your SDK project, so I can see what modules you're using that would be really helpful, so I can set up the same test.

[faxinadu]

gimme a couple more hours to fiddle here, taking a new route...

[faxinadu]

YESSSSSSSSSSSSSSSSSSSSS

FINALLY

i have something that works ! <3 <3 <3 <3

please please please - no arrays and at least 64 pads. i would go more even so we are covered. 128 pads for 128 midi protocol ccs.

[faxinadu]

feeling like this now:

http://www.youtube.com/watch?v=FzfSjNSt0Fc

suddenly im programing away

[faxinadu]

going really good now

weeee.png (12.79 KiB) Viewed 386643 times

[w_ellis]

Awesome Faxi, great progress!

In the meantime, I created a new version of the module, with individual outputs as requested. I also added a listen port input. Please note that there is only one instance of the OSC Server for any loaded OSCReceiver modules, so if you set a different listen port for different instances, only one will work and it'll probably screw things up a bit! We'll probably have to have a think about how this should work ultimately, as it's definitely beneficial not to start up a load of instances of the Receiver, but if different devices use it we could run into problems.

Other important fact is that I changed the addresses to be 1-based, so they match the parameter numbers, so /1 will hit O1.

There's also a little testing app if people want to try (just the example that is included with Juce). It sends messages on port 8000 to /1. You can find it here

[w_ellis]

Might even be a good idea to read the OSC listen port from cset.ini actually, thinking about it. But let me know what you think.

[w_ellis]

P.S. 16 parameters is just while we test it out. Once we have things up and running, e.g. with naming the addresses and having a prefix per instance, either we can make bigger versions, or just have multiple modules running together.

[faxinadu]

RAd!!!!!!!!!!!!!!!!!!!!!!

scopopop.png (20.29 KiB) Viewed 386629 times

[petal]

Cool stuff guys

[faxinadu]

thats a good idea clause,i second that, good setup.

[w_ellis]

Yup, I've been thinking that through and it'll be pretty easy. I was thinking that the OSCReceiver module would have a "First Parameter Num" input and you set that to a number, so the first module would have 1 (parameters 1->16), second would be 17 (parameters 17->32) etc.

I was also thinking about a standard OSC address format that we could use that avoids strings*. Something like /<device_instance>/<device_uid>/<param_group>/<param_num>, where device_instance is unique per device loaded by user (at least for a given device), device_uid would be an identifier for the device that's unique on the platform. param_group could mean that we actually always refer to parameters as 1->16 and use the group to reference multiple receivers? The First Parameter Num mentioned above would then become Parameter Groups instead.

* DragonSF - I'd love to know if you had good experiences with passing strings into DLLs, as my memory is of them creating instability.

[faxinadu]

i would send all the incoming osc data direct to the master module in scope just with /x y like you have it now, so it is the easiest integration in just getting the signal into scope. do the splitting once the osc info has reached scope.

[faxinadu]

or... if your module can have a parameter on each pad that states what incoming /x osc message that pad is listening to then that's it - in this case even 16 pads would be enough since each opened module in sdk can be configured to be unique. this would be imo the simplest, cleanest and most logical implementation.

I was also thinking about a standard OSC address format that we could use that avoids strings*. Something like /<device_instance>/<device_uid>/<param_group>/<param_num>, where device_instance is unique per device loaded by user (at least for a given device), device_uid would be an identifier for the device that's unique on the platform. param_group could mean that we actually always refer to parameters as 1->16 and use the group to reference multiple receivers? The First Parameter Num mentioned above would then become Parameter Groups instead.

imo this is way way over the top, keep it as simple and as functional as possible.

[w_ellis]

It's important that you think of* each OSCReceiver module running in Scope, across any devices, receiving all messages and needing to decide which ones it is interested in. We'll need to tell it what to listen for. If we just use the /xx syntax, it will be impossible to disambiguate between loaded instances of one device or even between different devices.

Of the suggestion I gave above, we could simplify by losing the param_group, but for very complex devices (e.g. mixers), you could end up with very high numbers for parameters.

* From an implementation-perspective it doesn't actually work like that, as only one thing listens to all messages, on behalf of all of the module instances.

[faxinadu]

maybe i missed something, can't you make the message a variable?