osc

[tomara-x]

of the data types supported by osc, the csound opcodes only send/receive floats, vectors, or strings. i think that's doable here

study: https://github.com/funatsufumiya/bevy_mod_osc

• is it only udp?
• working at the update rate is fine, no?
• can a circle be an independent sender/receiver with this?
  • don't think so. the sender is a resource.. plan b?
• why are they using lazy static? (as in what's the use of something like that?)

what have you unleashed!

plan b:

• std::net
• https://github.com/loopystudios/bevy_async_task (so many familiar faces!) (why tho? async_compute?)
• https://github.com/klingtnet/rosc

one singular sensation, every little step she takes (bararararara)
one thrilling combination, every move that she makes (papappa papappapa)

https://github.com/CNMAT/OpenSoundControl.org/blob/master/spec-1_0.md

[tomara-x]

3a0a33c fuck. doing it with async tasks kinda works but i notice a lag sometimes and it's driving me bananas.
there's also the issue when listening on a port but then changing it, then it doesn't work.
i might have to do it with threads?

found this: https://github.com/DrLuke/bevy_rosc
which isn't updated, and i think it works in a funny way, need to dig more tho (it doesn't send? i think it also needs to hardcode the ip:port in the add_plugin call?)

[tomara-x]

scratch all that, bevy_mod_osc is epic! put it in thread mode and have an osc port op that sets the port in the resource (hopefully that works), and then any number of osc r {address} ops can receive from different addresses.. i think that's good enough.
send should be much easier

[tomara-x]

hard coded port it is! fuck it!

edit: 😭

[tomara-x]

753166e
op string osc r {osc address} will receive vectors of floats sent over port 1729, the floats are written to this circle's array

edit: actually i don't think that's a vector (to osc) it's a bunch of floats? the types are f, ff, ...

[tomara-x]

7388b3a
osc_s {osc address} sends to address, osc_ip and osc_port will set the host and port for the sender (default to 127.0.0.1:1729)

[tomara-x]

fuck! now running multiple instances is gonna panic

a) figure out a way to avoid this (talk to mod_osc dev)

• gracefully give up if binding to the socket fails, or;
• is there a way to do it anyways? or maybe retry adding the plugin? move adding the resource and starting the thread to a thing that can be done in update?
• go to them with a solution if you can
• if only we can specify the port of the receiver (and restart it)

you might wanna make a module for that and customize it a bit (cause i feel it's too big of a change for mod_osc) (or at least try this idea out) so an op sets a resource and spawns a thread (give it a channel so it can be terminated) so you can change port from process (and you only actually start the thread once the op is given input) and no conflict with other instances, and if there is, you just give it another input.. hope that makes sense tomorrow :p

see https://github.com/DrLuke/bevy_rosc

okay, non-blocking is cute stuff, but that will make it not work in realtime. happy with the init op tho, now just need to figure out the thread stuff :3 i wanna try this more

🟢

[tomara-x]

i can't shake the thought of "why not receive (with a socket in non-blocking mode) on the audio thread?).. someone is rolling in their grave rn probably >:3c

[tomara-x]

needs cleaning 6def158

• send_port, send_host, init (which takes receive port) is so asymmetric!
• a stop op that sets the socket to none?
• when receiving you wanna store all the messages (in a local?) and compare against addresses like we had before (so receiving becomes an internal thing that's always done as long as the socket is some)

[tomara-x]

i think we're good a146be3

even better 96ce9ff

[tomara-x]

look at em go! communicating with each other 🥰

2024-05-12_01-24-18.mp4

[tomara-x]

aand sensors are a must

https://www.youtube.com/watch?v=MOicQRViGxE