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

Receiving non float by multiple inlets in [ofelia] #51

Closed
emviveros opened this issue Jan 28, 2021 · 3 comments
Closed

Receiving non float by multiple inlets in [ofelia] #51

emviveros opened this issue Jan 28, 2021 · 3 comments

Comments

@emviveros
Copy link

Hi Zack!

I know I can control outlets doing things like this:
Captura de Tela 2021-01-28 às 03 07 46

There's a way that I can receive another pd atoms by mutiple inlets of ofelia object independently?

Maybe something like:
Captura de Tela 2021-01-28 às 03 15 57

@cuinjune
Copy link
Owner

Hi, receiving non-float data through non-first inlets is not possible in Ofelia.
While it is possible to support other types by using "active" inlets, it will add extra overhead so I decided to use passive inlets supporting only float types. And if you want to use other types, you can always use the first inlet to receive a list of any types and handle them internally.

@emviveros
Copy link
Author

Ok! Thank you again!! :)

@jamshark70
Copy link

I realize this is closed and nothing will be done, but... here's a use case where it would be helpful.

Pd forum user 60Hz has created some Gem-style abstractions to simplify many basic use cases, for use in workshops where it would be too much to have everyone build up Lua code from scratch.

I was working on extending these for GLSL shader support. To handle image processors, it was necessary to pass imageID symbol messages, to tell the next processor in the chain which module's image variable contains the source to operate on. That was pretty straightforward.

Next problem: shaders with two image inputs.

If you can pass arbitrary lists into the additional inputs, then it would be easy to have a left imageID message for the main image source and a right imageID for the auxiliary source.

Because this is not allowed, it's necessary to have for instance imageID and imageID2, both going into the left inlet, and then every image-handling abstraction needs to include (replicate) logic to output imageID, imageID2, imageID3 as needed. Which is possible, but a lot messier.

Anyway, FWIW. I do realize that the intended design currently is to have one massive [ofelia] object that does pretty much all the drawing in one place, but... the learning curve for this is pretty nasty (the preamble just to open a window makes my head spin). Getting started really needs to be easier if it's to gain any traction in the Pd community, which is where abstractions such as 60Hz's come in.

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

3 participants