Numbering alias connections


Using the ADAU1446 and Sigma Studio 3.7, I am trying to configure what amounts to a mixer bus... where each input can be assigned to a particular output. For my purposes, I am using a 4-position stereo multiplexer at each oputut and connecting each input to all 4 muxes. Doing so creates a jumble of connections that are rather difficult to make heads or tails of. So I decided to use the Alias method. It works fine, and is nice and orderly and easy to read except...

...I have no control over the numbering of the alias instances. I can name each alias differently, but I cannot renumber them. Furthermore, the first few are in sequence (1,2,3,4,5,... ) then as I add new ones they jump around (8, 10, 12, 16, 17, 23...). So even though the next number in sequence should be, say, a six.... I cannot get six to appear. Even if I eliminate all other higher-numbered aliases.

To be clear, the nunber I am referring to is the one in the alias label with the dashes around it -1-, -2-, etc.... not the text underneath which is easy to change.

So my question is: how can I force the numbering of each instance to be what I want it to be?

Failing that,can you recommend an alternate method of channel assignment architectutre?


chuck winegar

Parents Reply Children
  • Benno,

    Yes, the problem appears to persists even in the latest release of v4.5.

    However, they have added some new features for managing aliases which appear in the pull down options after right-clicking on the alias. The new features offer some consolation, but I have resorted to using the text labels to keep things straight for now.

    Like many aspects of using Sigma Studio over the years, some issues you just learn to accept or find a workaround. None that I have encountered were so horrible that we were willing to abandon the platform which has otherwise been very good for us. Though I would really like it if they eliminated the need for the "T" connection and just built it into the GUI and let the compiler sort out how to manage the fan-out code.

    If the Sigma development group is anything like ours, there's always more work than bodies in the department, so the squeakiest wheels get the grease, and It looks there are only 2 of us squeaking! In our dept, 3 squeaks is the threshold for devoting resources to greasing the wheel, at which point we apply triage criteria for deciding if the issue is catastrophic or merely inconvenient.

    One factor that has tamped down my otherwise high tendency to complain about buggy software is that the user base for an App like this is quite a bit smaller than a ubiquitous office app, but requires a similar amount of development effort, possibly more, given the technical nature of it.

    Just my 2 cents. Maybe you can find a colleague to become the 3rd squeaky wheel??