Re: [MindIO-devel] dynamic Tx/Rx

[Jeremy W. <jjw...@ub...>]

Ian Vincent wrote:

>
>>
>>> From all the designs I have seen, six would be enough, or as you 
>>> suggest use an AND as a splitter. Either way the graphical 
>>> representation would not want all six to be displayed if not used 
>>> because it makes the graphic too big and uses up valuable screen 
>>> real estate. BE's implementation is superb in this respect, though I 
>>> expect the code is tricky.
>>
>>
>> If we do it this way, then we need a method of Rx and/or Terminal 
>> that can be used to find out of a specific Rx has been connected to.  
>> That's to keep the graphic clean by hiding unused Rx's, as you 
>> mentioned, and also so anther Terminal would know which Rx's are 
>> free, if there are multiple with the same function.  Or...
>
>
> Reading this, something sprung to mind, and that is that we could have 
> 'transmission' or 'Link' object that conceptually represents the 
> linking between any two nodes. This was how I originally envisaged 
> implementing a BE type design, before seeing what you had in mind. In 
> the current design, Terminal declares an Rx and pass's samples via the 
> Rx interface. I am not sure if my suggestion would have any 
> advantages, but thought I would put it on the discussion table so it 
> can be considered and rejected or adopted as we decide. Conceptually 
> it does make some sense.
>
> This 'Link' object could have dynamic Tx's, and could graphically 
> represent itself as the single output node of a terminal object. When 
> you add a link in a BE design window, you effectively create a 'link' 
> and wouldn't be suprised if BE actually has such an object. Eventually 
> we will need a graphical linking shape of some sort, and this link 
> object could manage that. Otherwise the creation of such a linking 
> line (or whatever) would need to assigned to either Tx or Rx. This has 
> to be plus for considering a seperate 'link' object. 

I think there is no difference in implementation between what you are 
describing and what we have now.  The correlation between real-life 
objects and software "objects" is limited.  Objects are "linked" by 
method calls.  And any type of visual representation is only indirectly 
related to actual object relationships.