OSC Receiver and Sender

I'll leave the original message here for posterity, but there are now two modules available, an OSC Sender and an OSC Receiver. Pick up the latest release from Github here and have fun! Here's some more detailed documentation on how to use the two modules.

=============

Hi all,

Inspired by the recent buzz of activity, I had a bit of a brain wave and cracked open Visual Studio for the first time in a while to create an OSC Receiver module for the SDK. It's super basic at the moment, but I wanted to get some feedback on what would be the most useful way to evolve it.

You can download it here: ScopeOSCReceiver.dll and at the moment it only has a 16 element output int array as an interface. It's listening on port 8000 and will receive messages with the format /<paramnumber>, e.g. /0 is the address for the first parameter, /1 for the second etc.

My planned next step will be to add a String input array to allow the addresses to be set through the module interface and an integer for the listening port. I'm not sure if it needs much else for now, but let me know what you think. I could add a console view to see messages as they arrive, but that would be quite a bit more work, so I'd do that later.

I'll also build an OSC sender, but that's actually a bit easier, so I thought I'd start with the trickier case.

I'd love to collaborate with others on building either a modular module to encapsulate this, or it could be incorporated into the controller managers I spotted in use by OS and RA. In particular, it would be great to get some help with an interface in the SDK to provide OSC address strings into an array, so I can test that bit. Essentially it would just need 16 string editors connected to an array, but my SDK skillz suck!

Let me know what you think!
Will

P.S. As a bit of additional background, we had a really tough time trying to get ScopeSync to handle Input + Output well, as the SDK doesn't really have a nice way of incorporating a DLL that is bi-directional. This idea of splitting into 2 modules could be an alternative approach to making some progress on that again.

Also, I'd like to thank DragonSF for a tip in one of the threads that allowed me to work with an output array successfully for the first time. It turns out that as a C noob, I hadn't been correctly allocating my memory, hence lots of access violations. Let's just say that ScopeFX isn't beginner-friendly

With an eye on the future, can you

assign midi or CV to OSC input.or.output?
At a top-level, auto detect and roll up all OSC parameters (in or out)?

That might help one day auto-detect all parameters in a synth, or even project, to auto/assisted assignment to controllers (like BCR2000, or Ableton Push via a M4L device, etc.) Or for DAW automation...a possible replacement for XTC mode.

I'm willing to cooperate, because I've got some experience from my EXT-MIDI converter. CV output is good, but MIDI out has problems.

hey will, is this public domain? am i allowed to use this in a commercial device?

you just turned me on an idea

hey will, is this public domain? am i allowed to use this in a commercial device?

I'm planning to keep everything open source, so there shouldn't be a problem, but let's worry about that if there's any serious money to be made

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)

assign midi or CV to OSC input.or.output?

No plan to do anything about that, but those would be standard things that can be done in Scope SDK.

Compared to (Scope's version of CV), the control resolution would be the same, but CV runs over sync, which is properly real-time, whereas the OSC handling will be at async control rates, which are every 50-100ms. In testing that seems to be good enough for most cases, but not if you wanted to do audio-rate modulation (which isn't really what OSC is designed for).

At a top-level, auto detect and roll up all OSC parameters (in or out)?

I'd want to understand the use case a bit better. This is mostly about being able to control Scope synths + effects using OSC, which has the advantage of full 32bit resolution and being able to run over a network (wired or wifi).

I'm willing to cooperate, because I've got some experience from my EXT-MIDI converter. CV output is good, but MIDI out has problems.

Great, I'll get in touch over PM once I have something that should parse a String Array at input for OSC addresses. Feel free to have a poke around at the code, in case you spot anything I could improve (I'm sure there's plenty!) Most of the relevant stuff is here: https://github.com/bcmodular/scopeosc/t ... ver/Source

separate output pads for each element would be cool instead of just the array

separate output pads for each element would be cool instead of just the array

The idea for now was to make it quite flexible, so we can tweak the number of outputs easily etc. I'm not an expert in SDK, but isn't it easy to hook up an array splitter?

trying this out, gimme a bit, having a hard time on the java side im real noob

so to send the value 12 to the first array slot i would need to:

outMsg = "/0 12";

gonna try now

