Hi,
I am currently thinking about rewriting my JumpToFromSendMod tool, which is at least for me one of the most used tools. I would like to expand the functionality to sidechain devices and also maybe meta devices. Of course it needs to be rewritten from scratch. I also want to display info about the sources on each receiving device, maybe within the context menu, not sure yet.
But currently, if I want to find the sending devices of a track, or in sidechain context, want to find the sending devices of a device, currently there is no hint at all in the track or device object about the source devices… The only way is to completely iterate thru all the devices left and above in the processing tree…
So if I want to add functionality also to the receiving device, for each click on a device, that part of the processing tree needs to be iterated… I guess while the current api might be fast enough, or this would introduce only minimal lag, I imagine that this can easily sum up, as soon as multiple tools are doing similar stuff, or if I want even to do recursive lookups…
So my suggestion for the API would be something like the following. The track and the device object could provide a “sources” array, which Renoise will automatically update, using its internal event system (assuming such a thing does exist). So an api dev can always assume that this array is up-to-date. This array then of course contains only references to the source device objects.
Seems to me that not even an observer pattern is required here. I mean, it could also be an observer, maybe the is a scenario where this is required (another tool is changing the routing or something)?
So something like:
renoise.song().tracks[].sources[]
renoise.song().tracks[].devices[].sources[]
Then it would be super easy and maybe much more performant to write a “routing-helper-tool”, which also easily can display info about the source sending devices etc.
I think this question mainly goes to @taktik 
Do you think such addition would make sense and bring benefits, or do you think it is completely ok to iterate all the time, maybe multiple times, since performance is fast enough?
Or is this just a wont-do, due time limitation?
I also have the impression, if you have to iterate over numeric arrays all the time in the api, it is way more hard to transfer the api to an oo style approach. If the api had more of such “convenient” additions, which help to prevent to iterate at all, the transition could be way smoother in the future, and not break the tools which already use the “convenient” additions only.
If the above was implemented, then this could be even expanded a bit:
By adding then ALL the sources, so for a device, also the previous device in the dsp lane, and for a track, also all the sending tracks and instruments, then you also could very safely iterate from master to the source simply looking at sources only, not having to deal with any kind of order anymore. You could then assume that as long there is a source, you are not at the last leaf node. Maybe then there needs to be a general observable like Renoise.song().source_changes, which then contains the objects on which renoise changed the sources.
The other direction like “targets” is not required afaik, since the device/track itself contains already info about the target. Except for the dsp lane maybe.