PlanetZ forums - scopeusers.com

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

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.

faxinadu wrote: Thu Dec 21, 2017 4:41 am 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.

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.

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

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

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.

faxinadu wrote: Thu Dec 21, 2017 6:51 am 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

faxinadu wrote: Thu Dec 21, 2017 6:51 am 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!

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

cool works amazing the one with pads <3 nice nice

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.

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

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

w_ellis wrote: Thu Dec 21, 2017 7:37 am 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

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.

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

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.

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

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!)

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.