-
-
Notifications
You must be signed in to change notification settings - Fork 260
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Rationalise Sound.Tidal.Params #763
Comments
I'm starting work on this, there's a lot of old parameters left over from the old tidal-midi implementation that should probably be removed. What's a good way to get a list of superdirt parameters? With osc type would be ideal. |
Here's what it's looking like so far:
|
@yaxu As I understand it, incorporating template haskell into what tidal-parse/MiniTidal recognizes is not impossible (template haskell constructs are part of the AST returned by haskell-src-exts, for which tidal-parse then uses haskellish to parse further into Tidal constructs, so...), but it would be a massive increase in the complexity of tidal-parse. Definitely not something I'd be able to take on... (to say this a different way: GHCJS absolutely does support template Haskell - however GHCJS is only what is used to build Estuary, it is not available as a service in the run-time environment - tidal-parse is what is used to parse things at run-time) Trying to follow this issue and the previous one it is connected to, I feel like I don't have a full grasp of what the goal is. My basic thought is that sending pan messages once and sending them continuously are such different scenarios that there's no need to abstract them into each other. Using "pan" for one kind of panning and "panbus n" for the other already seems very workable to me. Making all uses of pan involve bombarding the sound server with messages, even when the pan position doesn't change, seems strange. But possibly I have just misunderstood something about what the goal is! ;) |
In any case, I do very much hope as many parameters as possible stay in common between the different implementations - inevitably diverging, but with as large an area of commonality as possible... since all three Dirts have panning with basically the exact same semantics, it would be pretty weird for them to have different parameters for that, for example. |
@dktr0 scsynth only gets messages if the end-user says so, by explicitly routing a parameter to a bus, so I think we're in agreement there. A lot of the comments on the other issue are just me thinking through how to make a nice UI for it. Yes lets try to keep the dirts talking the same language as much as possible. I want to keep classic dirt going too although probably won't find implement these control busses.
|
As for TH I got something working but it wasn't making things less complicated.. Easier to just generate the code as text then compile it as per 54430b7 |
In solving #762 we create an extra function for each parameter to handle on-the-fly control busses. Sound.Tidal.Params is already unwieldy, so maybe this is a good time to rationalise this.
We could do this with code generation e.g. at compile time with Template Haskell, or at with an external script e.g. with perl or python. In the latter case this could maybe done automatically as part of the build process, or manually.
Template Haskell is tempting, but I think doesn't work with ghcjs, so wouldn't work for estuary (is that right @dktr0 ?)
One thing to bear in mind is that from this release we now have a two-way protocol developing between tidal and superdirt. So it could also be that an editor could somehow request a list of the available parameters from superdirt, which it then uses to create all the functions.
Following this thought, webdirt and indeed classic dirt don't have the same parameters as superdirt, so maybe they should have a different set of params.. But it's nice for patterns to run on both platforms even if some of the effects don't work on one of them.
A problem is that a superdirt synth might have a lot of parameters that then fill up the namespace and overwrite functions.
In cases like superfm it has a lot of individual parameters, and it's better to hand craft a function that modifies multiple parameters at once.
Logically speaking, parameters should have a namespace of their own, Params.pan etc, but even a shortened P.pan would be a real pain to type. There is already the possibility to do pF "pan".
So maybe for now we keep things as they are, not sure!
The text was updated successfully, but these errors were encountered: