sc-users] ANN: Vivid: SuperCollider + Haskell

best,
Miguel

--cores 4

Currently this is will build quite a few haskell packages from source.
To download almost all the packages as binaries you have to use the more
recent nixpkgs from github. Clone the nixpkgs from github to somewhere
local and then :

> nix-env -I nixpkgs=/path/to/the/clone/of/nixpkgs -iA ihaskell-with-packages
--option extra-binary-caches http://hydra.nixos.org --option
extra-binary-caches http://hydra.cryp.to -f '<nixpkgs>' --cores 4

Works nicelly in IHaskell, check how it looks here:

http://www.friendlyvirus.org/files/vivid.html

to run it you do:

IHaskell notebook

best,
Miguel

<email obscured>> wrote:

> On 30-03-2015 00:29, <email obscured> wrote:
> > Hey Miguel -- thanks, I've updated this. It should work for you now.
> >
> > Tom
>
> Great, thanks, now it builds easilly with nix. For future reference here
> is a config.nix for vivid with IHaskel:
>
> place in ~/.nixpkgs/config.nix
>
> https://gist.github.com/miguel-negrao/8234ad179274e7657e2a
>
> place in ~/.nixpkds/haskell/vivid-0.1.0.3.nix :
>
> https://gist.github.com/miguel-negrao/ce2564ccbf32b9ad81c5
>
> then
>
> > nix-env -iA nixpkgs.ihaskell-with-packages --option extra-binary-caches
> http://hydra.nixos.org --option extra-binary-caches http://hydra.cryp.to
> --cores 4
>
> Currently this is will build quite a few haskell packages from source.
> To download almost all the packages as binaries you have to use the more
> recent nixpkgs from github. Clone the nixpkgs from github to somewhere
> local and then :
>
> > nix-env -I nixpkgs=/path/to/the/clone/of/nixpkgs -iA
> ihaskell-with-packages --option extra-binary-caches http://hydra.nixos.org
> --option extra-binary-caches http://hydra.cryp.to -f '<nixpkgs>' --cores 4
>
> Works nicelly in IHaskell, check how it looks here:
>
> http://www.friendlyvirus.org/files/vivid.html
>
> to run it you do:
>
> IHaskell notebook
>
> best,
> Miguel
>
> --
>
> Read the whole topic here: Haskell Art:
> http://lurk.org/r/topic/7cSY1qmcVtY6Xvve2pjsIZ
>
> To leave Haskell Art, email <email obscured> with the following
> email subject: unsubscribe
>

