How to use the operator <> of overlay

Hello, I'd like to ask you a question about overlay.

d1 $ sound ( overlay "bd sn:2" "cp*3" )
I hear it's the same as d1 $ sound ("bd sn:2" <> "cp*3")
I'm going to use <> in the tidal cycle, but it is not recognized.
How can overlay operator <> use code?


what error message are you receiving? If I do this with vanilla settings I get

    Ambiguous occurrence ‘<>’
    It could refer to
       either ‘Sound.Tidal.Context.<>’,
              imported from ‘Sound.Tidal.Context’
              (and originally defined in ‘Sound.Tidal.Core’)
           or ‘Prelude.<>’,
              imported from ‘Prelude’ (and originally defined in ‘GHC.Base’)

In this case, the problem is that the operator <> is defined both in Prelude (which is a set of standard functions that are automatically imported) and in Sound.Tidal.Context (which is the one you want to use). Consequently the compiler does not know which version of <> you want to use and you have to do this explicitly. To do that you have several options:

  1. Write Sound.Tidal.Context.<> explicitly, i.e.,
d1 $ sound ("bd sn:2" Sound.Tidal.Context.<> "cp*3")

which is a quick fix but is cumbersome to write every time
2. Import prelude without <> to avoid the name clash. You can do this by writing

import Prelude hiding ((<>))

and evaluating the line in tidal. The ambiguity should now be resolved.
3. Define <> explicitly as Sound.Tidal.Context.<>, i.e.,

(<>) = (Sound.Tidal.Context.<>)

Again, evaluate the above line in tidal and <> should now work as expected.

You can add (2.) or (3.) to you boot tidal to avoid having to execute them every time you launch tidal cycles.

Incidentally, I have a follow up question:

Why does Sound.Tidal.Core redefine <> and not simply make Pattern a an instance of Semigroup? I guess you could argue that Pattern a does have many binary operators that qualify as semigroup but then, why choose <> to be the operator for overlay?

Hi @fnab,
There is no good reason, apart from I don't really know what Semigroup is. I remember there was some structural change with this package that caused some build errors a while ago. I guess that was the point that <> from Semigroup came into scope and broke things. If <> has the same meaning in both packages that's a happy coincidence. I'd happily accept a pull request that defines a pattern as a semigroup instance, if that improves things!

I'd happily accept a pull request that defines a pattern as a semigroup instance, if that improves things!

Great! I was just looking for an easy first issue to start contributing. I'll try to do it sometime this week.

1 Like

Excellent, looking at Semigroup it does look like a good first 'issue'.