Exactly... easy to do using a udpsend module in Max For Live, or Reaper has OSC tools built in too. I'm sure it's easy to do in TouchOSC too, but it hurt my head when I tried to do it in a hurry the other night!

ha yes the thing is i am trying in Android Studio :0

i mean you don't even need osc tools as long as you transmit the message over the right ip to the right port yeah?

As long as you're using UDP, not TCP, yes.

Code: Select all

 private void runTcpClient() {
        try{
            Socket s = new Socket("192.168.1.13", 5555);
            BufferedWriter out = new BufferedWriter(new OutputStreamWriter(s.getOutputStream()));
            String outMsg = "";
            outMsg = "/0 12";
            out.write(outMsg);
            out.flush();
            out.close();
            s.close();
        }

i think something like this should do it, but im struggling to connect it to a button yet

ahhh this is tcp i think

ok so this:

http://www.roman10.net/2011/11/22/andro ... h-example/

Code: Select all

private void runUdpClient()  {
    String udpMsg = "hello world from UDP client " + UDP_SERVER_PORT;
    DatagramSocket ds = null;
    try {
        ds = new DatagramSocket();
        InetAddress serverAddr = InetAddress.getByName("127.0.0.1");
        DatagramPacket dp;
        dp = new DatagramPacket(udpMsg.getBytes(), udpMsg.length(), serverAddr, UDP_SERVER_PORT);
        ds.send(dp);
    } catch (SocketException e) {
        e.printStackTrace();
    }catch (UnknownHostException e) {
        e.printStackTrace();
    } catch (IOException e) {
        e.printStackTrace();
    } catch (Exception e) {
        e.printStackTrace();
    } finally {
        if (ds != null) {
            ds.close();
        }
    }
}

[quote=w_ellis post_id=332668 time=1513687473
I'd want to understand the use case a bit better. This is mostly about being able to control Scope synths + effects using OSC, which has the advantage of full 32bit resolution and being able to run over a network (wired or wifi).
[/quote]

I was thinking of Copperlan, the way a remote end can present a list of available parameters to choose from. But maybe I need to know the limitations of OSC better first.

ok so this:
http://www.roman10.net/2011/11/22/andro ... h-example/

Yup, Datagram Sockets is what you want!

I was thinking of Copperlan, the way a remote end can present a list of available parameters to choose from. But maybe I need to know the limitations of OSC better first.

Yeah, probably looking to walk before we can run I had a look into Copperlan a while back and from an implementation perspective it's a bit of a nightmare. Super complex and a lot of features that I imagine a tiny fraction of people would use.

Code: Select all

package c.oceanswift.scope1;

import android.support.v7.app.AppCompatActivity;
import android.os.Bundle;
import android.view.View;
import android.widget.Button;

import java.io.IOException;
import java.net.DatagramPacket;
import java.net.DatagramSocket;
import java.net.InetAddress;
import java.net.SocketException;
import java.net.UnknownHostException;

public class MainActivity extends AppCompatActivity {

    @Override
    protected void onCreate(Bundle savedInstanceState) {
        super.onCreate(savedInstanceState);
        setContentView(R.layout.activity_main);

       
        final Button button = findViewById(R.id.Randomizer);
        button.setOnClickListener(new View.OnClickListener() {
            public void onClick(View v) {
                    String udpMsg = "/0 12";
                    DatagramSocket ds = null;
                    try {
                        ds = new DatagramSocket();
                        InetAddress serverAddr = InetAddress.getByName("192.168.1.13");
                        DatagramPacket dp;
                        dp = new DatagramPacket(udpMsg.getBytes(), udpMsg.length(), serverAddr, 8000);
                        ds.send(dp);
                    } catch (SocketException e) {
                        e.printStackTrace();
                    }catch (UnknownHostException e) {
                        e.printStackTrace();
                    } catch (IOException e) {
                        e.printStackTrace();
                    } catch (Exception e) {
                        e.printStackTrace();
                    } finally {
                        if (ds != null) {
                            ds.close();
                        }
                    }
            }
        });
    }
    }

any hints why this isnt working? its a button on that is supposed to send on click

Sometimes there can be issues with firewalls, especially when sending across LAN. You might need to add an exception to a firewall on the listening PC.

I'm assuming you don't have any errors from the app? You could also use something like Wireshark to listen for the messages.

i don't have any compile errors but i have some debugger errors when clicking the button. its very much possible i have errors heh. yah im grabbing a sniffer, but imo my code is wrong

i think i got better java code now, but checking via the steps outlined in the link, it does not seem like anything is listening on port 8000 on my pc. i got the module open in sdk.

https://stackoverflow.com/questions/481 ... on-windows

The problem is that all those answers are talking about TCP. Listening on UDP is quite different. Mostly you just want to see if the messages are arriving on your machine now, which is where Wireshark comes in.

its showing udp answers too....

yeah im also with wireshark checking

aaaaa.png (180.33 KiB) Viewed 3982 times

so as far as i can see i am both transiting and receiving but nada on scope

Sorry, I only skimmed the page and saw all the stuff about TCP. It looks like you're doing the right thing with your app.

I'm actually just working on the OSC Sender, which I'll probably finish tomorrow. That will at least make it easy to check that stuff is working locally.

Btw. how are you checking that you're getting something on Scope? I generally just plug in one of Simon's Pipe modular modules and look at the values there. You have to be a bit careful with the readouts though, as the SDK often doesn't update them without explicitly refreshing.

Unfortunately have to go to bed now, as teething baby will be keeping us up all night, but hope to make more progress tomorrow!

yeah but once a value is sent, it is held in the array until a new one comes in yeah? its not momentary and reverts... so i should have seen my magic little 12 there by now ehhehe tried refreshing, clicking and declicking the module, going into the array with f2 and other wishful things... hmmm not sure what else to try, kinda stoked and shocked i even got the android part to work (lots of copy paste from online codes heeh).

ok i just verified your module works using some random android app called QuickOsc! so still something im doing isn't right

oscc.png (89.88 KiB) Viewed 3966 times

it seems the QuickOsc is working via OSC protocol while mine is over UDP... those are the differences i spotted

EDIT: fixed issue, i didn't notice the module inherits voices and it was getting 0 voices, sorry my bad, but yeah something to make sure when testing!

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 have also forwarded the port via my router to the target pc as well as activated dmz host for good measure.

on same procedure ie open sdk, open the module and trasnmit to it sometimes it will connect and sometimes not.

eheh ok new issue - i can not get it to update anything real time.

osc module is connected to an array viewer that has selcount input and value output. a 0-1 normal scope button is connected to the value output.

quickosc is sending a 0 and a 1. the osc module is getting the info and it is passed to the splitter - but the information is not updating real time, only if and when i physically change the selcount to another sel and back, will it show the change.

i am not sure if its an issue from the osc module or the way to view arrays, but i anticipated this stuff i have been banging my head against the wall with some scope array issues lately, that is why i asked for 16 outputs instead of an array.

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.

I'm willing to cooperate, because I've got some experience from my EXT-MIDI converter. CV output is good, but MIDI out has problems.

Great, I'll get in touch over PM once I have something that should parse a String Array at input for OSC addresses. Feel free to have a poke around at the code, in case you spot anything I could improve (I'm sure there's plenty!) Most of the relevant stuff is here: https://github.com/bcmodular/scopeosc/t ... ver/Source

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.

And I'm confused:
class ScopeOSCServer : private OSCReceiver

Are you trying to create a server or receiver?

Scope arrays are a mess. Having 16 outputs instead of an array is (IMHO) the preferred way.

for sure!

and anyways......... why just 16? any chance for 64?

Scope arrays are a mess. Having 16 outputs instead of an array is (IMHO) the preferred way.

for sure!

and anyways......... why just 16? any chance for 64?

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

Message sent using actual OSC protocol (works):

udp1.png (35.44 KiB) Viewed 7729 times

message sent over UDP protocol (no bueno):

udp2.png (38.34 KiB) Viewed 7729 times

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.

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.

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.

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!

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.

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

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

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

weeee.png (12.79 KiB) Viewed 7661 times

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

scopopop.png (20.29 KiB) Viewed 7647 times

Cool stuff guys

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.

My suggestion: only the first instance will be the OSC receiver. All other will get trheir data from the 1st. As all the instance pointers are stored in a static array, there shouldn't be a problem. Data is pushed from instance 1 to the appropiate instance (i.e. event on device 1-16 goes to 1st instance, 17-32 to 2nd and so on). SO you can have as many events as you like, but you don't need one monster module.

thats a good idea clause,i second that, good setup.

Yup, I've been thinking that through and it'll be pretty easy. I was thinking that the OSCReceiver module would have a "First Parameter Num" input and you set that to a number, so the first module would have 1 (parameters 1->16), second would be 17 (parameters 17->32) etc.

I was also thinking about a standard OSC address format that we could use that avoids strings*. Something like /<device_instance>/<device_uid>/<param_group>/<param_num>, where device_instance is unique per device loaded by user (at least for a given device), device_uid would be an identifier for the device that's unique on the platform. param_group could mean that we actually always refer to parameters as 1->16 and use the group to reference multiple receivers? The First Parameter Num mentioned above would then become Parameter Groups instead.

* DragonSF - I'd love to know if you had good experiences with passing strings into DLLs, as my memory is of them creating instability.

For good reasons, I avoided strings as parameters so far. If possible, stay away from that.

i would send all the incoming osc data direct to the master module in scope just with /x y like you have it now, so it is the easiest integration in just getting the signal into scope. do the splitting once the osc info has reached scope.

or... if your module can have a parameter on each pad that states what incoming /x osc message that pad is listening to then that's it - in this case even 16 pads would be enough since each opened module in sdk can be configured to be unique. this would be imo the simplest, cleanest and most logical implementation.

I was also thinking about a standard OSC address format that we could use that avoids strings*. Something like /<device_instance>/<device_uid>/<param_group>/<param_num>, where device_instance is unique per device loaded by user (at least for a given device), device_uid would be an identifier for the device that's unique on the platform. param_group could mean that we actually always refer to parameters as 1->16 and use the group to reference multiple receivers? The First Parameter Num mentioned above would then become Parameter Groups instead.

imo this is way way over the top, keep it as simple and as functional as possible.

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 instances of one device or even between different devices.

Of the suggestion I gave above, we could simplify by losing the param_group, but for very complex devices (e.g. mixers), you could end up with very high numbers for parameters.

* From an implementation-perspective it doesn't actually work like that, as only one thing listens to all messages, on behalf of all of the module instances.

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

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.

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.

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!

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 7714 times

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

scopecad.png (51.72 KiB) Viewed 7916 times

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.

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)

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

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.

--

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'd put the relevant data in an ini-file (own or cset). And don't forget to do initiate another module as receiver, if the 1st one is deleted.

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

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

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

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

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

25991081_10215812752616830_1446300807_o.jpg (564.43 KiB) Viewed 7760 times

25855898_10215812751696807_268279398_o.jpg (523.02 KiB) Viewed 7760 times

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

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

the scope side update is almost ready too

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

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.

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

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!

gonna try to release the server device tomorrow

meanwhile if anyone feels like it:

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

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

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.

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.

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

Installation on my Windows 7, 64-bit system worked fine!

New versions of the OSC Sender and Receiver available for testing here: https://github.com/bcmodular/scopeosc/t ... ipt/Output

Sender:
- Added Snapshot (Snap) - change value of this inpad to force an OSC message to be sent for all values
- Added Sending Messages (Send) - 0 = don't send, > 0 = send (doesn't catch up, so you can use snapshot after re-enabling if needed)

