Re: [MindIO-devel] dynamic Tx/Rx

[Ian V. <vi...@ig...>]

>
>> 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 guess we need to find a balance between program complexity and convenience
>>>for the user.

>>Always!!!! Lets run with dynamic and see where that leads. It is probably 
>>no harder to add one Tx or Rx dynamically than 25.
>
>...if we do it this way, we need to modify the design to allow for 
>additional Rx's to be added dynamically.

The only object that I can think of that would require multiple Rx's would 
be logic objects such as AND or OR, and these could be implemented as a 
single universal logic object, with programmable inputs. do they need to be 
dynamic. If it makes things easier, logic objects could have a fixed no of 
Rx's (say 5) but could be cascadeable if more where needed perhaps. Can you 
think of any other objects that need multiple Rx's?