Skip to content
This repository has been archived by the owner on Mar 27, 2020. It is now read-only.

unespected behavior with duplicated names #11

Closed
infamedavid opened this issue Feb 5, 2019 · 4 comments
Closed

unespected behavior with duplicated names #11

infamedavid opened this issue Feb 5, 2019 · 4 comments

Comments

@infamedavid
Copy link

infamedavid commented Feb 5, 2019

actually I think it is not a bug, is a normal behavior

I add a Skjack module and rename the input as 01, 02, 03, 04 and the output as 01, 02, 03, 04
if I try to connect something using a graphic tool (Claudia in this case) is not allowed to connect anything to the inputs sockets (it seem like jack assume the named 01, 02, 03 ,04 socket are outputs and it cant connects with other ouputs )
a second issue occurs if I "Duplicate" using the right mouse btton menu the Skjack module, it create 4 additional inputs and 4 additional outputs named 01, 02, 03, 04 respectively.
if I try to connect something to the second module outputs , the connection jump to the socket of the first module that have the same name

all that can be fixed renaming and avoiding duplicate names to the inputs and outputs and restarting the rack.

is there a way to avoid this behavior?, however I think is a topic to be considered in a future manual

@dizzisound
Copy link

I think this behavior is what the README file addresses when quoting "Each name must be unique across an entire Rack instance". I could be wrong, though.

@infamedavid
Copy link
Author

I see...
sorry I had not read that

@Skrylar
Copy link
Owner

Skrylar commented Feb 6, 2019

I think this behavior is what the README file addresses when quoting "Each name must be unique across an entire Rack instance"

This is correct. A JACK client's port names must be unique. It is an error to do otherwise, but options for reporting errors like this are limited.

The idiomatic thing to do is, when the same name is used for both input and output, to add a "-in" and "-out" suffix to the port names. I could patch it to do this for you, so at least using names like "reverb" would make sense (and result in a reverb-in and reverb-out port.)

@Skrylar
Copy link
Owner

Skrylar commented Feb 6, 2019

Split in to relevant tickets.

@Skrylar Skrylar closed this as completed Feb 6, 2019
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants