10-27-2016 01:30 PM
I'm glad I asked, because I like your idea better. Particularly because I want to be able to code and debug on my laptop which won't have access to the hardware, so I was going to do a Hardware Abstraction Layer, so I could have simulated hardware. I would probably keep the hardware interface actor alive and then I can call into it for the manual actions and I can also have it broadcast some sort of status update to be displayed on the GUI.
I think that will work very well.
10-27-2016 01:40 PM
Look up "low coupling". You could write a simulated hardware interface that takes the same messages as the real one, and use them interchangeably.
The basic idea is to make a parent actor with all the method VIs you need. Make them dynamic dispatch, and leave them empty (no new code on the block diagram). Make messages for all of these methods. Then make children of this parent actor, and provide those children with overrides of all of the dynamic dispatch methods. You now have a family of actors that all take the same message, but respond to them differently. (Yes, there are similarities to state pattern actors.)
11-02-2016 09:38 AM
Sounds perfect. Another question: How are people handling configuration? Static configuration that doesn't change while the program is running isn't too bad, but what about configuration that the user can change while the program is running. I've got a few ideas, but kind of curious to hear what everyone else is doing?
11-02-2016 04:14 PM
niACS wrote:
. . . make a stateful actor with "manual" and "running" states. . . .
A "manual" state: That is a much more useful idea than the "not running" state which had somehow taken over my way of thinking about it.
I have my sequencer and an instrument manager as children of my application actor. The sequencer asks the app to do things with the instruments, the app passes those requests to the instrument manager, the app then passes results from the manager back to the sequencer as needed. It's indirect, but it reflects that our list of connected instruments doesn't change based on what we're doing with them.
11-02-2016 04:24 PM
I'm curious... Why did you decide to make them children? Is that just so that they all use the same messages? Do you perhaps mean they are nexted subactors of your application actor? That coincides more with the way I am thinking about the problem.
11-02-2016 04:27 PM
Sorry. I meant sub-actors.
11-02-2016 04:29 PM
That makes a lot more sense now. I thought that was what you meant.
It is very easy to get confused with some of the terminology. I'm finding particularly in the beginning its easy to confuse the "actor tree" for who launches who and who communicates with who, etc with the object inheritance heirarchy tree.
11-03-2016 11:00 AM
Taggart wrote:
I'm curious... Why did you decide to make them children? Is that just so that they all use the same messages?
Yes.
Do you perhaps mean they are nexted subactors of your application actor? That coincides more with the way I am thinking about the problem.
No. Parent/child always refers to inheritance; caller/nested refers to actors launched by other actors (which is a composition relationship).
11-03-2016 04:23 PM
NiACS my comments about inheritance were directed at what Auspex wrote. I think you and I are on the same page with regards to the low coupling and using inheritance so they all take the same messages and then overwrite the parent method in the child classes to get different behavior for the same message depending on which child actor I have launched.
11-03-2016 04:36 PM
Taggart wrote:
NiACS my comments about inheritance were directed at what Auspex wrote.
Oh. Sorry about that.