Skip to content
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

Using continuous patterns with control busses needs segment to work properly #806

Open
thgrund opened this issue Mar 10, 2021 · 6 comments

Comments

@thgrund
Copy link
Contributor

thgrund commented Mar 10, 2021

it looks like that using continuous pattern with control busses just applies one value, i.e.

d1 $ s "bev" # lpfbus 1 (sine * 7000) # legato 1

A workaround is to segment the continuous function like:

d1 $ s "bev" # lpfbus 1 (segment 128 $ sine * 7000) # legato 1

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 or segment, I guess.

@thgrund thgrund changed the title Using continuous patterns with control busses doesn't seems to work Using continuous patterns with control busses needs segment to work properly Mar 10, 2021
@polymorphicengine
Copy link
Collaborator

polymorphicengine commented Mar 11, 2021

You can do
d1 $ s "bev # lpfrecv 1 # legato 1
d2 $ struct "t*128" $ lpfbus 1 (sine * 7000)

@yaxu
Copy link
Member

yaxu commented Apr 24, 2021

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..

@telephon
Copy link
Contributor

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.

@yaxu
Copy link
Member

yaxu commented Apr 25, 2021

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.

@telephon
Copy link
Contributor

Beginners may also get confused. I'd be surprised to get more than one beat from d1 $ speed (sine + 1) # sound "bd"

@yaxu
Copy link
Member

yaxu commented May 3, 2021

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

4 participants