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

named and optional IO #20

Open
trporn opened this issue Jan 10, 2020 · 3 comments
Open

named and optional IO #20

trporn opened this issue Jan 10, 2020 · 3 comments

Comments

@trporn
Copy link

trporn commented Jan 10, 2020

It is quite simple and refreshing indeed.
It would be nice to add named inputs/outputs so that components can be connected by name. It would be less bug prone, especially since the types are dynamic and there is no type safety on the bus.

Also, can a component know if a specific output is required by some future component or not? This is nice for performance reasons. If it is not needed, it can be skipped.

Thx.

@MarcusTomlinson
Copy link
Member

Hi @trporn, thanks for your interest in DSPatch!

Connection by pin name string is certainly doable but arguably a cleaner, even less error prone way to do this would be to declare public enums for your IO in each of your components like so:

enum class Inputs
{
    Left = 0,
    Right = 1
};

Regarding determining if an output is being used, no, not at this point at least. Because circuits are implemented as pull systems, components know only about the components feeding into them, not the ones they feed to.

@MarcusTomlinson
Copy link
Member

MarcusTomlinson commented Jan 10, 2020

Oh wait, we do ref count component outputs. Your latter request may be doable. I will look into it :)

@trporn
Copy link
Author

trporn commented Jan 12, 2020

Yeap, enum is a nicer way to go. You can use something like magic_enum from https://github.com/Neargye/magic_enum to automatically infer the number of elements in the enum, turn enums to strings etc. This would make the enum declaration replace the definition of the number of inputs/outputs, so the hassle is kept to a minimum.

Oh wait, we do ref count component outputs. Your latter request may be doable. I will look into it :)

I think it is generally desirable to be able to treat the whole circuit as a graph. This way you can answer questions like "what output changes if I changed this input?" or "which of the inputs influence that output"

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

No branches or pull requests

2 participants