OSC Receiver and Sender

[faxinadu]

awesome give me 10 minutes ill post here my test tool and a conversion module for scope that takes the integers and converts them to int32 (what scope knobs usually like)

[w_ellis]

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 no problem with having many instances of that (compared to listen ports for receiving).

Here's an animated gif showing it in action!

OSC-Testing.gif (115.85 KiB) Viewed 328960 times

Let me know if it's not clear what all the parameters mean. I'll probably not be able to do much coding until early Jan, when I get back from Munich.

[w_ellis]

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.

[faxinadu]

--

[faxinadu]

for the sender can there be a generic version with no ids? so with scope one could control anything that accepts osc.

[faxinadu]

confirmed sender works here on same pc, tomorrow will test more

[w_ellis]

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 ... p-services

[w_ellis]

And 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

[faxinadu]

Big progress on android app, core technology is set up and working!

25991081_10215812752616830_1446300807_o.jpg (564.43 KiB) Viewed 328853 times

25855898_10215812751696807_268279398_o.jpg (523.02 KiB) Viewed 328853 times

[dawman]

Impressive.
Look forward to more controls for real time parameter modulation.

[faxinadu]

https://play.google.com/store/apps/deta ... t.scopeosc

the scope side update is almost ready too

[sunmachine]

I'd have to check on the exact details of licensing and how it would work for using an open source dll in a commercial project, but here's an idea of the worst case: https://juce.com/get-juce (i.e. it might need a splash screen)

I found the following regarding the splash screen:

The splash screen only affects an exciting new free tier - If you want to release a closed source JUCE-based product, and your revenue/funding is less that $50k, you can do so for free using the Personal license, but you will need to display a splash screen.

Source: https://forum.juce.com/t/splash-screen- ... e/21908/43

Directly in the information section next to the option for turning off the splash screen, it says that the splash screen can be disabled if the app is released under GPL v3

Source: https://forum.juce.com/t/how-to-turn-of ... ects/22329

Based on that, my understanding is as follows. Please correct me if I'm wrong!

1. As per the quotes above, the splash screen is only needed for closed software and when the developer's revenue is less than $50k. If the software is open source under GPL 3, the splash screen is not needed.

2. So, since the ScopeOSC package is released under GPL 3, there's no need for the splash screen.

3. Every SCOPE device that includes the OSC package has also to be released under GPL (and thus has to be open source).

There's also something noteworthy in the Juce 5 License Agreement by the way (highlighting done by me):

We may collect and process information about you and your use of our Program, some of which may amount to personal data. ROLI may also collect IP addresses associated with your end-users’ use of your Application solely for ROLI’s internal operations in providing you the JUCE Program. Personal data will be collected and processed in accordance with our Privacy Policy. Users of free versions of JUCE, such as JUCE Personal or JUCE Education, may not opt out of the tracking of IP addresses associated with the use of your Application by end-users. You agree to inform the end-users of your Applications about our collection of their IP addresses, if applicable, and have your end-users agree to such collection.

Source: https://juce.com/juce-5-license

[w_ellis]

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 ScopeOSC modules separately. I've already created a release for these here.

Re. the data collection, I just need to disable that in the build of the DLLs, as confirmed by ROLi here. See this comment:

"Another option to opt out, if you’re so inclined, is to use JUCE under the GPL license. As long as you release the code alongside the application, you can do what you want with it."

If all else fails, they're not very complicated to reimplement without the JUCE dependencies, but it's certainly nicer to use if I can.

[sunmachine]

Ok, great! Thanks for the clarification! All this licensing stuff is quite complicated. At least for me...
So did you intentionally include the older version 2 of the GPL here?
https://github.com/bcmodular/scopeosc/b ... icense.txt

[w_ellis]

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 the material though, as it's really complicated!

[faxinadu]

gonna try to release the server device tomorrow

meanwhile if anyone feels like it:

https://play.google.com/store/apps/deta ... oscaeolian

[sunmachine]

Looks like the OSC dlls need the msvcp120.dll which was not on my Windows XP system.
The installer installed the 2010 C++ redistributable, but msvcp120.dll comes with 2013.
So installing the following vcredist_x86.exe fixed it: https://www.microsoft.com/en-US/downloa ... x?id=40784

[w_ellis]

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.

[sunmachine]

My Windows PCs are offline and I'm only using them for music stuff, so I don't have installed many applications and usually don't do Windows updates.
I'll try to install it on my Windows 7 box later today.

[w_ellis]

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