Open thgrund opened 3 years ago
You can do
d1 $ s "bev # lpfrecv 1 # legato 1
d2 $ struct "t*128" $ lpfbus 1 (sine * 7000)
You have to end up with a discrete pattern, to be able to events over a network.
We could look at setting a default control rate if a continuous pattern reaches a bus. 30 per cycle? We could do the same for 'normal' events, e.g. d1 $ speed (sine + 1) # sound "bd"
could send 30 kicks per cycle..
but wouldn't it be better to use a function like segment
that explicitly specifies this? A default rate sounds like something you'd want to adjust all the time anyway.
Yes true, it doesn't really make sense to send a continuous signal to an event bus. A tradeoff between doing something approximating what a beginner expects but which might sow seeds of misunderstanding, and not doing anything.
Beginners may also get confused. I'd be surprised to get more than one beat from d1 $ speed (sine + 1) # sound "bd"
Looking a bit closer, I see that e.g.
d1 $ sound "bd" # shapebus 2 sine
This does send the bus value at 20Hz, but always sends 0.5. If you send this:
d1 $ shapebus 2 sine
The sinewave will be sampled and sent at 20Hz.
So this always sends 0.5, because it's being combined with the 'sound' which is only taking one value:
d1 $ sound "bd" |> shapebus 2 sine
This sends the sine to the bus at 20Hz, but no sounds are triggered at all:
d1 $ sound "bd" >| shapebus 2 sine
So I was thinking this would both send the bd
once per cycle and the shape bus at 20Hz:
d1 $ sound "bd" |>| shapebus 2 sine
However no, nothing gets sent then.. Combining discrete and continuous patterns together is not well defined, I guess.. This could probably be fixed.
it looks like that using continuous pattern with control busses just applies one value, i.e.
A workaround is to segment the continuous function like:
But this does not look correct, because one advantage of control busses is that you don't have to segment your pattern with
chop
,split
orsegment
, I guess.