OSC Receiver and Sender

[faxinadu]

each slot from 16 has a value pad and a message to listen to pad

[w_ellis]

P.S. device_instance would need to be unique per loaded instance of a device, would probably need to be user-editable and would need to be stored in project configuration.

device_uid would be a value stored in a device and published so people could avoid using the same value. We could even agree a range of device_uids for each developer, so this wouldn't need to be negotiated very often.

[w_ellis]

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

We could definitely do that, but it significantly increases the patching effort inside the SDK and I'm not sure I see what value it adds (assuming we're not using human-readable strings - see DragonSF's comment above). I can imagine it becoming a nightmare to debug if a given parameter osc address was set wrong.

[faxinadu]

it adds value in the sense that i can just open the sdk module, lets say for ocean storm i would just assign the slots to listen to /storm1 to /storm16 and thats it. open another synth assign it whatever...

edit: ahhh ok i think i catch your drift... you don't wanna use strings in the message names thats the thing?
edit: ahhhhhhhhhh ok and yeah didn't take multiple instances into account hmmm.

[faxinadu]

will thought more about it, your way is probably the best option. i kinda dislike the idea of really long message addresses but i can't think of anything better than your proposal.

i restarted from scratch on my little app. better code. now i have text fields on the front panel for ip and port, works

[faxinadu]

will can u please send me that module you mentioned that lets you see the array update in realtime? would make testing faster

[w_ellis]

The version I uploaded yesterday doesn't use arrays anymore. Are you using that yet?

With the previous version, I was using the Pipe module from BC Modular and hooking it up to a Range Text, which seemed to work well.

[w_ellis]

will thought more about it, your way is probably the best option. i kinda dislike the idea of really long message addresses but i can't think of anything better than your proposal.

I don't anticipate them being very long. An example would be /3/10010/3/5 - Third loaded instance of device 10010, parameter group 3, parameter 5. Not so different to MIDI - port/channel/cc

i restarted from scratch on my little app. better code. now i have text fields on the front panel for ip and port, works

Awesome!

[faxinadu]

oh i didnt notice damn! grabbing now man ty! do you wanna test my app? i just added also the ability to set the message for the knob

oscccc.png (8.38 KiB) Viewed 349496 times

[faxinadu]

cool works amazing the one with pads <3 nice nice

[w_ellis]

Any thoughts on my earlier question about where to store the OSC port number? I could easily create a dedicated preferences file for it, which might be safest. I think it's misleading to have it as an input to the module, as it can only be one value across all devices.

[w_ellis]

I'm assuming that most people won't need to change it...

[faxinadu]

actually i say keep it, might serve a function for the future!

btw i have the perfect device to try this on in a real world situation... but it is part of a commercial pack, do you allow me to try? of course i will send it to you for free

scopecad.png (51.72 KiB) Viewed 329024 times

[faxinadu]

Any thoughts on my earlier question about where to store the OSC port number? I could easily create a dedicated preferences file for it, which might be safest. I think it's misleading to have it as an input to the module, as it can only be one value across all devices.

maybe keep it as a pad, but have it initialize to 8000

[faxinadu]

will if we are keeping port as a parameter couldn't we just have each useage of it provide a port entry option for the user? so each device that embeds this will have to pull a text fader to the panel where the user sets the ports, and that's it no? takes care of multiple instances and everything i think.

[faxinadu]

aaaaaaaaaaaaaah lol sorry im getting too excited - port won't do on the broadcasting side, since it will be broadcasting on 1 port nevermind, just curious. so yes i get the reasons behind the setup now, i'm in if you go for what you described

[w_ellis]

Try this new version out: Scope DLL

The main reasons not to allow individual ports per device/instance:
- Will create firewall pain every time a new port is used. At the moment users will need to enable the relevant port once ever.
- It's inefficient in the module to have multiple instances of the OSC Receiver object, as the architecture neatly supports multiple listeners on the same port. It would drive up memory usage to have one per device/instance

See how you get on with patching this version. I think it's pretty easy to use.

[w_ellis]

As an example, I passed 1, 10001 and 1 into the 3 inputs and was able to control values by passing messages with addresses /1/10001/1/x

[w_ellis]

We can agree that Ocean Swift gets the Device UID range from 10000 to 19999 as an early adopter benefit (when you've build more than 10,000 devices we'll give you a new range!)

[w_ellis]

Oh, and of course I'm happy for you to try this out in one of your devices. We'll need to do some digging about licensing, but I'm sure there's ways to sort it out.