You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
OSC inputs to Strudel might be quite useful in various cases too, something to consider.
Another thought, regarding #33, perhaps there should be a separation between schema and protocol, i.e. you could potentially use the same schema over OSC, WebRTC, etc.
The text was updated successfully, but these errors were encountered:
I think the dirt/play prefix should actually be removed + a new .superdirt function should be added with that prefix intact, see #63 (comment)
here's an example of how you'd get custom osc messages: https://strudel.tidalcycles.org/?XhW1Hcn-MriE this will send messages like dirt/play/x/1/y/3 or x/1/y/3 when dirt/play is removed.
is it a limiting factor if the message always uses key value pairs?
using ":" syntax, it is also possble to get array values: https://strudel.tidalcycles.org/?vigTL4LDX9dv although osc will currently still turn those into key value pairs, meaning [ 2, "arbitrary", "arguments" ] turns into 0/2/1/arbitrary/2/arguments. but maybe key value pairs are just fine.. i haven't used osc enough to know
Tidal has facilities and docs for defining "OSC Targets": https://tidalcycles.org/docs/configuration/MIDIOSC/osc
Strudel currently only supports SuperDirt's OSC protocol: https://strudel.tidalcycles.org/learn/input-output
Here's the code:
strudel/packages/osc/osc.mjs
Lines 39 to 70 in b0a8d12
It would be great to be able to define OSC Targets for using Strudel to control other things, with some docs to go with it.
As an example, @freeeco wants to control Toybox in Reaktor similar to this https://cdm.link/2020/11/free-nano-community-modules-for-reaktor-blocks-with-tidalcycles-support-and-tons-of-toys/
As an additional thought, OSC inputs to Tidal have been a topic for a while:
OSC inputs to Strudel might be quite useful in various cases too, something to consider.
Another thought, regarding #33, perhaps there should be a separation between schema and protocol, i.e. you could potentially use the same schema over OSC, WebRTC, etc.
The text was updated successfully, but these errors were encountered: