Here is an example of mixer track offsets causing pain (I saw this posted to viewtopic.php?t=227624):
https://youtube.com/watch?v=XDMlp3QtPFE&feature=shares
This seems like it's a symptom of mixer connections using raw array indices and offsets, and not being symbolic. They should not be disturbed by superficial reorganizations!
I heard work was being done to improve the mixer engine, so below are a bunch of random suggestions for your consideration:
- More UI assistance to select mixer tracks based on name and not just index: There are some parts in the UI right now where you can right click, and a list of mixer tracks with their names (and indices) will pop up, but there are also still some places where this is not done (such as the channel rack). Any point where a mixer track parameter occurs should allow you to select them from a named list.
- Better UI hints for mixer track identification: Any point where a mixer track is identified by index should be considered an abbreviation - hovering over it should display the full name in the hint panel. Currently, some places in the UI (such as the channel rack) do not do this, while other places (such as in the VST wrapper) do this. This is despite both the mixer selection component in the channel rack and VST wrapper having exactly the same context menu and seemingly the same behavior, so it seems like there's no reason they can't behave the same, or the components could simply be reused.
- More UI assistance to route sends: Right now, you have to route a send at both the source mixer track, and inside the source plugin. Ideally you could just right click on the target mixer track (e.g., like the Frequency Splitter has) and there would be a list of "route to new mixer track >" that allows you to select any mixer track, routing the send from a single point in the UI.
- More UI assistance to route sidechains: Same concept as suggestion for sends. You should just be able to right click on the sidechain input number in Fruity Limiter and route the sidechain directly from there. Not sure how this would work for plugins, you'd probably have to right click on something in the "VST wrapper settings" instead to do this. If this feature was implemented, there's probably not much point in keeping sidechain connections lingering around when they have no destinations receiving them. Just means you have to manually delete the connection at two points, and you'd probably forget to unroute the sidechain from the source track anyway, just leaving unnecessary connections lying around. Maybe you could just add a mixer menu option to clear unused connections.
- Would also be cool if you could drag and drop mixer tracks onto mixer track selector components (including for sidechains and sends) to select a mixer track that way.
A more extreme rework of the mixer internals might also:
- Ditch "mixer track offset", "send indices" and "sidechain input indices", as these overload the concept of "index that refers to a mixer track" and make the UI more confusing. Indices related to mixer tracks should always have the same meaning (it should simply be considered an abbreviation that identifies the mixer track by its current absolute list position). Input/output indices in 3rd party plugins wouldn't be able to achieve this, but the connections settings in the plugin wrapper should behave this way.
- All UI components that select mixer tracks should have a consistent behavior: hovering shows the mixer track name in the hint panel, double clicking brings up the mixer with the track selected, and right clicking enables a different mixer track to be selected from a list of named mixer tracks. (Some of this is already implemented in some places, but it is not consistent throughout FL Studio - if a common component was reused throughout FL Studio this should be easy to achieve.)
- The mixer shouldn't have a fixed number of mixer tracks, but only as much as the user needs. This avoids having 100 unused mixer tracks polluting each list. Each point where you can select a mixer track should provide an additional menu option to create a new one. Old projects can be ported over by detecting which mixer tracks are unused and removing them. It's 2023, dynamic arrays exist
(although for me, this is more to prevent cluttering lists and less because I actually need more than 125 mixer tracks). Same could be said for mixer effects inserts too. You could do something like `mixerTrackList.reserve(125)` if you're worried about dynamic array overhead. If you want, you could still impose a limit, like 999, if you don't want to worry about your UI components being broken by 4 digit numbers 
. - You should only need to form connections at one point.
- Deleting a connection should sever it from both ends.
- Connections are symbolic, and not between array indices. Reordering elements in an array should have no effect on the routing (currently there's clicks and pops when you reorder mixer tracks, which makes it seem like there's a lot of heavy work being done behind the scenes to hide the fact that FL uses raw array indices for routing). This type of symbolic connection is already what FL does for internal controllers. If I link a parameter to a controller plugin, the list simply shows a named list describing each active controller in FL studio, instead of me having to set an array index at both ends to make them talk to each other.
- Code-wise, the underlying graph nodes might be identified by unique keys that are independent from the displayed array index, which would purely an indication of list order. Using a unique key allows for better serialization, and is less bug prone than raw pointers (please avoid raw pointers and use sanitizers so FL doesn't crash ), since the code can detect dangling references and write them out to a log instead of crashing - you just need to make sure to recycle IDs as infrequently as possible, which is easy with 64-bit numbers. Graph nodes could be looked up by their key via hash table (this should have a negligible effect on performance). If you don't want to allow feedback loops, then the mixer graph is acyclic and you could just use shared pointers to keep things somewhat memory-safe, but I still like the other approach (Rust uses it a lot for self-referential data structures).
- Mixer track routing should be more transparent, e.g., you should be able to right click on a mixer track and bring up a "Track routing" dialog showing a list of all the connections to/from the mixer track, including to/from effects within the track. There might be columns describing the source and destination (could be an I/O port on a plugin, an external input or output, or another mixer track, or a MIDI port, etc.), a column describing the type of connection (audio, midi, control), the direction of the connection (input, output). The user should have the option to delete connections where applicable. The mixer provides a rough visual indicator of this for mixer track audio outputs, but MIDI routing, and track inputs, and other routing, is harder to track down.
Lots of the same above about minimizing the importance of raw array indices could be said about MIDI ports. For example:
- Instead of having a fixed list of array indices, the user would create MIDI busses on demand (or keep calling them "ports", or even "MIDI tracks"), and could name them if desired. Each point where a MIDI port is selected allows the user to choose from a list of these MIDI busses as the source or destination, or to create a new MIDI bus. MIDI busses would essentially be like minimalist mixer tracks for MIDI, and allow for more extensibility going into the future.
- Just like mixer tracks, each MIDI bus (MIDI track, port, whatever) would have an option to set its external input and output to a connected MIDI device. This mixer track-esque design for MIDI busses enables more extensibility into the future, for example:
- MIDI busses could be routed between one another just like mixer tracks.
- MIDI busses could perhaps have their own MIDI effects slots, which could support MIDI scripts (with the ability to set parameters defined by the MIDI script).
- Reaper has no distinction between MIDI and audio mixer tracks, and allows routing of both MIDI and audio within them, which enables greater flexibility. A more mixer-track-like design for MIDI busses would open this up as a future option (MIDI and audio tracks could be merged into the same list).
- These suggestions are unlikely to be necessary for now, but flexibility gained by moving away from a fixed list of MIDI port indices opens up future options.
- Existing projects could be easily ported over by automatically detecting which MIDI ports were used and creating MIDI busses for them.
- For each MIDI bus, the user could see a routing list of its inputs and outputs just like suggested above for audio mixer tracks.
- The connection settings in the plugin wrapper should be more consistent between MIDI and audio I/O. Both MIDI and audio connections should have similar displays, with MIDI connections allowing you to select MIDI ports/busses for each event bus reported by the plugin, audio connections allowing you to select mixer tracks for each audio bus reported by the plugin. Right now, the UI for plugin MIDI I/O is different for not much of a good reason, and doesn't handle plugins with multiple input or output event busses (a rare scenario, but why limit it).