It works! 

    set' :: (Subset '["freq","amp"] sdArgs, Real n, VividAction m)
         => String -> Node sdArgs -> n -> m ()
    set' "freq" s n = set s (toI n :: I "freq")
    set' "amp" s n = set s (toI n :: I "amp")

This has a property that, depending on your point of view, you could call a disadvantage or a feature: `set'` can only send messages to synths (`Node`s) for which "freq" and "amp" are both valid parameters. If you wanted to use it with a lot of unique synths, and their parameters have unique names, then you would have to make every synth recognize all the parameters of all the others. (Those extra parameters could be no-ops, part of the type signature but unused in the definition.)

I'm in kind of a weird place, fighting with Vivid's brilliant type safety.

Is there a theoretical maximum to the number of parameter names `set'` could be defined for? I tried 33 and it compiled.


On Wed, Jul 4, 2018 at 9:31 PM Jeffrey Brown <jeffbrown.the@gmail.com> wrote:
Thanks, Claude! I'm working on moving your example into the Vivid context.

Tom, indeed, that would be simpler! I wanted to use `toI`. But I don't see how to do that without hard-coding every choice of which parameter to send a message to.

For instance, suppose you've got a list of parameter names `["freq","amp" ..]` from which you want the code to choose a parameter `p` randomly every cycle, and set it to the value `x`. You can't write `set s (x :: I p)`, because the `p` in `I p` is a type-level variable rather than an ordinary one.

I considered keeping a list of functions `[setFreq, setAmp ..]` instead of a list of parameter names, but I haven't found how to represent such a list:
.
    > :set -XDataKinds 
    > :set -XRankNTypes
    > s <- synth boop ()
    > [set s (3::I "amp"), set s (5::I "freq")]

    <interactive>:194:22: error:
        • Could not deduce: Elem "freq" '[] arising from a use of ‘set’
          from the context: VividAction m
            bound by the inferred type of it :: VividAction m => [m ()]
            at <interactive>:194:1-41
        • In the expression: set s (5 :: I "freq")
          In the expression: [set s (3 :: I "amp"), set s (5 :: I "freq")]
          In an equation for ‘it’:
              it = [set s (3 :: I "amp"), set s (5 :: I "freq")]
    > 


On Wed, Jul 4, 2018 at 11:50 AM <amindfv@gmail.com> wrote:
The approach I'd use might be a little different. Vivid offers a "toI" function which takes any number and converts it to an "I".

So for example:

```
myNums = [1..10] :: [Double]

sd0 = undefined :: SynthDef '["freq"]
sd1 = undefined :: SynthDef '["amp"]

main = do
   s0 <- synth sd0
   s1 <- synth sd1
   forM_ myNums $ \n -> do
      set s0 (toI n :: I "freq")
      set s1 (toI n :: I "amp")
```

Also: "toI" works on any numeric type (any "Real n"), and "I" itself is a numeric type. So you can always write:

x = 5 :: I "freq"
y = toI x :: I "amp"

Tom


El 4 jul 2018, a las 08:30, Jeffrey Brown <jeffbrown.the@gmail.com> escribió:

Composers reuse melodic material across different instruments. I would like to do that in Vivid. I would keep a sequence of values and send it sometimes to one parameter of one synth, sometimes to a different parameter of a different synth.

To do that I would have to coerce those numbers to values of type `I a`, where the string `a` is known only at runtime. I tried to write a function to do that:

    import GHC.TypeLits
    toIOf :: (Real n, GHC.TypeLits.KnownSymbol a) => String -> n -> I a
    toIOf "freq" n = toI n :: I "freq"
    toIOf "amp" n = toI n :: I "amp"

but it won't compile, because the outputs of `toIOf "freq"` and `toIOf "amp"` have different types.

Is this possible?

--
Jeff Brown | Jeffrey Benjamin Brown
Website   |   Facebook   |   LinkedIn(spammy, so I often miss messages here)   |   Github   
_______________________________________________
Livecode mailing list -- livecode@we.lurk.org
To unsubscribe send an email to livecode-leave@we.lurk.org
_______________________________________________
Livecode mailing list -- livecode@we.lurk.org
To unsubscribe send an email to livecode-leave@we.lurk.org


--
Jeff Brown | Jeffrey Benjamin Brown
Website   |   Facebook   |   LinkedIn(spammy, so I often miss messages here)   |   Github   


--
Jeff Brown | Jeffrey Benjamin Brown
Website   |   Facebook   |   LinkedIn(spammy, so I often miss messages here)   |   Github