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_at_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_at_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_at_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 <https://msu.edu/~brown202/> | Facebook
>> <https://www.facebook.com/mejeff.younotjeff> | LinkedIn
>> <https://www.linkedin.com/in/jeffreybenjaminbrown>(spammy, so I often
>> miss messages here) | Github
>> <https://github.com/jeffreybenjaminbrown>
>>
>> _______________________________________________
>> Livecode mailing list -- livecode_at_we.lurk.org
>> To unsubscribe send an email to livecode-leave_at_we.lurk.org
>>
>> _______________________________________________
>> Livecode mailing list -- livecode_at_we.lurk.org
>> To unsubscribe send an email to livecode-leave_at_we.lurk.org
>>
>
>
> --
> Jeff Brown | Jeffrey Benjamin Brown
> Website <https://msu.edu/~brown202/> | Facebook
> <https://www.facebook.com/mejeff.younotjeff> | LinkedIn
> <https://www.linkedin.com/in/jeffreybenjaminbrown>(spammy, so I often
> miss messages here) | Github <https://github.com/jeffreybenjaminbrown>
>
>
--
Jeff Brown | Jeffrey Benjamin Brown
Website <https://msu.edu/~brown202/> | Facebook
<https://www.facebook.com/mejeff.younotjeff> | LinkedIn
<https://www.linkedin.com/in/jeffreybenjaminbrown>(spammy, so I often miss
messages here) | Github <https://github.com/jeffreybenjaminbrown>
_______________________________________________
Livecode mailing list -- livecode_at_we.lurk.org
To unsubscribe send an email to livecode-leave_at_we.lurk.org
Received on Thu Jul 05 2018 - 04:51:47 BST