OSC shapes need additional logic

[yaxu]

With SuperDirt PR musikinformatik/SuperDirt#309 from @ahihi, it would be nice to send a message if either the 'sound' or 'dsp' message was present. Probably needs extra logic in the shape.

[yaxu]

Maybe it is easiest to add additional minimal OSC shape for dsp (might need more than one for each dsp parameter, if they are separable)

That would also require ignoring the dsp parameters in the OSC message. This could either be on the tidal side by adding a exclusion list of parameters to the shape (needs a bit of work) or on the superdirt side by ignoring dsp parameters if a sound parameter is present (because they will also come in a separate message).

It seems tidiest to not send the parameters in the first place so I think option 1 would be nice. Also tagging @telephon

[yaxu]

Oh but I guess the dsp does need to go in the same message as the sound. In fact am I right that in some sense the dsp is the sound? In that case maybe what gets sent is an OSC message with sound "sine()" plus an extra flag to say it's DSP? This could be like dsp "local" or dsp "global" if I understand this feature right.

Then on the tidal side it would just need something like dsp code = sound (pure code) # cS "dsp" "local"

But I remember @ahihi you wanted to explicitly set sound too on patterns.. I didn't understand the use case for that then..

[ahihi]

But I remember @ahihi you wanted to explicitly set sound too on patterns.. I didn't understand the use case for that then..

the dsp code be used not only to synthesize, but also to process the output of sound. e.g. dsp "in.fold2(0.5)" # s "gabba"

[ahihi]

what if it was something like this?

data BoolExpr a
  = Val a
  | Not (BoolExpr a) -- not sure if useful
  | All [BoolExpr a]
  | Any [BoolExpr a]

data Args
  = Named {requiredArgs :: BoolExpr String}
  …

then superDirtShape could be

superdirtShape = OSC "/dirt/play" $ Named {requiredArgs = Any [Val "s", Val "dsp", Val "gdsp"]}

maybe with a couple of helpers to keep the simple cases easy to write

allArgs = All . map Val
anyArgs = Any . map Val

superdirtShape = OSC "/dirt/play" $ Named {requiredArgs = anyArgs ["s", "dsp", "gdsp"]}

[yaxu]

Would it be OK to use a different param for processing sound, vs generating it? dsp for sound vs edsp for effect I think that would simplify the implementation

[ahihi]

it would complicate the SuperDirt side, where sound is an independent module (which arguably could already use some simplification) and live-dsp is just another module that runs right after sound (activated by the presence of a dsp key) that may or may not use the output from the preceding module. i think this achieves a nice separation of concerns.

also, one thing to note regarding this:

In that case maybe what gets sent is an OSC message with sound "sine()" plus an extra flag to say it's DSP? This could be like dsp "local" or dsp "global" if I understand this feature right.

Then on the tidal side it would just need something like dsp code = sound (pure code) # cS "dsp" "local"

a pattern can have both dsp and gdsp, because it should be possible to do module-level synthesis/processing and then feed the output into a persistent global effect. example:

tidal.gdsp.mp4

[ahihi]

i tried out #1178 (comment) and i think it does not complicate things much. the only thing that changes is that toData in the Pattern module becomes

toData :: OSC -> Event ValueMap -> Maybe [O.Datum]
toData (OSC {args = ArgList as}) e = fmap (fmap toDatum) $ mapM (\(n, v) -> Map.lookup n (value e) <|> v) as
toData (OSC {args = Named rqrd}) e
  | hasRequired rqrd = Just $ concatMap (\(n, v) -> [O.string n, toDatum v]) $ Map.toList $ value e
  | otherwise = Nothing
  where
    hasRequired (Val k)  = k `elem` ks
    hasRequired (Not x)  = not $ hasRequired x
    hasRequired (All xs) = all hasRequired xs
    hasRequired (Any xs) = any hasRequired xs
    ks = Map.keys (value e)
toData _ _ = Nothing

it occurs to me that the intermediate data structure could even be skipped by making requiredArgs a predicate function:

data Args
  = Named {requiredArgs :: [String] -> Bool}
  …

superdirtShape = OSC "/dirt/play" $ Named {requiredArgs = any (`elem` ["s", "dsp", "gdsp"]) }

toData :: OSC -> Event ValueMap -> Maybe [O.Datum]
toData (OSC {args = ArgList as}) e = fmap (fmap toDatum) $ mapM (\(n, v) -> Map.lookup n (value e) <|> v) as
toData (OSC {args = Named rqrd}) e
  | rqrd ks   = Just $ concatMap (\(n, v) -> [O.string n, toDatum v]) $ Map.toList $ value e
  | otherwise = Nothing
  where
    ks = Map.keys (value e)
toData _ _ = Nothing

though then we lose the automatically derived Show instance on Args.

[yaxu]

Maybe it could be even more general as a field filtervalues :: Maybe (ValueMap -> Bool)?

[ahihi]

you mean Args would become something like this?

data Args
  = Custom {filterValues :: Maybe (ValueMap -> Bool)} -- "Named" didnt seem very descriptive anymore
  | ArgList [(String, Maybe Value)]

seems reasonable, but what is the Maybe for?

another direction of generalizability could be to allow transforming the event data in addition to filtering, e.g. ValueMap -> Maybe ValueMap.