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

Feature request: Define function outside of `expr` for use in `expr`. #788

Open
danfuzz opened this issue Nov 13, 2019 · 8 comments
Open

Feature request: Define function outside of `expr` for use in `expr`. #788

danfuzz opened this issue Nov 13, 2019 · 8 comments
Labels

Comments

@danfuzz
Copy link

@danfuzz danfuzz commented Nov 13, 2019

I've found myself wanting to define a common function which I use (in the same patch) in both an expr and an expr~ box. Rather than copy-paste the entire contents of the exprs (and worry about keeping them in synch, it would be great if I could define a named function, which would then be accessible to all exprs. This might operate somewhat like value where banging a function name ... box would cause the function to be defined, after which it would be accessible to exprs. And as with value, one could use $0 in the name to simulate local scope.

@danfuzz danfuzz changed the title Feature request: Define function outside of `expr` for use in expr. Feature request: Define function outside of `expr` for use in `expr`. Nov 13, 2019
@Spacechild1

This comment has been minimized.

Copy link
Contributor

@Spacechild1 Spacechild1 commented Nov 14, 2019

Rather than copy-paste the entire contents of the exprs (and worry about keeping them in synch, it would be great if I could define a named function, which would then be accessible to all exprs.

In Pd, you would usually build abstractions to reuse functionality.

I think you're expecting too much from the [expr] object. I guess what you want/need is actually a textual language instead of a signal flow language. there are objects which embed Python (pd-py) or Lua (pd-lua) in Pd. those give you all the flexibility you want.

@porres

This comment has been minimized.

Copy link
Contributor

@porres porres commented Nov 14, 2019

I think you're expecting too much from the [expr] object. I guess what you want/need is actually a textual language instead of a signal flow language. there are objects which embed Python (pd-py) or Lua (pd-lua) in Pd. those give you all the flexibility you want.

yeah, I just made a similar comment on another feature request

@danfuzz

This comment has been minimized.

Copy link
Author

@danfuzz danfuzz commented Nov 14, 2019

In Pd, you would usually build abstractions to reuse functionality.

Near as I can tell it's not possible to define a single DRY abstraction which implements a function which can be used either as a signal or control function.

My actual use case: I am trying to define a nontrivial oscillator, and I want to use the same function code to both run the signal and be able to output a full array of samples in a single control tick (that is, without having to dump a signal to a table over multiple signal ticks).

@Spacechild1

This comment has been minimized.

Copy link
Contributor

@Spacechild1 Spacechild1 commented Nov 14, 2019

Near as I can tell it's not possible to define a single DRY abstraction which implements a function which can be used either as a signal or control function.

yes, but that's a fundamtental problem with Pd, not limited to [expr]/[expr~]. you always need two seperate objects for signal and control rate.

(that is, without having to dump a signal to a table over multiple signal ticks).

you can put the thing in a subpatch and use the [bang( method of [switch~] to write several audio blocks to a table at 0 logical time.

@Spacechild1

This comment has been minimized.

Copy link
Contributor

@Spacechild1 Spacechild1 commented Nov 14, 2019

that being said, defining expressions as functions and binding them to symbols is certainly an interesting idea, but that would only solve one part of your problem, because then the question is how you would use a "control rate function" inside [expr~]? This means a pretty significant expansion of the "expr" objects, and since you're an experienced software engineer, I recommend you do a PR as a proof of concept and see how far you get :-)

@umlaeute

This comment has been minimized.

Copy link
Contributor

@umlaeute umlaeute commented Nov 14, 2019

there are objects which embed Python (pd-py)

just for the record: currently pd-py is Python2 only, and Python2 is nearing it's EOL in about 1½ months (as of today).
I wouldn't recommend switching to just now (or before you do, investigate on how you can help porting it to Python3)

@umlaeute

This comment has been minimized.

Copy link
Contributor

@umlaeute umlaeute commented Nov 19, 2019

i would imagine something like:

[lambda add(x,y) x+y]

[expr add($f1, 23)]

[expr~ add($v1,$v2)]

i don't see any problem with "control rate functions" (apart from performance constraints)

@Spacechild1

This comment has been minimized.

Copy link
Contributor

@Spacechild1 Spacechild1 commented Nov 19, 2019

you're right, the lambda could be polymorphic (like in your example)

@umlaeute umlaeute added the feature label Nov 20, 2019
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
4 participants
You can’t perform that action at this time.