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
In Montevideo I'm using maps from string to float to represent messages. This lets me represent arbitrary sequences of SuperCollider events, something I was unable to do using tuples because GHC is picky about their types.
But Vivid's set expects a VarList, which is a family of tuples:
Currently my hack has been to extract a separate tuple for each key-value pair in the Map String Float, and set that tuple. But since the sequences I generate can be pretty complicated, that leads me to unbundle gobs of messages that really ought to be sent together.
The only solution I'm aware of would be to hard-code how to respond to every possible set of message keys. I'm using a synth with more than 33 parameters, so that would mean 2^30 = more than a billion definitions. I'm not even sure that would compile.
Can this be worked around?
The text was updated successfully, but these errors were encountered:
JeffreyBenjaminBrown
changed the title
convert a Map String Float to a VarList
Represent a [VarList]? Convert a Map String Float to a VarList?
Aug 2, 2020
But that has the disadvantage that each ScMsg has "forgotten" its type. They can be used to set' a synth, but they cannot be analyzed, say, to convert a pattern in one parameter to a pattern in another.
In Montevideo I'm using maps from string to float to represent messages. This lets me represent arbitrary sequences of SuperCollider events, something I was unable to do using tuples because GHC is picky about their types.
But Vivid's
set
expects aVarList
, which is a family of tuples:Currently my hack has been to extract a separate tuple for each key-value pair in the
Map String Float
, andset
that tuple. But since the sequences I generate can be pretty complicated, that leads me to unbundle gobs of messages that really ought to be sent together.The only solution I'm aware of would be to hard-code how to respond to every possible set of message keys. I'm using a synth with more than 33 parameters, so that would mean 2^30 = more than a billion definitions. I'm not even sure that would compile.
Can this be worked around?
The text was updated successfully, but these errors were encountered: