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

Effects get connected to wrong track's throws/catches #1

Closed
lzref opened this issue Jan 27, 2016 · 2 comments
Closed

Effects get connected to wrong track's throws/catches #1

lzref opened this issue Jan 27, 2016 · 2 comments
Assignees

Comments

@lzref
Copy link
Owner

lzref commented Jan 27, 2016

To reproduce: add 3 effects to track 1, add 2 effects to track 2, clear effects on track 1, add 1 effect on track 2 (it'll be connected to the right throws but won't be connected to previous effects). Add more effects and you may see effects connected to the wrong tracks.

@lzref
Copy link
Owner Author

lzref commented Jan 28, 2016

As I was debugging this issue (and thought I almost fixed it) I realized that my whole approach has been wrong all this time.

I was dynamically adding effect objects to the effects panel and assuming that the total number of objects on the effects panel will be the last inserted object ID. That worked when I was only adding effects but doesn't work when effects are sometimes deleted, since PD reuses object IDs.

Now, I've been hoping to keep effect abstractions really light and dumb: the only requirement was to have 2 signal inlets and 2 signal outlets. The effects panel was responsible for connecting effects to each other.

But it looks like the only reliable way of determining object ID's of newly created effects is placing iemguts/canvasindex inside of them.

So I see 2 possible solutions:

  1. Make effect abstractions heavier and require that they contain certain scaffolding code.
  2. Keep effect abstractions dumb but wrap them in effect wrappers that will handle all scaffolding. Ideally we'll have just a single effect wrapper abstraction that will be able to handle all types of effects.

I'm gonna try to go with option 2 unless I find reasons why that's not possible.

@lzref lzref self-assigned this Jan 28, 2016
@lzref
Copy link
Owner Author

lzref commented Jan 28, 2016

How is the effect wrapper abstraction gonna communicate with the rest of the system? Good question. Sounds like there has to be some kind of a global bus where wrapper can at least send its object ID. After receiving that the effects panel can connect the wrapper object to other objects. Potentially wrapper objects can have special communication inlets and outlets that can be connected to the parent right after the object is created.

@lzref lzref closed this as completed in a8f93a8 Jan 28, 2016
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