PlanetZ forums - scopeusers.com

I've updated the setup.exe to include the 2013 Redistributable instead now. I'll wait to hear if this causes anyone any issues!

The latest version can be downloaded here

Ah, yes, that's why I always used to build the ScopeSync DLLs on VC++2010. I think there might be a problem for people on really old versions of Windows. I'll check with Simon, as I think he had the problem at one stage. I'll just rebundle with the 2013 version for now to fix it for most people.

Yeah, still have a little bit of tidying up to do with licenses through the source code, but was planning to go with v2 for now, as that's what we're using in ScopeSync and what Juce demands. We could use v3 alternatively, but doesn't seem like it'll make too much difference. I'm still re-reading th...

I think it doesn't apply in quite the same way to DLLs, based on my reading of various threads on this topic. Essentially, as long as the closed source project does not Distribute the DLLs, then it does not need to become open source to make use of them. People will need to download and install the ...

petal wrote: ↑Tue Dec 19, 2017 3:04 am I know I'm dreaming, but it is a beautiful dream where you have both XTC-mode and Scope-mode available at the same time on the same system

That's the dream of Scopesync Starting to get back into it after a bit of a Daddy and new job/country hiatus

DragonSF wrote: ↑Thu Dec 21, 2017 3:24 pmAnd don't forget to do initiate another module as receiver, if the 1st one is deleted.

Yeah, the ScopeOSCReceiver is used as a reference counted object shared between all instances of the loaded dll, which will be created if it doesn't already exist

for the sender can there be a generic version with no ids? so with scope one could control anything that accepts osc. Not totally sure what you're looking to achieve, but perhaps you could try using broadcast addresses? See here for details: https://docs.microsoft.com/en-us/dotnet/framework/network...

P.S. I spoke with Faxi over WhatsApp and clarified that you can pass full int32 values over the OSC messages, so no need to scale them. I think that's the best use of the protocol and then scale for display at either end.

I've just finished the first version of the Sender, which you can find here: Scope DLL Seems to work inside the SDK. Will be interested if anyone gets time to point the sender outside, especially to a different PC. Note that you can set a different Port + Host per instance of the sender, as there's ...

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.

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

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

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 O...

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

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.

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, par...

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.

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 i...

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 r...

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 i...