PlanetZ forums - scopeusers.com

Message sent using actual OSC protocol (works): message sent over UDP protocol (no bueno):

i am gonna try with javaOsc today but
a) i suck, its literally my second day with java hehe
b) its not public domain and has attributions

but lets see..

will are you SURE your module expects only /x yy ? i read more on the osc protocol and it seems sending just hat over udp is not enough. it expects more formating - at least this also seems to be the difference between what worked and what didn't here.

faxinadu wrote: ↑Wed Dec 20, 2017 1:21 am will are you SURE your module expects only /x yy ? i read more on the osc protocol and it seems sending just hat over udp is not enough. it expects more formating - at least this also seems to be the difference between what worked and what didn't here.

I'm using the Juce OSC library and don't know all the implementation details. All I know is that in Max For Live I just set up a updsend module and send /x yy and it works. There's a good chance that the Max For Live module is doing more than just pure UDP if that's the case.

You can also make each module for 16 outs, but for different input values: module 0: v 0-15, module 1: v16-31 etc.

DragonSF wrote: ↑Tue Dec 19, 2017 11:20 pm 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.

DragonSF wrote: ↑Tue Dec 19, 2017 11:20 pm 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!

DragonSF wrote: ↑Tue Dec 19, 2017 11:14 pm 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.

DragonSF wrote: ↑Tue Dec 19, 2017 11:25 pm 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

faxinadu wrote: ↑Tue Dec 19, 2017 10:26 pm 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.

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

w_ellis wrote: ↑Wed Dec 20, 2017 2:08 am

DragonSF wrote: ↑Tue Dec 19, 2017 11:20 pm 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.

That code was from the early days, before I learned the idiosyncrasies of Scope. Allocating once in the constructor is enough (or checking, if itg is null, and then allocate. Scope will always use the same itg. Sorry for my old misleading info.
Regarding the dll generator: I7ll send you an updated version.

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.

feeling like this now:

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

suddenly im programing away

going really good now

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

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.

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.

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

Cool stuff guys