Receiver:
- Added Listening to Messages (List) - 0 = don't listen, > 0 = listen

When using in SDK, be careful about loading new version in old project, as the new pads mean that there could be weirdness. Recommend deleting old modules first and then loading new ones. Then save project, close SDK and re-open, just to be on the safe side.

I'm not planning other changes to the pads now, so hopefully there won't be other breaking changes, but if I do, I might version the DLLs instead. Let me know what you think.

confirmed to work, also it does not break connections on devices using older versions, so all good

Good to know!

The only further change I have planned before looking into integrating these into ScopeSync is to load a config for listening port from a file. If there are any other needs that people have (or bugs!), please feel free to raise them here: https://github.com/bcmodular/scopeosc/issues

Now reads listener port from C:\Users\xxx\AppData\Roaming\ScopeOSCReceiver\ScopeOSC.settings (or equivalent for different versions of Windows). File is created on first load of OSCReceiver module and will only be re-read at startup, so changing setting will require Scope to be restarted. I'm assuming that this won't be an issue for people as they won't need to change it very often.

https://github.com/bcmodular/scopeosc/t ... ipt/Output

N.B. Defaults to 8000 still.

Hi !

After those 7 thread page and code discussion, I'd really like to know how OSC is working on Scope !
I downloaded the setup file, installed it but I don't know what to do next !

