vvvv / vl.io.osc Goto Github PK

View Code? Open in Web Editor NEW

8.0 7.0 5.0 1.85 MB

Provides support for the OSC (OpenSoundControl) protocol in VL

License: GNU Lesser General Public License v3.0

C# 100.00%

vl vvvv osc opensoundcontrol

vl.io.osc's Introduction

VL.IO.OSC

Provides support for the OSC protocol.

For use with vvvv, the visual live-programming environment for .NET: http://visualprogramming.net

Getting started

Ships with vvvv
Usage examples and more information are included in the pack and can be found via the Help Browser

Contributing

Report issues on the vvvv forum
For custom development requests, please get in touch
When making a pull-request, please make sure to read the general guidelines on contributing to vvvv libraries

vl.io.osc's People

Contributors

Stargazers

Watchers

Forkers

azeno chkworks mrroundrobin ravazquez sebescudie

vl.io.osc's Issues

Specify Modules for Global Channel System

receiving spread shows too many values

when changing the help patch /zwar sender from tuple to linearspread and add a count of 5:

the receiver sees 4 more values that make no sense:

Cleanup help patches

what is this "zwar"? How does it help me?

Sending and receiving messages with the OSCClient node

I am struggling with the current VL implementation of receiving and sending OSC messages on the same port, which Supercollider apparently does, according to this forum thread:
https://scsynth.org/t/reply-port-of-asychronous-commands/6494/2

We already had a discussion about it in the vvvvorum a while ago:
https://discourse.vvvv.org/t/start-supercollider-server-in-background/20532/12

I had a workaround set up, which I am about to document in here, so maybe this could lead to a proper implementation. Coming back to this soon...

Optimize Enable Data Preview

like so, that more nodes are in the if?

Request: OscReceiver version without learning

i just did this for myself in a project where i don't need learning and want to save those cpu cycles. it's just a matter of deleting the learning stuff from the node, but maybe there's a better solution to that like sourcing out the learning into a separate node or so?

parser doesn't handle recursive bundles

edit: https://discourse.vvvv.org/t/osc-server-not-parsing-bundle-from-python-osc-library/20724/4

Colors are received in the wrong order

Hey,

Using latest vvvv gamma preview (5.3-164).

I'm sending colors from Châtaigne to vvvv via OSC. They are received in the wrong order, i.e as ABGR.

For instance, when sending this purple color

vvvv receives it in the exact inverse order

Châtaigne sends those colors as r typetag.

Had a look inside the lib, and was able to solve it by unchecking Input Is Big Endian inside the UnpackInterger32 function, which is located inside UnpackUtils.

Thanks in advance!

Reducing memory allocations

After profiling a project which made heavy use of this library (~70 sender/receiver nodes in total) we identified the following hot spots regarding memory allocation:

DatagramSender -> Socket.SendToAsync, not much we can do about it except wait, see dotnet/runtime#30797
MatchAddress - string splitting and MessagePattern construction adds up. Can the split be deferred until we indeed have a match? Can the message pattern be cached?
PadNull - If I understand it correctly OSC requires byte blobs and strings to be 4 byte aligned? In that case allocating the memory with the proper size would be more beneficial.
Unpack -> UnpackMessage and UnpackString. Both can be done more efficient using Span.

Attached is a screenshot from the profiler