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

cycle oriented delay time #1051

Open
felixroos opened this issue Apr 10, 2024 · 4 comments
Open

cycle oriented delay time #1051

felixroos opened this issue Apr 10, 2024 · 4 comments
Labels
enhancement improves an existing feature

Comments

@felixroos
Copy link
Collaborator

felixroos commented Apr 10, 2024

instead of seconds, there could be a delay control that uses cycles as a unit. maybe delay could be reused with a special suffix, like delay('.25c'), which would also allow one to keep using combo notation delay(".5:.25c:.9").

@felixroos felixroos added the enhancement improves an existing feature label Apr 10, 2024
@felixroos
Copy link
Collaborator Author

naturally, this leads to a more general design where c could be used on any other seconds based control like envelopes

@yaxu
Copy link
Member

yaxu commented Apr 10, 2024

How could "0.25c".mul(2) do the expected?

@felixroos
Copy link
Collaborator Author

How could "0.25c".mul(2) do the expected?

i'd say that should return "0.5c" .
so _c would be an artificial number type, similar to how hex numbers are prefixed with 0x

@yaxu
Copy link
Member

yaxu commented Apr 10, 2024

So mul would take care to do the multiplication while preserving the suffix? Or would something parse it into an object like {value: 0.25, _type: cycle}?

I guess ideally "0.25c".fmap(x => x*2) would work too.

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

No branches or pull requests

2 participants