rename junxion / osc mode

[sensestage]

"I don't think junXion is being supported anymore - so I would suggest renaming the junXion OSX mode to something else -- because sending the minibee id in the address is actually extremely useful in many cases. For example, it's the only way to differentiate between minibees in TouchDesigner. I would suggest giving the two radio buttons as 'OSC send format' with a text field including a preview of the format (also a nice reminder of what address to look for in your client software) ... something like this:

-- OSC Send Format -- O - minibee ID as first element: /minibee/data id val1 val2 O - minibee ID as part of address: /minibee/data/id val1 val2"

[sensestage]

Though there are still JunXion users, I think - so indeed that format needs to be there.

There is an issue that for sending data to the minibee in the junxion format, there are still some hardcoded limitations to how many (I haven't properly automated that part yet).

I have to see how complicated this will be to implement properly.

[sensestage]

Perhaps also datanetwork and libmapper can be removed. Libmapper hasn't been tested or updated since a long time. Datanetwork could be an advance option if we want to keep it around.

[jreus]

I suggest renaming the 'junxion' format because the format itself (addressing minibees by id) is not junxion-specific. It's a useful OSC format in any software. In TouchDesigner especially, but even SuperCollider.. when one would rather create a specific OSCdef by address rather than have a conditional for branching behavior by minibee id.

Getting rid of the datanetwork stuff would be great if nobody is using it. IMO the design approach to Pydon should favor a minimal interface and options. With those present being as self-explanatory as possible.

[sensestage]

In SuperCollider you can use argTemplate to filter for a specific minibee, e.g. for minibee 1:

OSCdef( \minibeedata, { |data,time,source| data.postln; }, '/minibee/data', argTemplate: [ 1 ]  );

[sensestage]

For the names of these options: '/minibee/*' and '/minibee/*/<ID>' does that make sense?

[jreus]

@sensestage hmm, good question... I think it's a question of what level of user we're aiming the Pydon interface at.

Your proposal would be pretty clear assuming that users are 1. familiar with Linux wildcard syntax and 2. understand that there are a variety of Pydon OSC messages of the format /minibee/* ...I think novice Sense/Stage users, or those who just get sensor data into their content creation programs and don't do anything else, will possibly be only familiar with the /minibee/data message, and would be better served by using that as an example in the Pydon UI. Maybe along with a short description of the difference between the two formats for more generality?

minibee ID as the first OSC argument. ex: /minibee/data id data1 data2 ... minibee ID as part of OSC address. ex: /minibee/data/id data1 data2 ...

When users need to use more advanced OSC commands they will probably end up looking to the documentation. At least that's my impression!

[sensestage]

fixed in 99f18abd8e50d5ef2b1de3b18b1cba25560eba2a