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

Self-patched Muxlicer (COMIO to Gate Mode) creates triggers when not expected. #30

Open
hemmer opened this issue Dec 9, 2021 · 3 comments
Assignees

Comments

@hemmer
Copy link
Collaborator

hemmer commented Dec 9, 2021

image

From here.

What I did

  1. Connect “Com I/O output” to “Gate mode CV input”
  2. Turn “Gate mode knob” clockwise fully
  3. Set the fader values as [0.1, 0, 0.2, 0, 0.3, 0, 0.4, 0] from left to right

I chose 0 at even-numbered steps, so I thought no gates would occur at it, but a short trigger occurred. I don’t have a hardware, so I can’t tell it is intended or not. I put an image which I hope to explain this situation.

I suspect that this is due to the there being a 1 sample delay being introduced by the patch cable. A possible solution is to introduce a 1 sample delay to the gate out generator, but more investigation needed.

@hemmer hemmer self-assigned this Dec 9, 2021
@hemmer
Copy link
Collaborator Author

hemmer commented Feb 3, 2022

Fix with unacceptable performance hit posted here. It is due to the 1-sample delay at least.

@ZwergNaseXXL
Copy link

ZwergNaseXXL commented Mar 12, 2022

I haven't checked Muxlicer's code besides your patch, but maybe this helps:
See virtual void onPortChange(const PortChangeEvent& e) {} in Module.hpp.
Unfortunately, this event is not sent for stacked output cable events, only when the connected/disconnected state of the port changes. (Actually iterating over all the cables to determine the previous state, see Engine::addCable().) But it is sent for every input cable event (because there can only be one cable per port). And you still have to iterate over all cables because the event doesn't tell you the cable or the other module. So maybe you could limit the performance hit by only iterating over the cables when an input cable is being connected to the gate mode input.

@hemmer
Copy link
Collaborator Author

hemmer commented Mar 12, 2022

Thanks for the hint - I won't be able to take a look for a while, but this will help when I do.

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

2 participants