I must say that I don't know what to do with all the 7 pages of this thread : I'm not a OSC developer. I just found 2 receiver & sender DLL files but I don't know how to transform them on usable scope devices with some GUI I would deal with ! I don't find either any useful info for a guy like me on the github OSC pages...

Thanks for help !

Hi JoPo,

This definitely isn't the thread for you if you're not using the SDK! faxinadu has integrated these modules into some devices that he announced elsewhere in the forum and I'm beavering away in the background to hook them into the updated version of ScopeSync that's been a couple of years in the brewing. In the time-honoured tradition here, it'll be done soon

Thanks,
Will

Ah ! Ok. Thanks a lot, Will !

to be honest i was sure people would be going crazy about it and all over this. but somehow it seems its only interesting for a few of us. :/

to be honest i was sure people would be going crazy about it and all over this. but somehow it seems its only interesting for a few of us. :/

Wait a bit ! I think that if any of you release some OSC Scope devices, other people would be interested. For instance, the amazing Falcon and many new very good vst's have OSC features. I could modulate things in Falcon from Scope. A device that convert audio signals into OSC signals and in the other way, would be awesome !

How are OSC signals time accurate ? Are they as bad as midi ? What is the resolution in frequency and in bits ? I have no idea : I never used OSC. I affraid that if OSC signals are carried by wifi or ethernet, the timing could not be as good as needed for some precise rythmic applications but in fact, I don't know.