-- file: SinOsc.hs:
{-# LANGUAGE DisambiguateRecordFields #-}
module SinOsc where

data SinOsc = SinOsc { freq :: Int, phase :: Int }
 deriving (Show)

sinOsc = SinOsc { phase = 0 }

-- file: LFTri.hs:
{-# LANGUAGE DisambiguateRecordFields #-}
module LFTri where

data LFTri = LFTri { freq :: Int, phase :: Int }
 deriving (Show)

lfTri = LFTri { phase = 0 }

-- file: foo.hs:
import LFTri
import SinOsc

main = do
   print $ sinOsc { freq = 440 }
   print $ lfTri { freq = 440 }



I get complaints about:

    Ambiguous occurrence ‘freq’
    It could refer to either ‘LFTri.freq’ or ‘SinOsc.freq’

This seems consistent with the docs (
https://downloads.haskell.org/~ghc/latest/docs/html/users_guide/syntax-extns.html#disambiguate-fields
), and (a little bit annoyingly) still doesn't work even with an explicit
e.g. ":: SinOsc".

Were you able to work around this somehow?

Tom


On Thu, Apr 9, 2015 at 11:01 PM, Rohan Drape <email obscured>> wrote:

> hello tom,
>
> > But to have default record fields (which is the thing i'm trying to
> > solve), we'd need default values, e.g.
> >
> > sinOsc = SinOsc { rate = AR, freq = 440, phase = 0 }
> >
> > Which would require users to write e.g.
> >
> > sinOsc { SO.rate = KR, SO.freq = 220 }
>
> actually we can write the field names unqualified.  we don't even need
> DisambiguateRecordFields at the "caller" if we write it into the
> library.  i added a "DRF" module at hsc3-rec to illustrate this, the
> examples below are from the help file.
>
> best,
> rohan
>
> ps. i put an R (for record) suffix on the names so they don't collide
> with hsc3.  this form is kind of nice, it gives the standard hsc3
> conventions if you write the constructor directly (ie. upper case, see
> "track" below).
>
> import Sound.SC3 {- hsc3 -}
> import Sound.SC3.UGen.Record.DRF {- hsc3-rec -}
>
> -- > drawR analog_bubbles
> -- > auditionR analog_bubbles
> analog_bubbles :: UGenR
> analog_bubbles =
>     let o = lfSawR {rate = KR,freq = mceR [8,7.23]} * 3 + 80
>         f = lfSawR {rate = KR,freq = 0.4} * 24 + o
>         s = sinOscR {freq = midiCPSR f} * 0.04
>         c = combNR {input = s,decaytime = 4}
>     in outR {input = c}
>
> -- > drawR sprinkler
> -- > auditionR sprinkler
> sprinkler :: UGenR
> sprinkler =
>   let f = lfPulseR {rate = KR,freq = 0.09,width = 0.16} * 10 + 7
>       t = lfPulseR {rate = KR,freq = f,width = 0.25} * 0.1
>   in outR {input = bpz2R {input = whiteNoiseR * t}}
>
> -- > drawR track
> -- > auditionR track
> track :: UGenR
> track =
>     let x = MouseX 220 660 Linear 0.1
>         y = MouseY 0.05 0.25 Linear 0.1
>         s = Saw AR x * y
>         a = Amplitude KR s 0.05 0.05
>         [f,_] = mceChannelsR (pitchR {input = s})
>     in Out 0 (mceR [s * 0.25,SinOsc AR (f / 2) 0 * a])
>
>
> _______________________________________________
> sc-users mailing list
>
> info (subscription, etc.):
>
http://www.birmingham.ac.uk/facilities/ea-studios/research/supercollider/mailinglist.aspx
> archive: http://www.listarc.bham.ac.uk/marchives/sc-users/
> search: http://www.listarc.bham.ac.uk/lists/sc-users/search/
>

Tom


On Mon, Apr 20, 2015 at 10:31 PM, Rohan Drape <email obscured>> wrote:

> hello tom,
>
> > I'm not able to reproduce that behavior -- here's a simple example:
>
> the variant that works is at:
>
>   http://rd.slavepianos.org/sw/hsc3-rec/Sound/SC3/UGen/Record/DRF/Type.hs
>
> the 'UGen' type has a constructor for each unit generator.
>
> i deleted the 'R' suffix, so there's now a module Sound.SC3.UGen.Record.DRF
> that re-exports the parts of hsc3 required for simple graphs.
>
> the 'autogen' codes are at:
>
>   http://rd.slavepianos.org/sw/hsc3-rec/mk/build-drf.hs
>
> i've only added a few ugens to the "whitelist" so far, enough to test
> the graphs at:
>
>   http://rd.slavepianos.org/sw/hsc3-graphs/gr/analog-bubbles-r.hs
>   http://rd.slavepianos.org/sw/hsc3-graphs/gr/analogue-daze-r.hs
>   http://rd.slavepianos.org/sw/hsc3-graphs/gr/berlin-1977-r.hs
>   http://rd.slavepianos.org/sw/hsc3-graphs/gr/bouncing-objects-r.hs
>   http://rd.slavepianos.org/sw/hsc3-graphs/gr/drummer-r.hs
>   http://rd.slavepianos.org/sw/hsc3-graphs/gr/lfo-modulation-r.hs
>
> http://rd.slavepianos.org/sw/hsc3-graphs/gr/sample-and-hold-liquidities-r.hs
>   http://rd.slavepianos.org/sw/hsc3-graphs/gr/sprinkler-r.hs
>   http://rd.slavepianos.org/sw/hsc3-graphs/gr/strummable-guitar-r.hs
>   http://rd.slavepianos.org/sw/hsc3-graphs/gr/synthetic-piano-r.hs
>
> there are other more "expressive" record systems for haskell, it
> depends on what you're wanting to do, but the standard records do
> allow default values and named parameters that overlap...
>
> best,
> rohan
>
> ps. i've only got ghc 7.10.1 here...
>
> pps. a simplified example to test this is:
>
> {-# LANGUAGE DisambiguateRecordFields #-}
>
> data U = A {freq :: Double,phase :: Double}
>        | B {freq :: Double,phase :: Double}
>
> a,b :: U
> a = A 440 0
> b = B 440 0
>
> c :: (U,U)
> c = (a {phase = pi},b {freq = 441})
>
>
> _______________________________________________
> sc-users mailing list
>
> info (subscription, etc.):
>
http://www.birmingham.ac.uk/facilities/ea-studios/research/supercollider/mailinglist.aspx
> archive: http://www.listarc.bham.ac.uk/marchives/sc-users/
> search: http://www.listarc.bham.ac.uk/lists/sc-users/search/
>

Tom


> El 20 abr 2015, a las 23:58, Rohan Drape <email obscured>> escribió:
>
> hello tom,
>
>> and in fact you don't need -XDisambiguateRecordFields then
>
> well spotted!  that makes DRF a very poor name for this...  i'll
> change it to CRU, which is also bad but less obviously so...
>
>> main = print $ sinOsc { someCrazyArg = "aw crap" }
>
> yes, that's unfortunate isn't it.
>
> perhaps one day there will be an excellent record system with conscise
> syntax and coherent rules and "al manner of thyng shal be wele"...
>
> best,
> rohan
>
>
> --
>
> Read the whole topic here: Haskell Art:
> http://lurk.org/r/topic/7pdQD7jQ1E48o46qFF1ypI
>
> To leave Haskell Art, email <email obscured> with the following
email subject: unsubscribe

>
> I just watched the interface of vivid and wondered about the scary types.
> I think it would be possible even in Haskell 98 to have something like
> this:
>
> sinOsc :: UGen SinOsc
>
> freq :: (Freq typ) => Float -> UGen typ -> UGen typ
> phase :: (Phase typ) => Float -> UGen typ -> UGen typ
>
> class Freq typ where setFreq :: typ -> typ
> instance Freq SinOsc where setFreq f args = args {sinOscFreq = f}
> instance Phase SinOsc where ...
>
> SinOsc is the record holding the arguments for a sine oscillator.
>
>
> Then you could write:
>    phase (pi/2) $ freq 800 sinOsc
>
> --
>
> Read the whole topic here: Haskell Art:
> http://lurk.org/r/topic/I5rZKvj6KuAhGvpTSWQV7
>
> To leave Haskell Art, email <email obscured> with the following
email subject: unsubscribe

best,
julian

> El 23 mar 2016, a las 06:43, Rohan Drape <email obscured>> escribió:
>
> hello julian,
>
> it's not that type of typing...
>
> all ugens end up with the same type.
>
> (there is a lot of work on typing data flow
> systems, but supercollider bindings aren't really
> an approriate place for it)
>
> (ie. signal types could tell things like what
> clock-rate the signal is on, how many input tokens
> it consumes to produce an output token, the type
> of the tokens etc. etc.)
>
> this is more about the haskell record system,
> which is very simple
>
> (the history of why it's still the way it is is
> interesting...)
>
> in this particular case i don't think the standard
> haskell records are so bad
>
> for ugens they behave about the same as sclang
> named arguments, except that it's either all
> positional or all named, no mixing
>
> ie. http://rd.slavepianos.org/sw/hsc3-rec/Help/cru.hs
>
> the runtime error for setting a field that doesn't
> exist (ie. the x_err_no_field value in that file)
> is
>
>  *** Exception:
>      /home/rohan/sw/hsc3-rec/Help/cru.hs:52:18-37:
>      Non-exhaustive patterns in record update
>
> which is pretty good.  it's the same situation as
> if you wrote SinOsc.ar(width:0.5) in sclang
>
> i've found that, for supercollider work, defering
> ugen graph errors to run-time isn't a problem, i
> mean there are enough other problems...

I just remembered another issue with using records: the user can't define new
UGens.

So UGen arguments are defined as a record, with every possible field written
out:

UGArg { freq :: UGen, rq :: UGen, localBuf :: UGen, warp :: UGen, etc, etc.

But if someone writes their own ugen or uses a nonstandard set of ugens,
there's no way to support those fields if they don't already exist. E.g. if i
write a ugen with a "brightness" arg and "brightness" isn't in my big record of
arguments, there's no way for me to use it. This isn't just a theoretical
concern: I know someone who writes their own ugens fairly often.

In a way, the solution I arrived on is conceptually simpler, since it's just
labels: you can use whichever ones you like.

Tom


> the other aspect, annotating "required" arguments,
> seems like a separate issue, ie. you could lift
> them out as arguments to the "default"
> constructor, etc.
>
> it's also kind of ambigous, though less so with
> say CombN.ar() than SinOsc.ar().
>
> in any case, for ugens i think the most useful
> thing is having an editor that shows what the
> parameters and the default values are.
>
> best,
> rohan
>
> --
>
> Read the whole topic here: Haskell Art:
> http://lurk.org/r/topic/75NJ3g1xhqFNIp0oiacl2e
>
> To leave Haskell Art, email <email obscured> with the following
email subject: unsubscribe

best,
rohan

Tom






> (for non-haskellers reading along, ie. julian, "freq o" is the
> frequency of o, and "o {freq = ...}" is a variant of o where the
> frequency is "...". of course o is a variant of sinOsc in exactly
> the same way...)
>
> best,
> rohan
>
> --
>
> Read the whole topic here: Haskell Art:
> http://lurk.org/r/topic/4z5GFidD9x7cFW8lZSd7fA
>
> To leave Haskell Art, email <email obscured> with the following
email subject: unsubscribe