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

implicit or explicit eval? #9

Open
stagas opened this issue May 7, 2015 · 2 comments
Open

implicit or explicit eval? #9

stagas opened this issue May 7, 2015 · 2 comments

Comments

@stagas
Copy link
Member

stagas commented May 7, 2015

currently, eval happens onkeyup(with a tiny debounce period). maybe this is not ideal as you'd like to do many edits and evaluate them all together. we could have a key combination that does eval instead. this could also help with #8 so it would be possible to eval a dsp function or maybe even stop it for a while. this should be communicated visually to the user, maybe coloring the background of the function in a manner that it says, "it's playing", "it's evaluating", "it tried to evaluate but it has an error", "it has stopped".

@stagas
Copy link
Member Author

stagas commented May 8, 2015

we should keep implicit eval and accept key combinations for these actions:

  • eval (explicitly evaluate this function. this would be useful only in freeze mode)
  • freeze/unfreeze (this will allow big edits without re-evaluating, unfreeze would eval and start implicit again)
  • mute/unmute
  • restore (return the function to its last working state, like a power undo for when we made a mess and it's hard to recover) *idea: maybe also multiple undos/redos, is it worth the trouble? needs real usage testing so this is for later unless it's trivial to implement along.

these need to be communicated visually, by coloring the background, or drawing a frame, or icons, or a combination of these

@stagas
Copy link
Member Author

stagas commented May 8, 2015

in freeze mode it should be visually communicated whether the function evaluates properly, so it should actually be evaluated in the background, but not used.

also, since we are computing these in parallel, a function that doesn't evaluate is essentially an implicit freeze/unfreeze so these can be implemented using that mechanism, that will also give us for free the ability to continue evaluating the rest of the functions even when one is in a state of error.

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

1 participant