See announcments forum

But is OSC obligatorily usable with tablet or smartphone ? I really hate touch screen devices ! I'm reading a ebook for experimenting and it is awful !! It's heavy but I must hold it in my hands, so it zooms sundenly, jumps to 3 pages after but I need to hold it, there is no place for my fingers, sometimes they just touch the screen and...f..g sh...it. The screen is ful of finger traces. Une vraie merde.

I'd like to use it just to replace midi at least for modulating signals. AND WITHOUT TABLET !

you can use it with anything, it is a server but i also think u should give the android control another chance, i too had some controllers on phone/tablet like 5-6 years ago, and the interfaces themselves have come a long long way. as long as its not extreme low end crappy tablet or something then it is both very responsive, very stable and fun. i still say try it, but again it is a server and a client and works with anything.

Most of the DAWs have good OSC support now. To answer your question from above, I wouldn't recommend for very timing critical needs, but it should work very well for parameter automation. Unfortunately there's always some level of delay due to scope's async implementation, but it's fairly small (a few tens of milliseconds).

Wifi itself and even internet in general can have excellent latency, just depends on setup. First person shooter games are very demanding on latency too

i can vouch for the way my own apps behave with osc using will's scope osc core and using my own java built pc side osc core - faster or as fast as midi

So... With your devices... Can I just send & receive modulation signals between Scope and some vst's that support OSC without need of android ?

Yes exactly.

Eh eh... Thanks ! Now, I'm very interested !

I've added some documentation describing the use of these two modules here: https://github.com/bcmodular/scopesync/ ... DK-Modules. There's also a new release with minor performance and stability improvements. Download it from here: https://github.com/bcmodular/scopeosc/releases

New release (0.1.2-beta) of ScopeOSC modules available now here: https://github.com/bcmodular/scopeosc/releases. This doesn't affect the main functionality, but will be required for the upcoming ScopeSync 0.6.0 release, which is slowly but surely on its way!

Documentation Wiki is also updated to reflect the changes: https://github.com/bcmodular/scopeosc/wiki and has been moved from the ScopeSync Wiki, which is now closed down, as I will be putting together documentation for the new release at http://www.scopesync.co.uk